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.
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.
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.
> 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.
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.
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.
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.