Live data from Hacker News

I'm Building a Self-Destructing USB Drive Part 2

interruptlabs.ca

31–40 of 57 posts

Re: I'm Building a Self-Destructing USB Drive Part 2

#31

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…

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

Re: I'm Building a Self-Destructing USB Drive Part 2

#32

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 p…

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

Re: I'm Building a Self-Destructing USB Drive Part 2

#33

Does this actually prevent forensics from finding any data?

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.

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.

Re: I'm Building a Self-Destructing USB Drive Part 2

#34

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…

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.

Re: I'm Building a Self-Destructing USB Drive Part 2

#35
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

Re: I'm Building a Self-Destructing USB Drive Part 2

#36

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…

[deleted]

Re: I'm Building a Self-Destructing USB Drive Part 2

#38

Earlier quoted context omitted.

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

Ah, yeah, I could see how that might help if it's robbers trying to get your bank pw/wallet key.

Re: I'm Building a Self-Destructing USB Drive Part 2

#39
post #36

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…

[deleted]

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.

Re: I'm Building a Self-Destructing USB Drive Part 2

#40

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…

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

Post reply on HN