For almost a year now, we’ve been following the progress [Walker] has been making with Ovrdrive — a completely open source USB flash drive that features the ability to destroy itself should it fall into the wrong hands. It’s an interesting enough project on those merits alone, but what really made this idea stand out was that the user was expected to lick their fingers before handling the drive as a form of covert authentication.
Well, we’ve got some good news and some bad news. The good news is that [Walker] is just about ready to release the Ovrdrive officially on Crowd Supply. But it’s with a heavy heart that we must report that the device’s cutting edge spit-detection capabilities have been removed. Now if you want to preserve the drive’s files, you need to rapidly insert and remove the drive several times rather than just plugging it in.
In all seriousness, this new approach makes a lot more sense. As entertaining as it might have been, the whole idea of a device that could detect moisture on the user’s fingers was fraught with problems. It was a bit more of a meme than a real solution, and if we’re being honest, kind of disgusting. This new approach sounds far more reliable, especially when combined with the new “Lite” self-destruct mode.
While the original capability of literally frying the flash chip by way of several capacitors and a voltage doubler is still here, there’s also a non-destructive approach that’s enabled by default. Unless you open up the drive and desolder the jumper pad on the PCB, the onboard ATtiny24A will simply use the enable pin on the flash chip to make it appear empty. This means that you’ve got to really want to cook your flash chip on the first hint of funny business.
Ultimately, whether it’s self-destructing or not, we just really like the idea of a hacker-developed open source hardware USB flash drive. Admittedly it would be a lot cheaper and more practical to just buy one like a normal person, but we strongly believe that if there’s a way for the community to build a OSHW version of something, they should at least give it a shot.
I’m curious about the kind of damage that is done by overvolting the flash chip. If I were really so paranoid to have a self-destructing flash drive, I would prefer to use encryption and wipe the keys, instead of depending on the attacker’s inability to reconstruct the damaged parts of the IC. My guess would be that the flash cells themselves can survive the “self-destruct”
I also think the flash cells would survive, but assuming the drive/control circuitry to multiplex reading them are toasted then it’d make is much more difficult getting the data out (think decapping and probing the bare metal address lines to manually step through the whole memory). This isn’t even accounting for not having the mapping info either. Sure not impossible, but definitely more difficult.
Yeah, that’s a really half-assed amateur-hour approach to trying to erase anything.
The other nice thing about wiping crypto keys is that, if you do it right, you can make a duress-erased drive indistinguishable from a drive that simply happens to be blank, which can, if you’re lucky, leave your adversary at least a LITTLE confused about what actually happened.
Oh, and you could probably do it in firmware on an off-the-shelf drive, so you weren’t carrying around a device that screams “suspect me”, and puts the person who took your drive on notice to do a simple Google search and find out what dance they need to do to defeat your protection.
It’s not obvious who you think your adversary is, or how you think they’re going to respond either to the drive erasing itself or to finding out it was *supposed* to erase itself. There are very few threat models where you want such responses to happen.
That whole project is the sort of thing you ought to think of, think ABOUT, and realize within 30 seconds why you shouldn’t do it.
Obligatory XKCD
https://xkcd.com/538/
Doesn’t work if the item is destroyed pyrotechnically…
Who is going to be interested in what is on some random guys flash drive? What information do you have that is that sensitive or valuable that it warrants something like this? Anyone who would have a reason to use something like this is going to use other, more secure methods, not some open source project. I bet you data forensics people know all about these sort of devices anyway.
“…There are very few threat models where you want such responses to happen…”
The point is normalization into ubiquity.
Having an encrypted hard drive in the 90s made you stand out.
Now? A big percentage of people’s everyday carry devices are encrypted by default.
It’s normal.
Is a self destructing drive ever going to become the norm?
Probably not.
But industrial/state espionage is definitely a thing.
I could see a better implementation of this being useful in plenty of real world in-transit situations.
> The point is normalization into ubiquity.
If it becomes *ubiquitous*, you can’t use things like plugging and unplugging, licking your fingers, or waving rubber chickens to make the drive give up its content. You have to do real authentication, so that your drive and mine aren’t unlocked in the same way, and an attacker can’t guess how to unlock a given drive.
Actually even this project, which is far from ubiquity, has been talked about enough to seriously damage any utility it might otherwise have had.
If there’s actually a ubiquitous approach, you end up with a situation that’s very similar to an encrypted drive, where the Bad Guys(TM) can’t read the data unless they can rubber hose the password (or password-like thing) out of the drive’s owner… and they *know* that.
As long as you’re asking for passwords, you really want to encrypt the data anyway. So you have a classic duress code system: there’s a “real” code that unlocks the data, and at least one duress code that does something else.
Standard ideas for the duress response are:
1. Wipe the crypto keys so the data can’t be read, and
a. Have the drive explicitly indicate that it’s been wiped, or
b. Put the drive in a state where it might have just wiped itself, but might equally have been erased at some previous time, for completely “legitimate” purposes… or just be blank from the factory. This is better in most rubber hose situations, because uncertainty about whether you denied them real data might somewhat reduces the chance that some actors will hose you more in retaliation. There are tricky parts to making those cases hard to distinguish, and you can always make a mistake, but you have a good chance of success if you do it right.
2. Try to brick the drive entirely. This is inferior to number (1) in every way. Short of thermite, it’s less secure. It wastes a perfectly good drive for no good reason. And it’s at least as likely to provoke retaliation as either (1) option.
3. Pretend to be a smaller drive with innocent content. But that’s security by obscurity that won’t work in a “ubiquitous” world, in the same way that magic dances won’t. If your drive were the *only* one that acted like that, it would probably fool a lot of people, even professionals… but not if *everybody’s* drive were known to do that.
> But industrial/state espionage is definitely a thing.
Rubber hose espionage isn’t the common case, though. There may be SOME people who have that problem, but MOST people can defeat all the realistic espionage threats that would be addressed by any duress system, just by encrypting the drive, which you can already do.
Even if you ARE worried about rubber hosing, you can sometimes deal with it by just making sure that the person carrying the drive doesn’t know the password until they and the drive get to some safe destination.
> I could see a better implementation of this being useful in plenty of real world in-transit situations.
Against *espionage*? I think that’s a stretch.
Where things like this really come into their own is against lawful (as opposed to legitimate) action by state actors or quasi-state actors. For example, if you get grabbed for sedition, they may want to get the names of the rest of your network off of your drive. If I remember right, that was the original idea behind this project.
But in that case you’re walking a fine line. Your adversary has to be violent enough (and maybe unlawful enough) to do something meaningfully bad to you if you don’t fork over the data. At the same time they have to *not* be willing to do that bad thing if they know or suspect that you’ve deliberately made the data permanently unavailable. I won’t say that *nobody* meets those criteria, but it’s not very many adversaries.
If you do obvious things like bricking the drive, you convert “know or suspect” to “definitely know”, and at that point there’s almost no plausible adversary who won’t retaliate. And of course, as you pointed out, having an obscure type of drive that’s only special because it can do this is that kind of obvious thing.
The PCB looks well designed, kudos for that.
Although I doubt that the “self-destruct” feature adds to the security of your data.
This design is open source, so it’s probably very easy to circumvent the protection (cut some traces, reflash the attiny with non-destructive firmware) to prevent the data from being inaccessible.
BTW, to get to the data of the flash chip, there’s no need to power up the USB-stick. You could desolder the flash chip and solder it onto some custom devboard and read it out. That’s probably what data recovery services will do when you hand them over this device.
Once the data is recovered, you could start decrypting it (in case it was). That will be the hardest part of the whole operation.
“This design is open source, so it’s probably very easy…”
What that actually means is IF it is done well then it is as secure as can be. Remember, good security is in a system where the “key” is the secret and the method is openly shared. All manner of proprietary things may claim perfect security, but could be far from the truth. With open source you know what you’re getting. Easy circumvention of protections is usually what happens with proprietary stuff, because the manufacturer thought nobody would realise a big flaw because they didn’t document it, for open source if the protections were well designed then circumvention could be truly properly impossible.
In stock configuration all this drive does is not enable the flash chip, anyone interested enough would then just assume the controller is broken and desolder the flash chip. So in short this device is useless except from preventing an average person from seeing what is on it, but encryption would do that anyway. Also what information does the average maker have anyway that warrants this? If you do have sensitive or valuable information there are other ways to secure it much better than this.
It should require that it be inserted, flipped, inserted, flipped, inserted, flipped, etc in a certain pattern.
Then it’d look like entirely normal behavior so nobody would catch on.
Reminds me of an old James Bond movie where he plays with an explosive ball pen. 😉 But I don’t remember which one.
GoldenEye is certainly getting “old”, having come out in 1995, but it’s not one of the oldest Bond films.
Sure Grampa (don’t get me wrong, I also feel like 1995 was not THAT long ago…)
There was a Roger Moore Bond film in the early 1980s that had an exploding fountain pen (IIRC). Octopussy?
Not a half bad idea – pack an accelerometer in there…
Could the drive have a thumb recognition circuit added. It gets trained once and then when you insert the drive in the usb slot it checks the thumb. If if does not recognized the pattern, it turn every read into a write of random data.
Those are available commercially for quite a long time already.
But putting some alternative firmware in them could add some interesting functionality…
Why not just have a small button on the side? Push the button it’s fine, don’t it’s toast.
I don’t like the idea of inserting the thing multiple times quickly.
But lot’s of alternative methods could be devised.
What about inserting it slowly (time delay between Vcc and data lines)
Accessing a certain file. within a time limit.
Writing a text file which contains a “password”
MEMS microphones are quite small these day’s. You can tap some morse (for example with a pen) on the casing, but an accelerometer could also pick that up.
And security though obscurity can also be a modest part of the equation.
Such as having a default USB disk that is “harmless” and hiding a second “partition”, and erasing the type number of a FLASH chip can obscure it’s size.
And there are plenty more options.
The idea of a suicidal thumb drive reminds me of ALL the Mission Impossible episodes/movies where in the mission brief is delivered in a self-destructing audio/video format that inevitably went up in smoke.
I think a thumb drive that simply and harmlessly releases smoke when accessed would make a cool gift.
That’s called vape
What about a flash drive with three ‘sections’
A normal unencrypted freely accessible section that has some innocent files, then the two encrypted sections for the plausible deniability thing, one with faux ‘sensitive’ information and the other with the real juicy stuff.
Unlock either with a file name as the password.
No physical stuff to be probed. Just one filename unlocks the decoy encryption, another unlocks the real encryptied section and a third nukes the lot.
This is all very neat and funny, but the best way I can think of doing something like that is simply a VeraCrypt drive with a “normal” volume and a hidden volume. On the hidden volume you keep your top secret compromising whatever files and in the normal volume you keep some private data that is convincingly worth of protection, hell even some dickpics or whatever just to troll the evil guys.
Then you can easily give up your passphrase after some resistance and the evil guys have their content. The hidden volume can not be detected.
The keyword here is plausible deniability.
I build a proof of concept similar to this, but using an SRAM chip instead of flash memory. A capacitor kept the contents of RAM for around 26 hours. There was also a button on it that wiped it instantly.
The amount of data it could store was small, but enough for things like encryption keys. You could probably eliminate the SRAM and use a microcontroller’s internal RAM. The advantage of that would be that the erase button wouldn’t just remove power, it could actually trigger code in the MCU to overwrite the data.