SSDs and built-in encryption–and how to enable it

Last Updated on July 3, 2011 by Dave Farquhar

Update: This entry was based on preliminary information that turned out to be incorrect. Please see the following update.

One of the last knocks on SSD performance is that they don’t perform well with full-drive encryption. But on Sandforce 1200- and 2200-based drives, and the next-generation Intel 320 drives introduced today, that’s not an issue anymore. Encryption happens on the drive, in hardware, with no performance penalty.

The problem was that nobody talked about how it works. I found the details buried in Anandtech’s review of the Intel 320 drive. The takeaway is this: If you set your BIOS password, the drive will be unreadable if you remove it and put it in another system. Update: No it won’t. But you can add ATA password support, under some circumstances.
It’s been a long time since I’ve bothered with BIOS passwords, since they’re trivially easy to defeat. So I never noticed that modern PCs also use the BIOS password as the ATA password. Sandforce and Intel 320 SSDs already write everything with AES-128 encryption. AES-128, if you’re wondering, meets US Government standards for classified information up to the SECRET level. As far as the US Government is concerned, the difference between SECRET and TOP SECRET is “grave damage” to national security vs. “exceptionally grave damage” to national security. If you’re wondering, the diplomatic cables and other classified information published by Wikileaks in 2010-2011 were classified SECRET.

Put simply, AES-128 isn’t good enough for a government’s very deepest, darkest secrets, but it’s good enough for most classified information. So it’s probably good enough for you.

The AES-128 encryption in modern SSDs happens at the hardware level automatically, so there’s no speed penalty for using it, and you have nothing to gain by not using it. Simply set your BIOS password on your system, and your drive is encrypted, regardless of what operating system or operating systems you run. The only reason to use software-based encryption is if AES-128 isn’t secure enough for you for some reason.

If someone attempts to defeat it by the conventional method–clearing the password by using a jumper on the motherboard (or, perhaps, other methods depending on the system), the attacker won’t find a readable drive, and won’t be able to boot into the operating system. So, essentially, ATA passwords and the way they’re implemented on modern SSD drives really give teeth to the BIOS password. But since it’s not dependent on the host operating system, if a critical system file gets blitzed and renders your drive unbootable, a recovery CD will still work to salvage whatever data may remain on the drive.

If you found this post informative or helpful, please share it!

9 thoughts on “SSDs and built-in encryption–and how to enable it

    • March 28, 2011 at 9:22 pm
      Permalink

      Bill, I believe the answer when that happens is to set the BIOS password in the new board to match the old, then plug in the drive.

  • March 28, 2011 at 11:27 pm
    Permalink

    In his own documents concerning ssd 320 series intel clearly speaks not about BIOS but ATA device password. There is no mechanism to secure mass storage drive by BIOS password. But ATA specification offers per drive password. Bios of your motherboard should support such feature. Most of desktops do not, big pile of notebooks do. But that’s not all. To maintain tight security ATA password should be used to hash AES encryption keys. All these keys should NOT be placed anywhere in unencrypted form. Remember… with ATA pass you can lock any drive (not only intel’s). Only in strict conjuction with internal encryption the whole intel’s AES makes sens. But what implementation intel chose? Does it make sens? Ramains to be seen, I hope.

  • March 28, 2011 at 11:35 pm
    Permalink

    I believe a modern BIOS stores passwords as a hash which raises a number of questions. Such as AMI, Award and Phoenix all hashing passwords to the same value? Or same BIOS manufacturer across the various main board manufacturers? Or models within a manufacturers product line as delineated by specific features and/or processor type? Given customizations by or for system integrators such as HP, Lenovo or Dell?

    It would be a rough cob to find out later the disk only working with a specific make and model main board given specificity of a particular BIOS necessary to recover data.Then there is the matter of updates to BIOS microcode. Could that impact password hash values? It could if the hash is salted with machine specific BIOS information possibly including BIOS revision number if not modifying the hash algorithm itself.

    Just thinking out loud how problematic data recovery might be in a main board failure scenario. It happens. So we order an exact replacement from the manufacturer who sends out a revision 3 board when we had a revision 2. We have run into similar incompatibility scenarios with hardware RAID controllers. Not saying the use of a BIOS password precludes the requisite flexibility needed to facilitate failure mode access and recovery of encrypted data — I don’t know — but me personally would need the answers up front.

  • March 29, 2011 at 12:27 am
    Permalink

    ATA Passwords are not stored in bios. They are stored in the drives themselves. In their firmware none-volatile memory or on the firmware section of platter surface(in case of convensional hdds). BIOS offers only interface to set this password up. This interface is standarized by ATA specification. But those storage implementations rise questions and history taught as that manufacturers had much on their consience in this reagrd. See all those commercial firms offering ATA password bypassing and resetting. Security fiasco.

    • March 29, 2011 at 6:06 pm
      Permalink

      All I know is what’s written in what I linked above:

      SandForce introduced full disk encryption starting in 2010 with its SF-1200/SF-1500 controllers. On SandForce drives all data written to NAND is stored in an encrypted form. This encryption only protects you if someone manages to desolder the NAND from your SSD and probes it directly. If you want your drive to remain for your eyes only you’ll need to set an ATA password, which on PCs is forced by setting a BIOS password. Do this on a SandForce drive and try to move it to another machine and you’ll be faced with an unreadable drive. Your data is already encrypted at line speed and it’s only accessible via the ATA password you set. (emphasis mine.)

      That’s all I know. When I get hardware to test it myself, I’ll do it, but I don’t know when that will be. Right now my discretionary budget is $0.

  • March 29, 2011 at 11:08 pm
    Permalink

    First, thanks Dave for putting this up for discussion.

    I spent a couple internet hours digging for information since I’m well behind the curve on this and it’s important. What I’ve found so far is both assuring and disturbing although a complete picture has yet to be puzzled together.

    It seems — and I really want to preface this at the moment — that the BIOS ‘Security Set Password’ ATA command sends the password to the drive controller in clear text. In this context I don’t find that particularly ominous and if true, we can scratch any concern about alternate machine/main board access as long as the BIOS is supportive of that simpler function.

    The troubling part (if true) is the drive encryption key being independent of password. The password then being purely a function of authorization. But even if the password was incorporated into the data encryption key — presently understood to be randomly generated upon initialization — it exists as a function of the drive controller and stored within the drive in areas only available to the controller.

    Without better understanding, this raises a red flag around the possibility of third party access to the drive and its contents via privileged controller functions. Which puts us squarely in a trust relationship with the drive manufacturers found all among none I’ve went to lunch with recently. The NSA on the other hand…

    At any rate by the end of the day we’ve made at least a modicum of progress in understanding and all hands I’ve read so far agree to this application of technology being best of breed to date. That may or may not being saying much. We’ll see.

    Thanks again.

    • March 30, 2011 at 6:30 pm
      Permalink

      A coworker and I spent some time researching it and, yeah, there’s not a clear indication of the relation between the password and key, if any.

      There’s also a lot of “ata passwords are easy to defeat” talk, but when someone asks how to do it, because they bought a used drive and found it was locked when they got it, nobody can say how to do it, short of “send it off somewhere and for $59 they’ll do it.” In my mind, “easy” means go download something, and there’s nothing definitive in that regard.

      Ideally, the password should be linked to the key, much like PGP’s passphrase works.

      Password authentication is OK, and then the key is to use a strong password that won’t fall to a simple dictionary attack. But if the two are linked, you’ve got a human element in there, not just an algorithm that can be reverse engineered and broken.

  • March 31, 2011 at 7:20 pm
    Permalink

    Ideally AES and ATA keys should be bind together during Secure Erase when AES keys are generated. The final key should be split between hardware (non volatile disk memory) and user (his mind). Both have only a piece of the final key which encrypts the drive. That way cracking hardware gain nothing, only cracking AES algorithm or using key loggers (harder because of hardware nature of application) could be used. If the hacker dump flash memory he still needs both parts: hardware burried key and user key.
    This is the proper solution.
    One thing is for sure: This is not the implementation intel has chosen.
    Everything else will be more or less security compromised.

Comments are closed.