In research that has important findings for banks, businesses and security buffs everywhere, scientists have found that computer files stored on solid state drives are sometimes impossible to delete using traditional disk-erasure techniques. Even when the next-generation storage devices show that files have been deleted, as …
One way around this problem...
... is to physically destroy the devices, which is what the *really* paranoid do. Granted, this wouldn't work out too well for companies that send their old kit to a company that refurbishes and resells the stuff ('asset recovery' is the usual name given to this process), as they tend to like having working storage devices to sell along with the equipment in question.
Interesting article otherwise- This is actually ammunition for not having corporates buy SSDs at this time.
HMG's Secure Erasure
Involves grinding the drives into dust in a large shredding machine.
The moral of the story is if you must put it on a flash drive encrypt it. Mind you the brain power involved to workout that methods used for erasing magnetic disks don't work on solid state is mind boggling, but a timely reminder none the less.
Secure data disposal?
May I suggest a 4lb lump hammer - also suitable for hard drives.
Safety goggles optional (but highly recommended).
You can suggest it mate
but have you ever tried it? All you get is a bloody loud ringing sound unless you have glass platters on the HDD.
not safe enough for all purposes
Ros Anderson refers to research in his book 'Security Engineering' where explosives were not considered up to the job of destroying on-chip data where fragments of over a certain small size remained, if the data was particularly sensitive, e.g. nuclear weapons launch codes and the attacker well enough funded.
There's a simple, cheap method....
....but it would require a large airy environment and serious care while the process is used.
Thermite, it's cheap and very effective at rendering the whole device unusable, it's what was used to render magnetic core memory useless in the event of capture on military equipment.
Yes, I've used it. It does require a modicum of intelligence (support the drive at the two shorter ends) and a little physical strength, but the end result is a V-shaped device from which it would be 'challenging' to recover any usable data. I've not actually tried it with SSDs, but I can't see why it wouldn't be equally effective (the casing is less robust, but you'd want to make sure you'd mangled each chip inside). For those lacking the physical strength (or intelligence), there are mechanical devices such as Bustadrive (Google it).
But ultimately the answer is physical destruction, for which a large number of solutions are available, up to and including shredding followed by liquidation. There's no real market for recycled SSDs (at least, I would never buy them), because the storage degrades with use.
Stick it in a vice and drill holes through the platters. Then stuff in an incinerator for a nice roasting along with you garden waste, just to burn off the top layer treatment of the platters, let it cool and drop it off at the scrap metal bin in your local council waste depot.
I wait until I have half a dozen to do once a year, from friends and family.
Yes - regularly when I upgrade drives. But I also use a large screw driver. Punch a hole through the electronics and the drive platter and that vigorously wind the screwdriver around what now remains of the platters.
It's call hardware - and when I have finished it is useful only as scrap.
Goggles and breathing mask highly advised.
Hammer and Pliers
I read something last week about some hedge fund crooks erasing flash drives with hammers and pliers. Perhaps I can find my old UV eprom eraser, once I get the opaque cases off. Moving up the spectrum, an unhealthy dose of X or Gamma will work without removing the cases.
Secure delete... let me think...
River Thames (+ Concrete?)
So little time...
Anyone who does serious data recovery will tell you fire doesn't do it with magnetic media. I suspect flash based media doesn't fare as well, but it can probably be at least partially recovered from all but the hottest fires.
Don't make me laugh. At least some of the chips will be more or less intact after that. All the data on an intact chip would be recoverable. Some of the data on broken chips would even be recoverable with the right equipment.
>River Thames (+ Concrete?)
Niether water (while the drive is unpowered) nor concrete will harm the data on a flash device.
Personally I'd have to go with what someone else said. Thermite. There won't be anything left of the chips after that.
"Anyone who does serious data recovery will tell you fire doesn't do it with magnetic media. I suspect flash based media doesn't fare as well, but it can probably be at least partially recovered from all but the hottest fires."
Do not make me laugh man
"Don't make me laugh. At least some of the chips will be more or less intact after that. All the data on an intact chip would be recoverable. Some of the data on broken chips would even be recoverable with the right equipment."
I want what you smoke.
Regarding the river solution, I trully doubt that you will ever figure out where I dumped the thing, nor if you find a concrete slump that there's anything inside.
But here it is for you, burned, smashed, rolled under a car, a bus, and finally dropped inside a concrete lump into river thames from London Bridge.
Stop watching so many james bond movies mate, they'll do you no good.
Actually this is about the only way to secure a flash drive.
Although consigning it to a wood stove might be more effective than a hammer.
The little bits wear out, you see.
So the next write modifying the same file might just make a duplicate.
And the 200dreth write after that might get around to reusing those first bits.
After a while a flash drive is a mess, a very well considered mess, but a mess.
Run the old DOS program core on one; ouch.
From a company standpoint, only idiots would consider selling used flash drives.
New word, ubiquitous.
(a prevalence of idiots.)
Fill it with random data, then it will have to overwrite what you have deleted.
Actually it won't
These devices use something called "wear leveling" and have some capacity above the rated or visible space.
This capacity is swapped out using some algorithm stored in its own controller, which is why most of methods where unable to erase everything.
re: Fill it with random data
That will wipe most of it, but you can't guarantee that it will get it all - when a block produces an error it is marked as bad, and any attempt to write the whole device will skip any bad blocks, but each block (128kB?) could be complete and readable with only a single bit out of place.
Wear levelling != extra storage..
Sorry; but wear levelling just means that the writes to the device are spread very evenly across it (due to the limited number of write-cycles available to each storage cell). It does not mean that there is spare capacity which is only brought into play when needed. Trust me; drive manufacturers like big numbers; if there was really 80Gb of capacity on a '40Gb' SSD they would find some weasely way of trying to sell it as an 80Gb drive...
A '$ cat /dev/urandom > /dev/ssd' will go a long way towards preventing your data being accessed.
That said; Mechanically mangling will generally be faster and easier.
Fail @Owen Carter
wear leveling "hidden space" is in fact extra storage. SSDs are a particular creature. Data tends to be a copy-on-write setup, so when you overwrite your file, the new copy (parts of it at least) end up elsewhere on the drive and the old data gets flagged as available (whether it gets used or not is based on the write-count). That "elsewhere on the drive" can be within the CONCEPTUAL capacity of the drive, or land in that over-provisioned wear-leveling space. The controller doesn't care, it just doesn't want you to fill up the full 120GB of your "100GB" drive, because it is greedy and wants to maintain peak performance with its wear-leveling.
Storage locations on an SSD are a moving target, and that is the point MANY people (including these researchers) seem to forget. They're talking about traditional HDD "shred" techniques and then getting shocked that not even a "defrag" overwrites the data. They tried sequential overwrite methods, which with the above explanation of over-provisioning and a bit of brain power, one would realize would be ineffective.
A bit of intelligence shines through when they say the best way to "sanitize data on SSDs was to use devices that encrypted their contents." Bingo. Many SSD /drives/ do this. Granted they have a point about purging the crypto keys, but that's easy enough by grinding the chippery, or the thermite option.
Lastly: "Furthermore, there is no way to verify that erasure has occurred (e.g., by dismantling the drive)." is utter bullocks, as I can tell straight away that a drive that's had its flash chips melted by thermite (or perhaps dissolved in an acid bath) is cleanly "erased" (in proper Ahhh-nold fashion via "Eraser").
Oh, and a P.S. for Mr. write-spam monkey, when an SSD "fails" due to write exhaustion, the last-written data remains in the cell, perfectly accessible to be read. If you had an entire block or even chip fail in your SSD, unbeknownest to you, the data may still be accessible and no amount of continual rewriting will destroy it. Fail 4 u :)
Read the article muppets
Did any of you read the article? Data was recoverable in some cases after 20 full disk rewrites. Thus your random comment were about as useful and relevant as random string pasted to this comments box.
Commentards indeed. Kermits.
Worst flame'ing ever...
Which part of: "will go a long way towards." did you read as 'fully achieve'?
I was replying to a comment about wear levelling.. not a comment about fully destroying the data. I covered that in the 'Mechanically mangling' part :-)
I echo the comments about smashing up drives
Works for tapes, works for disks and it will work for computer chips too.
As the value of the data on the drives becomes exponentially greater than the value of the actual drives this will continue to make more and more sense.
Wasteful maybe, but if you're considering erasing a drive then by that point it will have served the purpose for which you bought it anyway.
The real issue here is not being able to securely erase individual files but what's new? In a corporate environment, by the time you realise you've saved something a little bit dodgy and gone to delete it, it's already sitting in the CEOs inbox.
mate, next one on the pub...
is on me to laugh at the expense of the recovery boys.
Use TrueCrypt to encrypt the SSD
I installed an SSD in my Acer Aspire One notebook, and partitioned the SSD into drives C and D, with a clear demarcation between my Windows 7 system in drive C and my data in drive D. I then encrypted drive D with TrueCrypt. I don't think this will provide 100% security (especially if SSD data is shuffled across two different partitions by TRIM), but I think it will help some. Any insight?
Bitlocker is better for this kind of thing
Bitlocker is in the Windows 7 Kernel and not some file system driver. Also it will only leave 100 MB of unencrypted space(For the boot files) and everything else will be encrypted before it hits the disk, so no worries about someone recovering your data. Also Bitlocker has been optimized like crazy so there isn't a noticeable performance drop in file system activity.
I suggest you read the truecrypt documentation http://www.truecrypt.org/docs/?s=data-leaks
Basically your problem is that most of your "sensitive" files will end up being written unencrypted as software makes temporary files on the unencrypted drive while you're working on the files, which means then you have the problem of not being able to delete that data as mentioned in the article.
Kernel level drivers
TrueCrypt also uses kernel level drivers and can be used for encryption of boot drivers. And it's cross-platform - Mac and Linux too. And you don't need to pay a premium for some fancy version of Windows - it'll work with Starter edition on up.
Thanks for the info
To the three persons (or one person?) who answered me: thanks for the helpful information.
Already proven wrong.
Fail @OP (Robot)
"and partitioned the SSD into drives C and D, with a clear demarcation between my Windows 7 system in drive C and my data in drive D"
And how did you do that? Pad the "space between" with "sectors"? Data is not stored sequentially on an SSD. That's hard-disk-drive territory. Common SSDs likely have 16 flash chips, with 5-10 "channels" to read/write to those chips. The data is more likely to be physically stored RAID0(ish) style as opposed to sequentially on one chip. That's not counting the fragmentation that will occur as the drive is used, due to the copy-on-write methods of wear-leveling. In the end, there is no "clear demarcation" except logically (in your head and OS). SSDs don't even have sectors. Those 512byte blocks are simply emulated, just like any other sector/track concept. That is why page and block alignment is so important to establish optimal performance on your SSD.
Best thing to do? Use TrueCrypt whole-disk encryption from the start. Your data would not have ever been written to the drive in an unencrypted manner at any time, and thus you won't have to worry about it lingering around. The only thing likely to be vulnerable would be your network configuration and a bit of browser history that it takes for you to get on the network and download TrueCrypt initially after your OS install.
NAND flash memory is very much segmented into pages, usually 512 bytes. This is the granularity of an erase operation. Your point about them being emulated is wrong.
I think the detail in your comment of the physical layout is a bit of a red herring as magnetic drives also have the same disconnect between logical and physical indexing: They usually employ multiple heads and have a strategy of dynamically reordering the data with the aim of reducing lateral head movements to minimise power consumption, seek time and noise.
Absolutely right that encrypting any temporary files (and the swap file/partition too) is the only way to be sure.
Wear level(l)ing? De-gaussing????????
You got through that whole article without referring to wear levelling (and so does the paper), which is presumably a major part of the problem. If the OS repeatedly writes to what the OS thinks is logical block 42, it won't always end up in the same physical block of flash memory, because any given block of flash has a limited lifetime - a limited number of write cycles. Because of that, the SSD includes a flash controller that implements a "wear leveling" layer that attempts to ensure that any given physical block of flash memory does not get more than its fair share of writes, by mapping between logical blocks and physical blocks. If that made no sense, fair enough, look it up elsewhere, where you will hopefully also find words that explain how SSDs manage to present disk-like block sizes that aren't the same as the inherent SSD block size, and how SSDs have more internal blocks than they offer the host, for bad block replacement just like on a real hard drive.
So when this magic file erase software thinks it is erasing a specific file, it overwrites what it thinks are the required logical blocks, which courtesy of wear leveling etc are not the physical blocks where the original data was actually written.
Given that, if you read the whole "disk" from start to finish it is entirely possible courtesy of wear levelling etc that you will find pieces of the data that you wrote earlier are still accessible. They won't be where you expect them, but unless you correctly overwrite the whole disk from start to end (possibly including replacement blocks which aren't directly user-accessible) there is a risk that data may leak.
Can I have my ticket to California now please? I only need a couple of minutes and then I can go to the beach, if that's OK.
[The idea that there's any practical value in analog-hacking these things, as with supercooled DRAM... just don't, OK]
"subjecting SSD media to degaussing, in which a drive's low-level formatting is destroyed."
You cannot be serious? Shirley? What kind of iriot expects degaussing to have any effect on a flash-based storage device?
Secure burning of an SSD probably erases it.
...microwaves? ..electrical fields?
Electric arc, Laser Beam, Grinding wheel.
If it's worth erasing, the cost of blank replacement media is trivial compared to the cost of ((([[them]])) finding it.
Degaussing won't, but, remove the "u", and then the word works...
De-gassing... toss it in a microwave and the data will go from magnetic or optical to pure smoke and sparks of light . If you're brave, toss it in a container of mercury or something liquid that will build up a LOT of heat, but not explode too easily. Melt down the memory chip and fuse it. It might take the Tal Shiar, or better yet, the Xindi, to undo that bit of damage...
OTOH, someone might make a business model of operating an ISO-19485 (year) temporally-rated slurry-maker incinipit for sensitive data destruction...
Already discovered a year ago - wiping a flash device need not work
You are correct, but it has been discovered a year ago.
At first glance the idea of filling a drive with crap to overwrite the stuff you didn't want to be recoverable would appear to do the trick but you'd need a tool that could overwrite the spare capacity which is not reported to the OS and used to help with wear-levelling and bad block replacement.
dd if=/dev/zero of=/dev/ssd
That's the point
That will only fill the REPORTED disk size with zeros. SSDs are over provisioned, and when new data is written, it often just remaps the block and puts the new data in a new location. Hence, looking at the chips themselves, you could recover a potentially large amount of data.
dd if=/dev/zero of=/dev/ssd probably useless on compression SSD
Some high end SSDs use disk compression internally, so a stream of zeros of arbitrary size (e.g. equal to the published nominal device capacity) could be compressed to a very small file as stored on the actual hardware. The rest of the files on the device would be unaffected.
dd if=/dev/urandom of=/dev/ssd would be better as the output doesn't compress, but as other commenters have pointed out, even this doesn't overwrite physical blocks previously marked by the wear levelling software as unusable.
The problem is partly that all of our assumptions based upon what works on rotating media are invalid, given the way reverse engineering is revealing how flash memory works internally.
Burn baby burn!
I used to work for a company which handled a lot of credit card transactions and personal data. Needless to say this meant the company disposal policy on hard drives was pretty tight.
Given the time a secure wipe can take for just one drive I took to collecting a batch in the server room and then taking them home in one go... A few minutes with an oxyacetylene torch soon erased them. Far quicker, and I defy anyone to recover data from re-solidified aluminium or glass platters. Even better, it takes just as long to "delete" a 1TB drive as it used to for a 20GB.
The boss thought this was quite an amusing, and secure way of maintaining data security, so I took my time with one and sliced it straight down the middle, long ways, and brought half back into the office. The boss put it in a case and proudly showed it to potential customers as an example about how seriously we take data disposal.
I feel sorry for whoever took over after me... I don't remember the job description including "the successful applicant will have an oxy torch".
We're so serious about security...
"... and then taking them home ..."
This is the part you didn't tell the customers about, right?
Takes time to get home...
...once the drive leaves the data center, the data is open to be compromised. Who's to say you actually did what you said you did?
disposal policy on hard drives was pretty tight ...
... but they let you take them home. Yeah right.
WTB Data Protection.
Hmm... Please tell us who you are with so we can avoid them?
Seriously I suspect a lot of companies out there are just as lax...
of course this happened
I have worked in a center for secure data disposal. Even handling drives outside of the non secure area was liable for dismissal. We went through turnstiles and metal detecting security before we could leave and enter the secure building. Loading bay had a separate inwards and outwards path that didnt intersect and again personell went through metal detector whilst the outwards prepacked containers were on the conveyor. No phones, electronic devices (including watches, games, pagers etc) inside the main building, no keys, no metal, no flash drives. All of the above were subject to disciplinary proceedings. Of course you could go back out to your locker at break times if you wanted to but through the security and back again.
There were various levels that customers could pay for varying from data blanking via overwrite to degauss through to crunch to tiny bits (then melt).
even better: BELT SANDER
the bad part, the disks never actually left the data center. Yes, the operator sat a table in the middle of the floor with a belt-sander and removed the coating from each platter.
Take them home??
They let you take the drives home????
Oxyacetylene approach is good, but exposing yourself, the company and your clients to the risk of you being robbed, kidnapped and optionally tortured to get this data to my mind does not indicate that your company took data disposal seriously enough.
Please remind them to keep the oxytorch in-house!
The fact that an SSD device does not lose data when degaussed is about as much of a security failure of the device as the fact that hard drives don't lose data when prayed over. They're not magnetic media.
Since they're random-access memories, defragmenting yields no access-time benefits, so I wouldn't be surprised if it just shuffles pointers around or is ignored in some other way. It is true that erasing a large SSD by backing up all the useful data on it, and then filling it up with one huge file of random data is not practical - and it may be that even this will leave some data left in odd nooks and crannies now used for the directory structure, which is a valid security issue (in the sense of valid as a complaint against the manufacturers).
Even invalid complaints, though, are real security issues if user's aren't aware of the inherent limitations of solid state disks. But studies that appear to show a lack of appreciation of the distinction lose credibility. Still, it would be desirable for SSDs to automatically zero out all unused space upon request. (Doing it automatically as a general practice would prevent data recovery after crashes and the like.)
Of course, this means an extension to the operating system so that it knows how to issue such a request, or utilities that come with the particular device.
- Product round-up Six of the best gaming keyboard and mouse combos
- LinuxCon 2014 GitHub.io killed the distro star: Why are people so bored with the top Linux makers?
- Boffins attempt to prove the UNIVERSE IS JUST A HOLOGRAM
- China building SUPERSONIC SUBMARINE that travels in a BUBBLE
- Review Raspberry Pi B+: PHWOAR, get a load of those pins