[HN Gopher] I'm Building a Self-Destructing USB Drive Part 2
___________________________________________________________________
I'm Building a Self-Destructing USB Drive Part 2
Author : machinehum
Score : 51 points
Date : 2022-09-19 16:50 UTC (6 hours ago)
(HTM) web link (interruptlabs.ca)
(TXT) w3m dump (interruptlabs.ca)
| Nomentatus wrote:
| Build in 2 flashdrives - don't lick your fingers, you see the
| regular drive with innocuous crap. Lick, and you see the real
| deal. Better, have a magnetic key or transponder that unlocks the
| real drive (and hides the innocuous one.) Doesn't draw the
| attention that a mysteriously not working drive does.
| aramachandran7 wrote:
| Why use a micro at all? You could have implemented the entire
| circuit with a couple extra discrete components to reduce
| complexity.
| yellow_lead wrote:
| Does this actually prevent forensics from finding any data?
| 2OEH8eoCRo0 wrote:
| No.
|
| If you do this as part of a legal search and they catch on
| you're now in a lot more trouble and you've caught their
| attention.
| neilv wrote:
| I think the XKCD wrench comic could use a sequel, but it
| might be out of scope or too dark.
|
| If you have to worry about an adversary who _would_ torture
| you, then I 'd guess that convincing them that you just
| intentionally destroyed the info... is only going to make
| them torture/kill you punitively.
| dheera wrote:
| It would probably be better if the device self-destructed
| _automatically_ if some kind of dead-man switch signal isn 't
| given. Like having to press a button at least once a day or
| maintain reception at least once a day with an implant inside
| the owner's body; else it self-destructs.
|
| That way _you_ aren 't doing anything, it's their act of
| arresting you or sneezing your device that causes the
| destruction. If they want to keep the evidence they have no
| choice but to keep the device in your possession.
| 2OEH8eoCRo0 wrote:
| I wouldn't risk it. Don't break the law in the first place.
| Comply with legal requests. If you're a journalist be
| careful!
| nibbleshifter wrote:
| mrguyorama wrote:
| Unless there is ample precedent or case law showing that
| this kind of rules-lawyering is acceptable, always assume
| judges would frown upon obvious attempts to subvert the
| intent of law by using the wording of the law.
|
| Unless of course you are a big company, in which case that
| seems to be the expectation.
|
| So the real advice here is just to be a very important
| person.
| dheera wrote:
| I mean, I would comply, the device just exists, is
| designed in a certain way, and wasn't designed by me.
|
| If the law forcefully and physically separates the device
| from me, the device self-destructs of its own design. The
| law enforcers would be the ones at fault for destroying
| the evidence.
| [deleted]
| wizofaus wrote:
| > It would probably be better if the device self-destructed
| automatically if some kind of dead-man switch signal isn't
| given
|
| How is that not what's being described here? The dead-man
| switch signal is to moisten your fingers before plugging it
| in.
| wongarsu wrote:
| Depends on your adversary. To the normal user who plugs it in
| it will appear dead, and the average data-restore lab might
| desolder the flash chip, figure out that it's dead and give up.
|
| But I'd expect this to just burn out the flash chip's control
| logic, the stored data itself should stay intact. Someone
| determined enough could decap the chip and surgically wire in
| replacements for any burned-out parts.
|
| I think it's a good balance if you have a believable excuse why
| you're carrying a dead USB stick, and aren't on the list of
| public enemies. It's a lot simpler than trying to melt the
| flash with thermite or something like that. But I wonder if
| there would be a reasonable way to run an erase cycle first.
| lofaszvanitt wrote:
| Not at all.
| system2 wrote:
| Why not? If the data is zeroed, there wouldn't be anything to
| find by forensics.
| Kirby64 wrote:
| You're not zeroing the data, you're just burning up the
| flash memory in some way... which is not necessarily going
| to reliably damage the actual contents of the data, most
| likely it'll probably just damage some built-in voltage
| regulator or IO. For a truly determined adversary, you
| could pull the flash chip and read the contents directly.
| It's much more difficult, but theoretically possible if the
| information is valuable enough.
| Arrath wrote:
| From my reading it doesn't appear to zero the data, just
| overdrive the controller and hope to burn it out, which may
| or may not have downstream effects on the memory chip
| itself.
| xani_ wrote:
| That if it can produce enough current for it in the first
| place and I kinda doubt that. I've seen chips survive
| short term reverse polarity even, this might just be fine
| squarefoot wrote:
| I don't like how it's engineered: the uC is completely overkill
| as the high voltage could be generated by a single transistor
| switcher that charges a capacitor, not unlike those "Joule thief"
| circuits used to light higher voltage leds with small batteries.
| The mosfet would then just switch that voltage, which could well
| be tens of volts or more. However, the working principle assumes
| the user's skin would be normally high, which is not the case if
| he/she is sweating since sweat would lower the skin resistance
| even more so because of sweat higher sodium content.
| amelius wrote:
| I don't like the initial assumptions: that a cop would never
| have wet fingers, or that you'd never miss the contacts or have
| partially dry fingers when plugging it in.
| amelius wrote:
| I would like to have seen something that triggers when the
| user says "by all means, have a look; I have nothing to
| hide".
| kazinator wrote:
| Why not use the uC to implement a secret compartment on the
| drive instead? Like switch between two flash chips.
|
| When the cops plug in the drive, they see the content you want
| them to see. And there are no hidden partitions or anything:
| your uC passes through all signals to a complete storage
| device. They can examine the partitions at the block level, and
| all that; nothing is hidden.
|
| You have some mechanism to instruct the uC to switch different
| storage device (which, of course, is encrypted so that it's
| protected should it be discovered).
| angst_ridden wrote:
| I think Naomi Wu's Big Red Switch Box is better. With a seemingly
| dead drive, an adversary may still try to rubber-hose an access
| method out of you on the assumption that there's some special
| sequence to required to gain access. A simply dead drive is
| suspect, especially given the prevalence of ideas like port
| knocking, etc.
|
| With the Big Red Switch that throws sparks and emits smoke, the
| adversary may still inflict punishment on you, but they have no
| illusions that they can torture you into revealing "the secret
| way to access it".
| jrootabega wrote:
| I searched several variations on that, but couldn't find what
| you're referring to. Do you have a link?
| Morizero wrote:
| I believe it's her "Emergency USB Drive Destroyer"
|
| https://www.youtube.com/watch?v=Gg0sdeAwN5A
| jrootabega wrote:
| Ah, yeah, I could see how that might help if it's robbers
| trying to get your bank pw/wallet key.
| SpikeDad wrote:
| I think it's more for Chinese communist police raiding
| her home. Since she runs mains voltage through the USB
| drive the thing would have to be plugged in.
| aivisol wrote:
| How does it differentiate between licked fingers and sweaty
| hands?
| howmayiannoyyou wrote:
| Better off with a strong shallow field, high intensity rare earth
| magnet attenuated by a removable stainless steel shield that
| erases the data only if the USB key is removed from a holster
| incorrectly, thereby removing the stainless steel shield.
| LeifCarrotson wrote:
| It's a USB key, not a floppy. Magnets do not affect Flash
| storage. Typical (austentic) stainless steels do not attenuate
| magnetic flux.
| unwind wrote:
| Very interesting project, but I must admit I raised an eyebrow
| when the author said it was nice to use an ATtiny25(8-bit core)
| instead of the usual (32-bit) ARM micro controllers, then
| proceeded to use _float_ in the code all over the place.
|
| Since the AVR core has zero support for floats, that will mean
| it's all software emulation, bloating the code fantastically. I
| guess (and understand) it doesn't matter as long as the
| application fits and does what it's supposed to do, it was just
| ... extremely jarring.
|
| This, for example: void set_pwm(float voltage)
| { OCR1A = ( voltage / 5 )* 0x400; }
|
| The above generates 100+ instructions, _without_ inlining the
| floating-point operations that are left as library calls (see [1]
| for a Compiler Explorer view).
|
| Normally you'd expect code like that to use 8-bit variables
| wherever possible, and perhaps stretching to 16-bit numbers when
| more range is needed such as when computing the above PWM value.
|
| [1]: https://godbolt.org/z/PvP5jsrnG
| neonate wrote:
| Part 1 is here: https://interruptlabs.ca/2022/07/29/I-m-Building-
| a-Self-Dest...
| jonas-w wrote:
| I don't think this is a good way to initiate the destruction.
|
| Washing hands, sweating, condensation from beverages, etc. could
| easily trigger this.
| [deleted]
| ChrisClark wrote:
| But you want to trigger it, to keep the data safe. Though if
| the adversary has sweaty fingers they also get your data.
| imglorp wrote:
| You could use a scheme kind of like how port-knocking works.
| For example, plugging in directly causes self-destruct, but
| plug and unplugging twice in 5 seconds will be the "okay it's
| me" signal.
|
| This could be implemented by writing a timestamp file on
| wakeup.
| pjerem wrote:
| > This could be implemented by writing a timestamp file on
| wakeup.
|
| You'd need to embed a clock and an energy source to keep
| the clock going.
| morcheeba wrote:
| A 150uF capacitor should keep the microcontroller running
| for about 5 seconds without power; it could keep time.
| 7.3mm x 4.3mm x 2.9mm
| nyanpasu64 wrote:
| I have the flash drive pictured in the first image of Part 1, and
| I'd say it, almost self-destructs on its own purely from
| overheating. If you plug it in or read it, it gets hot, and if
| you write to it it gets rapidly hotter. I've never tried writing
| gigabytes, but some people online say it gets so hot the drive
| slows down and eventually starts throwing errors instead of
| writing data, until it gets a chance to cool down.
| mindslight wrote:
| First, a specification for Maximum Voltage does not imply that it
| is also a contract for the Minimum Voltage Required to Destroy
| Device. And even if it were, you're still missing a spec for the
| current/power required to destroy the device. I would guess that
| the maximum voltage spec is based on the forward/reverse voltages
| of the body diode (hence the alternative -0.6v rating that would
| actually be easier to hit with no voltage doubler), rather than
| say gate punch through. Thus you're going to need a lot of
| _energy_ to create the heat required to cook the silicon. Your
| chip may desolder itself from the board before it 's been
| appreciably damaged.
|
| But really, apart from the novelty, why attempt to destroy the
| chip in the first place? Encrypt the bulk flash memory, store the
| key in supercap backed SRAM, and then zero out and short the RAM
| when triggered. Then you'd have a reusable device in case of
| inadvertent triggering. You could even load it with a key from a
| trusted host computer (stored on the computer or derived from
| passphrase), gain safety for transporting your files while
| walking around and plugging in to less trusted computers), and
| then if you did accidentally trigger the device, simply reload
| the key afterwards when you got back to the trusted computer and
| not have to rewrite the flash. The utility of such reloading
| functionality would depend on your threat model, but could be
| very useful for a lot of people. Perhaps border crossings.
|
| Since we're on the topic of bespoke crypto ideas, I've often
| mused about the possibility of a probabilistic KDF that would
| take a lengthy amount of time to derive the key, and/or be
| resilient to typos in the passphrase. Rather than doing a fixed
| number of rounds that take a few seconds to derive the key xor
| failure, there would be additional random bits that had to be
| derived via hash collision finding, stretching out the time. Such
| a thing could be resistant to typos or omissions of words in the
| passphrase, with the result that such errors would increase the
| time even more. Thus, until the KDF reported success, an attacker
| would not know whether you gave them the correct passphrase and
| they just need more time, or whether you were stalling.
| bArray wrote:
| > Thus you're going to need a lot of energy to create the heat
| required to cook the silicon. Your chip may desolder itself
| from the board before it's been appreciably damaged.
|
| Yeah, this is a really weird and unreliable method for killing
| the flash. I would be more inclined to go the route of super
| high voltage.
|
| > Encrypt the bulk flash memory, store the key in supercap
| backed SRAM, and then zero out and short the RAM when
| triggered.
|
| Probably the easiest method for sure is a decryption key. Older
| style flash could also be erased using UV, but it seems like
| this is now not the case.
|
| I'm not entirely sure about using moisture as a method for
| ensuring the USB device is interacted with in a certain way. I
| would probably consider some other options:
|
| * A few holes with light sensors that check for a binary code
| as the stick is inserted.
|
| * A covert fingerprint sensor.
|
| * DIP switches that are somewhat hidden. Perhaps on first entry
| an LED flashes, and you must set the switches in response to
| the sequence. In this case somebody could watch you do it and
| still not understand what they must do.
|
| * Perhaps even something as simple as unplugging it and
| plugging it in several times.
|
| All of these seem somewhat more reliable that the resistance
| you happen to create when licking you fingers, and are harder
| to replicate.
|
| As you say, having it so that just the encryption code is lost
| means that you could recover the device by loading in the
| correct key again.
| [deleted]
| mindslight wrote:
| That's really not applicable to the method I laid out, where
| the only copy of the key is erased. If the attacker knows the
| details of the self destruct, the know the key is gone. If
| they don't know the details of the self destruct, they know
| the device is dead, same as OP's solution. The point of the
| crypto is to make it so that the entire bulk memory does not
| have to be erased/destroyed. Some showmanship to lead
| uninformed thugs to the conclusion of "it's too late" might
| be a good thing, but essentially orthogonal to the method
| used.
|
| For the recovery option I laid out, one possible reply would
| be "The key to unlock the drive is back in my home country,
| and I don't have it".
|
| In general that XKCD misses the forest from the trees. Yes,
| the rare lone individual is never going to stand up to any
| determined attacker, but getting technology into the hands of
| many people who widely use it for mostly innocuous things
| certainly could.
| _Adam wrote:
| Exactly - and that maximum is the "minimum maximum" across all
| batches of the device. You might get a particularly resilient
| one that handles the 10V just fine.
|
| The encryption idea makes way more sense, and the means to
| short out the cap doesn't even require the device to be
| powered. The only implementation challenge is that now instead
| of combining a simple circuit with an off-the-shelf mass
| storage controller, you need to either find one that can read a
| key from an external source or roll your own using a micro
| (maybe this is easy with existing libraries?). But if I was a
| journalist concerned about such things I'd rather pay a premium
| for the right solution than worry that the police might be
| sweating from the heat or that the chip in my drive happened to
| be especially resilient to overvoltage.
| [deleted]
___________________________________________________________________
(page generated 2022-09-19 23:01 UTC)