I'm Building a Self-Destructing USB Drive Part 2(interruptlabs.ca)
interruptlabs.ca
I'm Building a Self-Destructing USB Drive Part 2
https://interruptlabs.ca/2022/08/31/I-m-Building-a-Self-Destructing-USB-Drive-Part-2/
56 comments
Part 1 is here: https://interruptlabs.ca/2022/07/29/I-m-Building-a-Self-Dest...
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.
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.
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.
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.
Back in ~2014, I had a newish 32Gb USB3 flash drive. At that time, premium mainboards had FireWire headers for front panel connectors, on board as well as USB2. Both are 2x5 headers and can easily be smashed on if the connector keying isn't really well done. The FireWire header can deliver 12v (apparently it can be "8-30v" but real PCs tended to deliver the voltage they had available). You can see where this went.
After being inserted in, the drive was dead on USB2. On USB3 it would work for a few minutes at a time. This became relevant when I discovered the drive still worked in that few-minutes-at-a-time fashion in 2021 and contained my old wallet with 30,000 Dogecoin on it.
After being inserted in, the drive was dead on USB2. On USB3 it would work for a few minutes at a time. This became relevant when I discovered the drive still worked in that few-minutes-at-a-time fashion in 2021 and contained my old wallet with 30,000 Dogecoin on it.
I really like the idea of a failsafe, where if the device is locked in a cabinet for a month it becomes unusable.
> 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.
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.
Bonus points for a USB stick that with the correct knock algorithm (plug in 3 times, unplug for 10 seconds, plug in again) presents a secret partition, otherwise presents a dummy partition.
With an USB C stick, you could have a knock algorithm that involves plugging it in with a particular orientation pattern as well.
Technically speaking, you could probably also develop a USB-A that could do the same thing with a little mechanical and electric configuration.
eMMC already contains an area that can be used for this sort of thing:
https://en.wikipedia.org/wiki/Replay_Protected_Memory_Block
https://en.wikipedia.org/wiki/Replay_Protected_Memory_Block
By that Wikipedia description I don't really see how it could be used for such.
[deleted](1)
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:
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
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;
}
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
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".
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".
I searched several variations on that, but couldn't find what you're referring to. Do you have a link?
I believe it's her "Emergency USB Drive Destroyer"
https://www.youtube.com/watch?v=Gg0sdeAwN5A
https://www.youtube.com/watch?v=Gg0sdeAwN5A
Ah, yeah, I could see how that might help if it's robbers trying to get your bank pw/wallet key.
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.
wouldn't the act of destroying the drive be enough to convict anyway?
Yes, but they could not, for instance get data on or conversations I've had with other people and go after them. A firestop of sorts. It's far from a universal solution, just a very low tech, very theatrical option for very specific threat models
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.
How about authenticating with an accelerometer rather than through skin conductivity? To unlock your USB device, or to avoid the self-destruct, you would wave it, tap it, spin it, or rotate it in a specific way before plugging it in.
Accelerometers are widely used by smartphones so I assume that the ICs are common and inexpensive (at least if bought in volume). A tiny battery would be needed as well.
Carrying the idea even further, maybe you could even do key entry this way. Imagine that the USB device stores encrypted data and you enter a short decryption key by tapping out a particular bit of music before plugging it in.
To get even fancier, maybe you can enter a hexadecimal key (0123456789ABCDEF) through various motions. For example, spinning the USB clockwise on your desk is a 0, flipping it from horizontal to vertical is a 1, waving it through a figure eight loop is an 8, rolling it along the long axis is a B, etc.
Accelerometers are widely used by smartphones so I assume that the ICs are common and inexpensive (at least if bought in volume). A tiny battery would be needed as well.
Carrying the idea even further, maybe you could even do key entry this way. Imagine that the USB device stores encrypted data and you enter a short decryption key by tapping out a particular bit of music before plugging it in.
To get even fancier, maybe you can enter a hexadecimal key (0123456789ABCDEF) through various motions. For example, spinning the USB clockwise on your desk is a 0, flipping it from horizontal to vertical is a 1, waving it through a figure eight loop is an 8, rolling it along the long axis is a B, etc.
Does this actually prevent forensics from finding any data?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
How is that not what's being described here? The dead-man switch signal is to moisten your fingers before plugging it in.
[deleted]
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!
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.
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.
Not at all.
Why not? If the data is zeroed, there wouldn't be anything to find by forensics.
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.
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
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.
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.
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).
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).
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.
I would like to have seen something that triggers when the user says "by all means, have a look; I have nothing to hide".
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.
I don't think this is a good way to initiate the destruction.
Washing hands, sweating, condensation from beverages, etc. could easily trigger this.
Washing hands, sweating, condensation from beverages, etc. could easily trigger this.
But you want to trigger it, to keep the data safe. Though if the adversary has sweaty fingers they also get your data.
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.
This could be implemented by writing a timestamp file on wakeup.
[deleted]
I'm not convinced that destroying the flash chip makes it more secure. Erasing the chip should be secure and fast enough. Damaging it with overvoltage might leave the data recoverable.
How does it differentiate between licked fingers and sweaty hands?
Why use a micro at all? You could have implemented the entire circuit with a couple extra discrete components to reduce complexity.
[deleted]
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.
It's a USB key, not a floppy. Magnets do not affect Flash storage. Typical (austentic) stainless steels do not attenuate magnetic flux.