Improving Security On Solid State Drives
This post originally placed on my McAfee Blog – http://blogs.mcafee.com/corporate/cto/improving-security-on-solid-state-drives
Well, One week into the Intel/McAfee relationship and I am pleased to say it’s already bearing fruit. Over the last few days I’ve been reaching out to all my Intel peers, making the connections with people which were simply impossible while the deal was going through all the evaluations.
I had an interesting discussion with Knut Grimsrud in the Intel storage division today about “clever” things we can do to improve performance and security on the Intel SSD hard disks.
Typically, Encryption and SSD’s are not pleasant bedfellows. Sure, it works, but as most have found, an SSD which has been encrypted performs slower than one which has not. This is due to a few factors, but mostly because encryption at the sector level writes a capacity-worth of data to the SSD, giving it little “free space” to work with afterwards.
Data stored on SSDs is not arranged like sectors on a magnetic disk – in fact, you can imagine it more like tape storage. New writes are written to fresh pieces of tape, it’s not until you reach the end of the tape, that the disk starts overwriting earlier deleted or unused areas.
This is done because the NAND storage in an SSD, again like magnetic tape, has a finite number of write cycles it can go through before it starts degrading. By spreading the writes into new areas of “tape”, and overwriting as little as possible, the drive can extend its useful life far beyond the 10,000 or so write cycles any particular block is good for.
So, doing a full encryption on an SSD obviously has some consequences – all that beautiful fresh tape gets used up, and the drive starts going and filling in gaps and deleted areas – and, to add insult to the process, overwriting a bit of NAND storage takes significantly longer than writing a fresh or unused piece. The final nail in the performance coffin is the drive is challenged in determining areas occupied by real files, and areas that are just overwritten by the encryption routine – thus the internal “garbage collection” routines which go looking for reusable areas of storage are working overdrive to find somewhere to write to.
So, how to solve this performance problem? Well, lucky for us Intel already made a tool available to do exactly that, though it was intended for other purposes. Let me introduce you to the Intel SSD Toolbox, in particular, the Intel SSD Optimizer.
The Optimizer is designed to go through your smart little SSD, and work out what storage is in use by current files, and what is free – either never used, or was in use at one stage, but the file’s been deleted. The Optimizer then tells the SSD using a special command called “Trim” that certain blocks of space can be considered free.
So, your slow encrypted 160GB drive with 40GB of data on it and 120GB of mysterious encryption remnants goes back to having 120GB of nice fresh free space, and blistering performance to match.
You can run the optimizer once after encryption, but as Intel recommends, it’s good to run it regularly to keep your drive in top performance.
To close, people have asked why we don’t just ignore all the unused space on the SSD to start with. The challenge is, that writes on the SSD get scattered all over the place – there’s no way of tracking them down, and remember, when you overwrite a sector on an SSD, you are in fact writing a new sector somewhere else. Since we want to make sure that any data on the drive prior to encryption is also protected, we have to make sure we touch all the storage. We don’t want someone to be able to disassemble the SSD, dump the memory and find a copy of some very sensitive data on your encrypted drive.
Great News and write up. Looking forward to what the future brings with the McAfee/Intel relationship. Not just for encryption but also other endpoint software based security products. Thanks for engaging so quickly and sharing.
This doesn’t make sense. When SSD completes FDE, all space r consider used. Trim will not be able to clear free space.
You misunderstand Trim and encryption I think Jjerry – although FDE writes to all the space, it’s not “used” by any files or data – the free space on the drive before and after encryption is the same, so Trim can tell the Drive to deallocate the sectors which (though encrypted) don’t contain any data and put them back into the free pool.
SSD’s with Sandforce controllers have Garbage collection that replaces TRIM. Also A lot of drives reserved space for garbage collection which makes filling the entire drive having zero impact on performance. OWC SSDs do that.
Thats what I thought as well, but encryption of sectors does not create “garbage” as far as the drive is concerned – a write to a sector by the file system, and a write by encryption are equally valid things at the drive level. That’s why an external “rationalization” is required.
As for spare space for garbage, no drive has enough to cover the case of full disk encryption. You’d need more space in the garbage block than the storage capacity of the unit.
So does Endpoint Encryption pass the Trim command through to the drive during normal operation for modern OS’s? If so, then it seems that the performance degradation of “full” SSDs would be much reduced.
Trim comes from the file system driver, so it’s not something products like eepc see or have any influence over.