It's for organizations that have different standards.
For example, the DoD has a pretty strict standard w.r.t. erasing traditional magnetic hard drives, even though `dd of=/dev/zero` should be good enough. Attacks at that point are theoretical, but they want defenses against theoretical attacks.
For one, the green button may not be fast enough. There are many ways flash cells can be killed en masse. Individually rewriting each cell would take much longer. Someone can then pull the plug and stop the entire process.
I guess these buttons have to be installed in some way that they are easily and quickly pressed in case of emergency before the enemy gets the equipment (so w/o opening your notebook i.e.). But then every colleague running past my desk can quickly trash my SSD. Probably a remote triggering the buttons via software makes more sense.
Were you expecting more or less of a dramatic moment? I've fried robotic parts before, and you really do get a small puff of acrid smoke. Things usually melt and turn black in my experience instead of cracking, but then, I've never zapped a big array of flash memory.
I think triggering an overwrite of all memory with random data by pressing a short sequence of on-unit buttons would be more practical when you're smuggling data through Jinnah international airport and the authorities seize you.
I mean you want to destroy your computing equipment for 2 reasons.
1) Its end of life cycle. In this situation you have plenty of time to do what you want.
2) The enemy is upon you. In this situation you are very short on time.
For situation 2 I would have thought burning or blowing up the computers would be a better solution than trying to quickly unscrew the case. Find the cable. Find the hole to plug the cable in. Press the button. Move onto next hard drive / system.
For situation 1 I would have thought that destroying them another way would be just as effective. You would also have the advantage of not having self destructing hard drives in key systems which could malfunction / be exploited / triggered because someone pressed the red button to erase by mistake.
The only use case I can think of is hackers / pirates / terrorists. I could see them running a computer which has the red button ready to go and taped to the outside of the case to destroy evidence as soon as police try to kick down your front door.
"The only use case I can think of is hackers / pirates / terrorists. I could see them running a computer which has the red button ready to go and taped to the outside of the case to destroy evidence as soon as police try to kick down your front door."
I'd imagine this was the manufacturer's intention. If you're going to the trouble of building a computer with an instant self-destruct feature, you'll probably put the button somewhere accessible.
What's the point of the green button (overwriting data with random garbage), if you can have an encrypted drive, which means you have random garbage on it all the time, lest you have the key. Well, maybe that's how it works (erasing the encryption key), though in this case there is no point of doing it remotely.
In this case the red button is not that important either. The only thing they could be used is when you are tortured to give away the decryption key (or passphrase) for the drive. By pressing the red button, you could convince the bad guys, that they won't be able to read the data anyway. The green button would not save your arse, since they may just think that you gave them the wrong key.
This movie clip feels like it could be featured in a dystopian sci-fi movie in which a big corporation has all the power. Just waiting for Deckard to walk by a billboard and see this playing.
I'm really surprised that they implement "destroy all data" by physically overwriting the flash cells. This is commonly (e.g. iPhone) done by storing all data encrypted with a randomly-chosen key and just throwing away the key to "delete" it, which is a much faster way to destroy a drive. And it's not like Flash drives can function without a somewhat complicated controller anyway...
EDIT: clarified in response to DanBlake (and hackermom, who has just been hellbanned.)
So reading the data, applying crypto on the data, and then writing it back, is faster than just writing random data to the same cells to erase the data? How?
Edit - Adding my response here for later reading when the ridiculous hellbanning that filtered me and another user from the discussion is lifted...:
There's a problem with your theory here, in how you (and others responding to DanBlake's question) have misunderstood how a flash memory device works. How can the user or operating system, on software level, select a definite block of data for "zeroing out" when the storage medium is an SSD where wear-levelling is always present and ultimately what controls, on lowest possible level, what memory cell data is going to be written to? To my knowledge - and do correct me if I'm wrong - this is not doable on an SSD, and you thusly have to overwrite the entire SSD to be certain that the memory cell holding the key is erased. This is how flash memory controllers work - they always write data to the next free block, remap the old block and then marks it as unoccupied in the BAM.
If the case is a mobile unit that may have a small portion of separate PRAM or similar where you can store crypto keys, the principle is the same there as that's also a flash type memory, even if a much smaller one that is faster to erase. However, that solution isn't usually available in a "normal computer", nor available to a "normal OS", which are the two targets of SSD drives.
If you encrypt the data, you only have to zero out the key (nanoseconds? maybe microseconds) instead of zeroing all the data. Assuming there is no backup of the key, the data is just as gone as if you'd zeroed it.
What JonnieCache and DanBC say: keep the data encrypted at all times, then you can just overwrite the few bytes of the encryption key to render the data unreadable. This has the additional advantage that you only need to really securely erase a very small amount of storage (plus the controller's memory.)
(Editing my original post to make this more clear. Sorry.)
Oh, I thought you mean "as you push it" encryption.
When I was in the military, Encrypting data was not acceptable for disposal though. They make you physically destroy it, which is why I imagine they do things in this manner.
Yes, physically destroying drives prevents problems ("oh that wasn't encrypted?", "turns out it still had parts of unencrypted data on it from the previous server it was installed in", "what do you mean 'encrypted according to 1995 standards' (DES) is no longer secure?"). It's a good policy; but if you offer both "destroy" and "erase", "my" crypto implementation of "erase" has a lot to recommend it. (And there's no reason you can't follow it with a good zero-everything.)
That approach does have the advantage of speed, but it's not really a substitute for physically overwriting all the data.
History is rife with examples of people getting themselves into serious hot water by assuming that the lack of a well-known weakness in a cipher means that the cipher is secure. Anyone who's got an extremely high need for data security is hopefully keenly aware of that.
The data is stored encrypted by default, then once the key is discarded you no longer have data, just encrypted gibberish; all without writing to any of the disk where the data was. Much, much faster than having to zero out the whole disk
Clearly this is insufficient, it needs a pound or two of HMX. At a detonation velocity of 9100m/s, it should take care of the data (and everything else) just as fast.
On a more serious note however, how hard would it be to break the encryption, especially if one were able to develop a sufficiently advanced computer in the future (ie. quantum computer)?
Theoretically, information is information, encrypted or not, and just because the key is zeroed out doesn't mean part of the original information cannot be obtained from encrypted data. For example, an infinitely fast brute-force algorithm could crack it, as well as a lucky guess, however unlikely. If the key is weak relative to the strength of the cracking algorithm/hardware and the cost of leaking information, then this doesn't work.
Due to the ridiculous hellban that occured I'm posting my intended but disallowed response using this temporary user, because I feel that getting the explanation out about how solid state memory devices operate is important to the discussion and to clear misunderstandings that people may have regarding safe erasion of data on flash memory:
There's a problem with your theory here, in how you (and others responding to DanBlake's question) have misunderstood how a flash memory device works. How can the user or operating system, on software level, select a definite block of data for "zeroing out" when the storage medium is an SSD where wear-levelling is always present and ultimately what controls, on lowest possible level, what memory cell data is going to be written to? To my knowledge - and do correct me if I'm wrong - this is not doable on an SSD, and you thusly have to overwrite the entire SSD to be certain that the memory cell holding the key is erased. This is how flash memory controllers work - they always write data to the next free block, remap the old block and then marks it as unoccupied in the BAM.
If the case is a mobile unit that may have a small portion of separate PRAM or similar where you can store crypto keys, the principle is the same there as that's also a flash type memory, even if a much smaller one that is faster to erase. However, that solution isn't usually available in a "normal computer", nor available to a "normal OS", which are the two targets of SSD drives.
Yes, SSDs set a portion of the disk aside for wear-leveling, so even writing zeroes to the entire disk from the OS does not guarantee that the data is completely destroyed. (Similarly, hard disks may hold secret data in bad sectors.)
However, this device has these capabilities baked into it at the firmware level, and the firmware can address individual cells. (Similarly, the controller can include a small amount of non-volatile securely-erasable memory for the key.)
I just wasted 5 minutes trying to find a link to post here. It was an article where two hackers decided to actually try out all the various hard disk destruction methods people postulate, with a view to making a remote self-destruct mechanism. They posted lots of photos of different things they tried, and an amusing write up of their escapades: they burned them with fire, attacked them with acid, masonry drills, other chemicals, almost maiming themselves and annihilating their garage a couple of times. If anyone could dregde up the URL for me I'd be most appreciative.
The article is likely about the talk "And That's How I Lost My Eye: Exploring Emergency Data Destruction" at DEFCON 19 [1]. A blog post [2] gives a quick overview, and the 50 minute talk [3] is very entertaining. There's no whitepaper, and I couldn't quickly find a more detailed article.
Does this have an internal battery to ensure that the destruction is complete even if the power source is removed? Otherwise there's an obvious weakness: before raiding the house, cut the power: this will prevent the SSD user from being able to destroy their data.
43 comments
[ 0.16 ms ] story [ 34.2 ms ] threadNo, seriously, this may be pretty useful, especially since the self-destruct mechanism can be hooked up to something else.
The red button is impressive but whats the benefit of trashing the SSD? Or does the green button not erase data with 100% reliability?
For example, the DoD has a pretty strict standard w.r.t. erasing traditional magnetic hard drives, even though `dd of=/dev/zero` should be good enough. Attacks at that point are theoretical, but they want defenses against theoretical attacks.
What if this gets triggered when you don't want it to? You're just adding another list of possible bad shit that can happen.
I rather wished it was not built into the device itself, but you connect it to something else.
Just add another layer of stuff that can go wrong, and this one fries the disk completely.
I mean you want to destroy your computing equipment for 2 reasons.
1) Its end of life cycle. In this situation you have plenty of time to do what you want.
2) The enemy is upon you. In this situation you are very short on time.
For situation 2 I would have thought burning or blowing up the computers would be a better solution than trying to quickly unscrew the case. Find the cable. Find the hole to plug the cable in. Press the button. Move onto next hard drive / system.
For situation 1 I would have thought that destroying them another way would be just as effective. You would also have the advantage of not having self destructing hard drives in key systems which could malfunction / be exploited / triggered because someone pressed the red button to erase by mistake.
The only use case I can think of is hackers / pirates / terrorists. I could see them running a computer which has the red button ready to go and taped to the outside of the case to destroy evidence as soon as police try to kick down your front door.
A dedicated panel switch.
Some of us have been variously labelled all three.
I'd imagine this was the manufacturer's intention. If you're going to the trouble of building a computer with an instant self-destruct feature, you'll probably put the button somewhere accessible.
In this case the red button is not that important either. The only thing they could be used is when you are tortured to give away the decryption key (or passphrase) for the drive. By pressing the red button, you could convince the bad guys, that they won't be able to read the data anyway. The green button would not save your arse, since they may just think that you gave them the wrong key.
EDIT: clarified in response to DanBlake (and hackermom, who has just been hellbanned.)
Edit - Adding my response here for later reading when the ridiculous hellbanning that filtered me and another user from the discussion is lifted...:
There's a problem with your theory here, in how you (and others responding to DanBlake's question) have misunderstood how a flash memory device works. How can the user or operating system, on software level, select a definite block of data for "zeroing out" when the storage medium is an SSD where wear-levelling is always present and ultimately what controls, on lowest possible level, what memory cell data is going to be written to? To my knowledge - and do correct me if I'm wrong - this is not doable on an SSD, and you thusly have to overwrite the entire SSD to be certain that the memory cell holding the key is erased. This is how flash memory controllers work - they always write data to the next free block, remap the old block and then marks it as unoccupied in the BAM.
If the case is a mobile unit that may have a small portion of separate PRAM or similar where you can store crypto keys, the principle is the same there as that's also a flash type memory, even if a much smaller one that is faster to erase. However, that solution isn't usually available in a "normal computer", nor available to a "normal OS", which are the two targets of SSD drives.
Genuinely curious as it seems that would not make sense, if you overwrote it with zeros in a comparable, logical manner.
(Editing my original post to make this more clear. Sorry.)
When I was in the military, Encrypting data was not acceptable for disposal though. They make you physically destroy it, which is why I imagine they do things in this manner.
History is rife with examples of people getting themselves into serious hot water by assuming that the lack of a well-known weakness in a cipher means that the cipher is secure. Anyone who's got an extremely high need for data security is hopefully keenly aware of that.
On a more serious note however, how hard would it be to break the encryption, especially if one were able to develop a sufficiently advanced computer in the future (ie. quantum computer)?
There's a problem with your theory here, in how you (and others responding to DanBlake's question) have misunderstood how a flash memory device works. How can the user or operating system, on software level, select a definite block of data for "zeroing out" when the storage medium is an SSD where wear-levelling is always present and ultimately what controls, on lowest possible level, what memory cell data is going to be written to? To my knowledge - and do correct me if I'm wrong - this is not doable on an SSD, and you thusly have to overwrite the entire SSD to be certain that the memory cell holding the key is erased. This is how flash memory controllers work - they always write data to the next free block, remap the old block and then marks it as unoccupied in the BAM.
If the case is a mobile unit that may have a small portion of separate PRAM or similar where you can store crypto keys, the principle is the same there as that's also a flash type memory, even if a much smaller one that is faster to erase. However, that solution isn't usually available in a "normal computer", nor available to a "normal OS", which are the two targets of SSD drives.
/ hackermom
However, this device has these capabilities baked into it at the firmware level, and the firmware can address individual cells. (Similarly, the controller can include a small amount of non-volatile securely-erasable memory for the key.)
[1] https://www.defcon.org/html/links/dc-archives/dc-19-archive....
[2] http://www.sportsfirings.com/?p=4959
[3] http://www.youtube.com/watch?v=oXbq0BFzQQg
EDIT: yep, it was. You should all watch it, it is most diverting.
Perhaps it's this? DEFCON 19: And That's How I Lost My Eye: Exploring Emergency Data Destruction
(http://www.youtube.com/watch?v=oXbq0BFzQQg)