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