Storage

The security limitations of solid-state drives

SSDs can offer substantial benefits in performance and reliability for at least some purposes, but encrypting data and secure data deletion are problems.

Solid state drives, or SSDs, have been the subject of some anticipation for quite a few years now. I recall my father talking about how solid state storage would revolutionize computer design in just a few years, a quarter century ago. At the time, my understanding of what that would entail was somewhat less clear than it is now, but here we are looking at the rapid encroachment of SSDs into areas previously dominated by spinning magnetic media hard disk drives (HDDs).

The benefits are dramatic. The fact there are no moving parts in SSDs ensures greater resistance to physical damage under harsh usage conditions. The fact SSDs do not use traditional magnetic storage protects them against certain failure modes of more traditional media. Access times are typically faster, and access latency can be greatly reduced, improving the performance of read operations.

Early in the modern era of solid state storage devices, some SSDs used the same technology as the RAM installed in our computers. Unfortunately, this technology suffered some problems that limited its adoption, including:

  • They suffered from very high cost per byte, relative to HDDs.
  • They were volatile memory, and required a constant supply of power.
  • They were, simply put, bigger.

In exchange for these features, however, they provided very fast access times. As a result, they were useful enough for some people to invest in small SSDs built in this manner.

The increasing prevalence of non-volatile flash media storage soon saw that approach to persistent solid state storage spreading, however. Flash memory cards and USB "thumb drives" proliferated, but the increasing storage capacity and decreasing costs of HDDs have continued to guarantee them a place as the default persistent storage media for most purposes. Things are rapidly changing, however; netbooks saw the widespread sale of flash media SSD-using consumer computers. Smartphones have also substantially increased the use of flash media SSDs in consumer computers, and flash media SSDs are being offered in standard laptop computers now as well.

Part of this rise in usage can be attributed to the falling prices of flash media. It has not caught up to spinning magnetic media by any stretch; it still costs many times as much money per byte. For a small multiple of the cost of a current HDD size in a laptop (say, twice as much money), one can now have an SSD that is big enough for most modest needs -- that is, the needs of people who do not do a lot of professional video editing on their laptops, or download gigabytes of movies every weekend and store them indefinitely.

Aside from the cost differential per byte of storage, SSDs are rapidly approaching the day they will render HDDs essentially obsolete. They do still have some problems, however:

  • SSDs are subject to hard limits on how many write operations may be performed before they cease working correctly. Their capacity for longer life is constantly growing, and this will surely become (mostly) a thing of the past within the next few years, but for now use cases that require heavy writing activity may prove problematic for the lifespan of these storage devices. Some claim these days are already behind us.
  • Cost, as already noted, is much higher for a given storage capacity than for HDDs. As of this writing, expect prices around $1.50 USD per gigabyte of SSD storage, and only about ten or fifteen cents per gigabyte of HDD storage -- an order of magnitude cheaper than SSDs, and then some.
  • Many of the security challenges for storage media that are widely considered "solved problems" for HDDs have not yet been thoroughly addressed for SSDs.

If the user has the funds to spend on SSD storage, keeps good backups (which one should do anyway), and does not find the "write longevity" problem of SSDs significant, most of the rest of the differences between SSDs and HDDs seem to recommend going with an SSD every time. This will only become an easier decision as SSD technology advances and prices continue to drop on what is, in some respects, still a relatively new technology implementation.

Security is another matter.

The security limitations of SSDs

Speaking of flash media SSDs as the standard implementation for the near future, the most obvious security disadvantages relative to HDDs revolve around encryption and secure deletion. Under the hood, these turn out to be effectively the same category of problem.

Magnetic storage media rely on the alignment of magnetism in ferromagnetic materials on the surfaces of the platters. Because of this, passing a read/write head over a platter to apply a magnetic field to that ferromagnetic material can change the data currently recorded there in one simple operation. The overwriting process need not account for whatever data was previously recorded.

By contrast, flash media uses transistors to store data. A group of these transistors has an "empty" or "erased" state and a "programmed" or "written" state. Each of them must be reset to an "erased" state before they can be reset to some "written" state to store data. As a result, while writing to empty storage space only requires a single operation as with magnetic media, "overwriting" is effectively impossible. Any data in the space where new data is to be written must be erased first, in a separate operation.

Encrypting data already on disk

This leads to the first problem with data security on SSDs: encrypting data already stored on the media. Because of the way filesystems interact with storage media, encrypting a file on magnetic media such that your data is secure involves merely writing the newly encrypted data over the old data. This leaves the HDD only storing an encrypted copy of the data, because the unencrypted copy was destroyed by the process of writing the encrypted copy to disk.

By contrast, this operation is effectively impossible for an SSD, and in the general case, the encrypted copy of the file will write data to a currently empty region of the media, leaving the unencrypted copy where it is. The plaintext copy is "erased" only in that it is eliminated from the filesystem's mechanism for tracking files -- e.g., a file allocation table or inode. Bypassing the filesystem to directly scan the media can reveal "deleted" data that is still there to be found. The controller built into an SSD abstracts the management of data on the device so that implementation specific drivers are not needed by the computer, but this abstraction also creates the problem that there is currently no standard means of ensuring unencrypted data is truly erased from flash media.

Secure data deletion

This leads directly to the second major security issue afflicting SSDs: secure deletion. Standard secure deletion software such as the Unix utility shred is sufficient for secure deletion on modern HDDs, but largely ineffective for consumer flash media storage devices.

UCSD researchers Michael Wei, Laura M. Grupp, Frederik E. Spada, and Steven Swanson have published the results (PDF download) of practical testing, showing the dismal state of secure deletion on SSDs. The results of their tests led them to three conclusions:

  • First, built-in commands are effective, but manufacturers sometimes implement them incorrectly.
  • Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive.
  • Third, none of the existing hard drive oriented techniques for individual file sanitization are effective on SSDs.

The third conclusion should come as no surprise to those who understand the rudiments of flash media storage technology. The second is disappointing, but not entirely surprising. This leaves users with a single recourse for reliably secure deletion: functionality built into the storage device itself. The dismaying fact that we must rely on "black box" implementations of secure deletion technology that ship with the hardware may raise warnings in the minds of the practical paranoids of the world, based simply on the fact that without extensive testing we really do not know what the devices actually do under the hood. One is implicitly required to trust in the manufacturer's good intentions for reliably secure deletion of data.

Worse, the research shows that regardless of good intentions, the secure deletion capabilities of SSDs may not even be correctly implemented. In short, the secure deletion functionality of your SSD may simply not work correctly, resulting in false confidence in the secure deletion of data that is still sitting on the device, waiting to be discovered.

In addition to these problems, there is the inconvenience of the fact that there is no effective mechanism for secure deletion of a single file. If the user wishes to securely delete anything on the media, he or she must securely delete everything in the media's user-accessible storage space.

Not all hope is lost. The researchers who worked on this project have developed some techniques for both continuous data sanitization (which impacts performance substantially) and on-demand sanitization. There is still much that can be done to improve the interfaces and integrated functionality of SSDs to accommodate secure deletion operations in the future. Potential solutions using today's implementations may undo many of the media lifespan optimizations currently in place that minimize the number of writes to any individual parts of the complete SSD's user accessible address space, however.

The end result is that for security-critical uses, SSDs are often not the best choice of storage technology. The greater maturity of HDD storage technologies allows for greater reliability and flexibility of secure data management without damaging the expected lifespan of the storage devices, at least for now.

Additional Reading

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

37 comments
ilovesards
ilovesards

I FORGOT MY 1GB SSD in my pocket inside 60minutes washing machine with chlorox + detergent soap . i followed good advice to dry it on my laptop keyboard for two hours= great, all data as per my back-up count =are still there(i needmy ssd,not my data). i read from scientific american that, even you overwirte HHD'S ten times, the NSA can still bring the shadows of your data =up-front . ssd's can easily be destroyed physically than hdd's. ill just swalow 32GB micro ssd's when somebody searches. in cases of encryptions= even if you use > 3million digits of pi encryption= time will come =it will be decrypted (ask the NSA ). lesson= protyect your data . if you lose it= its your fault, not the ssd's .

melias
melias

Let's just hope the scanner/copier manufacturers don't start using SSDs any time soon.

MTsyko
MTsyko

Thank you for this article. You answered questions that I had and ones that I would have come up with. End result: I'm going to quit looking at SSD's for awhile.

c.walters
c.walters

Chad, I really enjoyed reading your article. I only have one question. Wouldn't encrypting the data before storing it on the SDD media solve the encryption issue?

dlovep
dlovep

Is that mean the SSD would be far more better than Hard Disk? since you can re-constructre the previous written data, which mean you can write whatever data you want and when it's full just delete it, and when you need it you will be able to retrieve back?

Spitfire_Sysop
Spitfire_Sysop

I think that the best use of a SSD is a read-only OS drive. Any OS that can run like a liveCD will be optimal. Once you have your OS installed and configured it should be locked down in read only mode. No data should be kept on it. The only time you would write to the drive is for configuration changes and updates to the core OS files. I would like to see some sort of feature like this built in to modern OS. Having your boot drive read-only must enhance security, right? It would even better if you had two small SSDs. One would be the core OS, locked in read-only at a BIOS level. One would be for configuration files and program files. Then a seperate magnetic HDD for swap files and user data/multimedia.

Sterling chip Camden
Sterling chip Camden

(old man sighs) it wasn't that long ago we thought that $1 per megabyte was a good deal. I'm sure SSD technology will eventually catch up with all of these concerns. For now, I'm avoiding it for all but casual/incidental use.

Photogenic Memory
Photogenic Memory

This isn't a security question but more a functionality of the drive. I've been reading that in older drives write operation slowed down due to the problem of old data having to be erased first to make space for the new data. I also read that TRIM is a feature to helps overcome that but still the problem does exist in what is described as " write amplification"? I read here for concise explanation: http://en.wikipedia.org/wiki/TRIM Does anyone know of anything that will either replace TRIM or work better that's in development? The article does describe some security issues with the program. I plan on buying an SSD soon and really look forward to enhancing an old computer of mine with this just to see what happens.

francois.lachance
francois.lachance

Some people have already adopted this for the secure disposal of HDD, the same should be used for SSD - physical destruction of the media.

Chug
Chug

This article seems to address file level secure erasure or encryption? And I'm unclear if this is talking about flash drives in general, like USB thumb drives, or SSD drives that replace hard drives. What about whole disk level erasure or encryption for SSD drives that replace hard drives? For example, using one of the many DOD wipe tools that exist to securely overwrite an entire drive before disposal? Or using BitLocker or some other 3rd party encryption tool (my comany uses SafeBoot, or what's now called McAfee Endpoint Encryption). I would think that when you're doing this at a whole disk level, on a device that's supposed to act like a hard drive to the PC that it's plugged into, the controller system within the SSD device would take care of all this for you wouldn't it? If that's not true, please explain further. Thank you.

Joe_Wulf
Joe_Wulf

Chad, Very well written article. Your descriptions are excellent and included a great lead-in with relevant information on some SSD background. Look forward to many more good articles like this from you! R, -Joe Wulf

ctrogers
ctrogers

Just last week I read an article on Slashdot about how SSDs start sanitizing deleted files all by themselves even if law enforcement officers try copying the drive with a write-blocker in place. Apparently some of these drives understand NTFS and zero out unused space whenever possible to maintain performance. Original article link: http://news.techworld.com/security/3263093/ssd-fimware-destroys-digital-evidence-researchers-find/ "After examining an SSD for traces of data after it had been quick formatted, the team expected the purging routines to kick in around 30-60 minutes later, a process that must happen on SSDs before new data can be written to those blocks. To their surprise, this happened in only three minutes, after which only 1,064 out of 316,666 evidence files were recoverable from the drive."

spufidoo
spufidoo

Possibly one of the most clear, succinct and comprehensive articles I have read on the subject of SSDs.

melias
melias

Is this the hi-tech version of a BFLH? :) I would like a solution that would allow me to continue using the drive. Oh well, can't have everything.

apotheon
apotheon

Luckily, that's an easy question to answer. Yes, it would solve that problem -- because never storing a plaintext copy of your data there ensures there will be no plaintext copy of the data lingering after encryption.

Neon Samurai
Neon Samurai

It seems to be a two edged sword. A full drive is going to be overwriting a lot more previously deleted data so your not going to have very long to recover files before they are unrecoverable. When you want to recover stuff, you can't. An empty drive may not be moving enough around to over-write previously unencrypted files. You've encrypted your drive unknowingly leaving unecrypted fragments not yet overwritten by new data. When you want the files to stay lost, they don't. It apears some drives do automated maintenance related to file leveling. When turned on or left idle, the drive may just start moving things around to fresher more trusted storage blocks. When your working with the drive during a recovery, you may actually make more of it unrecoverable due to it's own design. This is even worse than the first above because now when you want to recover files you can't. Not because you wrote more files to the drive but because the drive itself did so beyond your control or choice.

SkyNET32
SkyNET32

"I'm sure SSD technology will eventually catch up with all of these concerns. For now, I'm avoiding it for all but casual/incidental use" I remember too, ah, the nostalgia. I'm not concerned either about it for casual use, but I agree, if your data is that sensitive, as Chad referred to those "basic paranoids", stick with traditional media

apotheon
apotheon

I also remember when an entire OS kernel was smaller than your average MS Word document today. We have more storage, but most people are squandering it on a lot of bloated software.

apotheon
apotheon

I expect TRIM to get improved or replaced at some point in the near future. Time will tell.

seanferd
seanferd

Then it really isn't any different than an HDD anyway, if you are going to wipe the whole drive and/or shred it.

seanferd
seanferd

-Encryption and secure deletion. You can't count on encryption if the unencrypted source files are not securely deleted, right? There is no physical overwriting on SSDs. -All SSDs. Doesn't matter what type of drive. Yes, if you want to destroy a drive, any full disk secure erasure will work. (And a hammer or whatever.) But do you want to wipe a whole drive occasionally to make sure that stuff you erased is truly gone? Not to forget that you only have so many write cycles with an SSD as well.

Rayezilla
Rayezilla

The article is talking about both encryption and secure erasure. flash drives, USB thumb drives, and SSD drives that replace HDDs all use the same basic technology as far as I understand it, so the article refers about any files stored on any of those devices. I'm not sure about your last question (the DOD wipe tools), but the article does say that traditional HDD wipe programs aren't effective on SSD technology.

Chug
Chug

no, I don't want to wipe a while drive occasionally to make sure stuff I erased is truly gone. That's where the "whole disk" encryption comes in. I understand the idea of encrypting only a file basically creates the encrypted copy in a different space on the SSD device and leaves the original unencrypted data there, but whole disk encryption shouldn't have that problem should it?

apotheon
apotheon

If something is not clear, I welcome the opportunity to clarify.

apotheon
apotheon

> Our experience is that the amount of data does not affect how long the one-time initial encrypting takes to finish. That does seem to indicate that it is actually behaving under the hood the way you described. Do you know if it's the same on SSDs? I'll check out the link you provided.

Chug
Chug

>> It DOES take several hours (for us it usually takes about 3 to 5 depending on drive size and computer power, this is with a normal hard drive) to initially encrypt the drive but that is a one-time process. >Is this with a clean drive, or is does it involve encrypting a drive that already has a lot of data on it? If the latter, the amount of time it takes may not necessarily be indicative of overwriting every sector of the drive. Most of the time we are encrypting the drive as soon as the PC finishes reimaging so it's got the base OS and some standard apps on it, but before the user really has a chance to put any data on it. But sometimes it doesn't happen until later after there is a lot of data on it. Our experience is that the amount of data does not affect how long the one-time initial encrypting takes to finish. >> And as rolandl posted, it encrypts EVERY sector on the drive whether there's data on that sector or not. >Can you cite a source for this so I can read up on it? I'm not the expert at my company about the product, but everything I've heard about is, yes, it's SECTOR level. The product my company uses is McAfee Endpoint Encryption. It used to be called "SafeBoot" and was it's own product that McAfee bought within the last year or two. Here's a link to their product site. http://www.mcafee.com/us/products/endpoint-encryption.aspx >> It does affect performance but does on regular drives anyway, but it's pretty negligable. >That's a result of processing being performed on data in RAM (to encrypt and/or decrypt it), so yeah -- it has nothing to do with the type of drive you use. Yes, exactly, I understand that. I was just responding to someone else's comment about not believing that such an encryption mechanism wouldn't affect performance. I was clarifying that of course it does, but it's negligible.

apotheon
apotheon

Doing a defrag on an SSD is pointless because of the performance characteristics of the drive -- and, though I have not tested it, I do not even know if defrag can operate on an SSD.

apotheon
apotheon

> No, WDE is NOT only at the file level, it IS at the sector level. To clarify, SkyNET32 said "filesystem level", not "file level". There is a difference. Are you positive that PGP WDE is actually touching every sector on the drive, or is it just dealing with the virtual filesystem and letting the drivers handle the hardware implementation details? In fact, even if it normally touches every sector of an HDD, I'm not positive that would apply in the case of an SSD. It would have to literally send enough data to the drive to force the controlling electronics to actually write something to every single cell in the flash media. With HDDs, one can normally achieve similar sanitization results by just telling the drive to overwrite specific files, but thanks to the write-iteration saving algorithms used by flash media SSDs, the devices go out of their way to avoid writing to the same exact set of cells, reporting such an operation as successful while writing to another part of the device's user-accessible address space. > It protects the ENTIRE contents of the drive and is independent of the OS on the PC. This makes me think it actually might not work with SSDs at all -- maybe. Flash media SSDs abstract away the implementation details of the hardware, essentially eliminating direct access to the device while giving the software attempting to access it the impression that it has done so successfully by layering an interface over the controller for the device that looks like direct access. Similarly, Oracle's databases didn't work with ReiserFS at all last time I checked because it bypassed the filesystem to interact with the drive directly at the block level, the result being that trying to use the two technologies together would corrupt the filesystem. > It DOES take several hours (for us it usually takes about 3 to 5 depending on drive size and computer power, this is with a normal hard drive) to initially encrypt the drive but that is a one-time process. Is this with a clean drive, or is does it involve encrypting a drive that already has a lot of data on it? If the latter, the amount of time it takes may not necessarily be indicative of overwriting every sector of the drive. > And as rolandl posted, it encrypts EVERY sector on the drive whether there's data on that sector or not. Can you cite a source for this so I can read up on it? > It does affect performance but does on regular drives anyway, but it's pretty negligable. That's a result of processing being performed on data in RAM (to encrypt and/or decrypt it), so yeah -- it has nothing to do with the type of drive you use. I believe PGP WDE may do what you say. Unlike most proprietary commercial encryption software vendors, the engineers at PGP Corp. generally know what they're doing, and may well have taken such implementation precautions with their whole drive encryption software. I'm just nitpicking details because I want to be sure.

Chug
Chug

I don't want to presume, but it sounds like you're not familiar with how "whole disk" encryption works. No, WDE is NOT only at the file level, it IS at the sector level. Also, it's not a disposal issue, it's protecting the drive from being read if the PC is stolen (so you can't just slave it to another PC and read it). It protects the ENTIRE contents of the drive and is independent of the OS on the PC. It DOES take several hours (for us it usually takes about 3 to 5 depending on drive size and computer power, this is with a normal hard drive) to initially encrypt the drive but that is a one-time process. And as rolandl posted, it encrypts EVERY sector on the drive whether there's data on that sector or not. After that initial process, the encryption/decryption is real-time. Since the initial encryption is only a one time process, I don't see how that would shorten the life of the drive. It does affect performance but does on regular drives anyway, but it's pretty negligable. Not putting sensitive data on a PC for a comany that deals in sensitive information isn't realistic. That would basically mean a large portion of the employees in the company might as well not even have computers, and for the work they do that's not practical. That's what the "whole disk" encryption is for.

Neon Samurai
Neon Samurai

Truecrypt has a "whipe drive" option when encrypting the system disk (FDE). it'll encrypt the bits and overwrite empty spaces. That should cover any cleartext dregs left on the drive (but may take a bit out of the SSD's lifespan). One could also consider a disk defrag after the intial system encryption. This may move enough aroound in the chips to scatter the bits. of course, it depends on how much effort the machine justifies. Somethign that's going to be classified top secret is going to need a verifiable and confirmed secure whipe if not a pre-encrypted system image that gets stamped onto the drives.

SkyNET32
SkyNET32

I don't think it matters whether you are using WDE or just trying to encrypt a single file. I thought Chad was trying to say that the underlying file is still there, in plaintext regardless if you are encrypting one file or the whole disk, because HDD type encryption software only does it at the file system level, and not deep enough to the sector level. Furthermore, encrypting an entire drive would take hours, and severely shorten the life of the drive and its performance. I think smashing the drive would be the safest bet, and no I don't have a problem with that since by the time its time to do that, the drive will have lasted a long time. Those ssd's are rated at 1 million hours MTBF, aren't they? That's enough for me. You still need it? Then don't put sensitive data on it :D

apotheon
apotheon

I'm not terribly familiar with PGP WDE. Thanks for the information.

rolandl
rolandl

We use PGP Whole Disk Encryption at my workplace. FYI, when you enroll a disk on WDE, every single block of the drive is encrypted, whether there is data on it or not. This is a single read and write. An 80GB 2.5 inch 7200 rpm hard disk, for instance, takes some 3 hours to fully encrypt. See this for the fuller discussion: http://paulstamatiou.com/pgp-disk-encryption-safe-for-solid-state-drives I believe WDE largely overcomes the security limitations discussed in this article. Nothing is perfect, of course, as there are spare sectors on the drive for fault tolerance, etc., but WDE does overcome the "unencrypted files left on the drive" issue specifically discussed in the article.

apotheon
apotheon

It seems unlikely this would provide the complete protection you want it to, at least until you have enough data on the encrypted drive to actually fill the whole thing. I am not aware of a whole drive encryption system that will painstakingly overwrite every single byte of storage on the drive as part of the process of setting up an encrypted partition. Obviously, this applies only to data you had (unencrypted) on the drive before encrypting.