SSDs with usable built-in hardware-based full disk encryption

(tl;dr / post summary: Many current SSDs do super fast hardware AES encryption, but only a very few expose this correctly to the user, meaning you often still need a third-party software solution. Information on this is incredibly hard to find.) Imagine that your laptop or your PC gets stolen. That would be terrible. However, it would be even worse if your laptop contained confidential data, either your own or that of your employer or client. It’s clear that encrypting one’s hard drive has become a necessity. There are good open source software solutions for this, for example TrueCrypt (Windows, Linux and OSX) and the LUKS/dm-crypt system. However, such software encryption systems require a small chunk of your CPU capacity, and also affect SSD performance and durability to a lesser or greater extent, depending on the controller.

Intel 520 self-encrypting SSD. Image courtesy of Anand Tech.

Intel 520 self-encrypting SSD. Image courtesy of Anand Tech.

A number of SSD drives now implement real-time AES encryption in hardware. Usually the reason for this is to enable fast secure erase: When the AES keys are destroyed by the firmware, a very cheap operation that requires almost no writing to the flash, no data on the whole SSD can be read, and can thus the data can be considered securely erased. The encryption and decryption take place in the controller hardware, so there is no performance hit. The Sandforce SF2281 controller is one of the more well-known SSD controllers that does this. In some cases, the manufacterer uses the HDD password or ATA password (configurable via many laptop BIOSes, very few desktop BIOSes, or the ATASX BIOS extension) to encrypt the AES keys. This means that even if the manufacturer got hold of your drive, and you had set a strong ATA password, they would probably never be able to decrypt your data. I call this usable built-in-hardware-based full disk encryption. In these cases, you do NOT need to install third-party software full disk encryption, and can enjoy the full performance of your SSD. In many other cases, the encryption keys are stored in the drive firmware, but are NOT explicitly encrypted with a user-supplied password. This is non-usable encryption, because in theory the manufacturer or a sufficiently skilled hardware hacker can extract the encryption keys from the drive firmware and decrypt all of your data. In these cases, you ABSOLUTELY have to use a third-party software disk encryption software tool. The purpose of this post is to keep a list of current SSDs with usable and non-usable built-in hardware-based full disk encryption. Whilst recently shopping for a suitable SSD, this information was unreasonably hard to come by, hence this list. If you have additions or corrections, please let me know in the comments.

SSDs with USABLE built-in encryption:

Intel 320

This post and this post by an Intel representative confirm that the AES keys on the Intel 320 SSD are encrypted with the user’s ATA password. The second gives more detail on the implementation details, for example that the ATA password itself is also stored in non-reversible hashed form in the drive firmware. The white paper linked to under the Intel 520 heading below confirms the working of the 320 encryption setup.

Intel 520

This is the first Intel SSD making use of the Sandforce SF-2281 controller. Due to a bug in the controller, the drive does AES-128 encryption (instead of the advertised AES-256). AES-128 is still considered to be sufficient for most purposes. After two unsuccessful attempts getting a clear answer on the details of the Intel 520 encryption directly from Intel support, I finally stumbled on this white paper by Intel: Managing Intel Solid-State Drives Using Intel vPro Technology (mirror here). On page 3, in the grey box at the bottom of the page, we see the following text (bold words by me):

How Self-encrypting drives (SEDs) Work: SEDs, such as the Intel® SSD 320 Series and Intel® SSD 520 Series, have a drive controller that automatically encrypts all data to the drive and decrypts all the data from the drive. The disk encryption key is never present in the computer’s processor or memory, where it could be accessed by hackers. The key used to encrypt and decrypt is securely stored only on the drive. Because the disk encryption key is encrypted with the ATA (Advanced Technology Attachment) passwords, the key is made accessible to the drive only after successful user authentication; without the key the data remains encrypted on the media. Authentication of the user is done within the SED by supplying the ATA user password, which is isolated from the OS. Therefore, attacks on OS vulnerabilities cannot affect an SED’s pre-boot process.

That’s a pretty conclusive statement by Intel that both the 320 and the 520 encrypt their AES encryption key with the user-supplied ATA password. After a few weeks and some mails with Intel tech support, I also received the following confirmation concerning the Intel 520 SSD:

Yes, ATA password is used to encrypt the encryption keys stores on the SSD. In other words: The Encryption Keys depends on the ATA password to decrypt them. The ATA password is not used in combination with the Encryption Keys to encrypt the data.

Intel support furthermore confirmed that the Intel 520 is compliant with FIPS-197.

SSDs with PERHAPS USABLE built-in encryption

In these cases there are indications that the mentioned drives are encrypting the encryption keys with the ATA user password, but I have not been able to find more conclusive confirmation. If you find anything, please let me know it the comments, because eventually I’d like to move them out to the list of USABLE or NON-USABLE encryption.

Plextor M5 Pro

On the product page the graphic shows quite clearly that ata passwords are related to encryption keys, but it does not specify in which way these are linked. A reasonable approach would of course be that the key is encrypted with the ATA password, but until that’s confirmed, this drive remains on the “perhaps”-list.

Samsung 840 Pro

Again it’s far too hard to find conclusive information on the encryption implementation. On this product page, we find the following text:

Keep your data safe with Self-Encrypting Drive (SED) Technology Simply enable an HDD password via your computer’s BIOS, and Samsung’s SSD 840 applies data encryption automatically.

This is not as conclusive as I’d like, but there is an implication that there’s a link between the HDD password and the encryption on the Samsung.

Samsung PM830

This drive is not to be confused with the consumer-oriented Samsung 830. The PM830 is a special professional OEM version, found for example in Dell Latitude laptops. There are indications, such as this great 2012 overview paper, titled Hardware-based Full Disk Encryption (In)Security Survey, by Tilo Muller, Tobias Latzo, and Felix C. Freiling (accompanying website with demonstration videos), which mention the PM830 as an example of hardware-based full disk encryption. I’m still searching for the cited spec document that might confirm whether the PM830 encrypts its AES-256 keys with the ATA password, and also the possible password-length limitations.

SSDs with NON-USABLE built-in encryption

OCZ Agility / Vertex 2 / 3 / 4

In this posting on the OCZ Technology Forum, we see that in at least some of the OCZ SSDs, “The encryption key is not directly linked to the ATA Security password (or the BIOS password).” I have not been able to find more specific information about other OCZ offerings. However, my expectations are not very high based on this previous work by OCZ.

Conclusion

  1. Manufacturers of SSDs with built-in encryption are doing an absolutely TERRIBLE job of informing their customers of their specific encryption implementations. For something as critical as full disk encryption, I would expect full disclosure. If the encryption approach is good, disclosing its details won’t affect its security.
  2. The only SSDs that I’d recommend in terms of usable built-in disk encryption are the Intel 320 and 520 drives. It would be great if this list could be expanded. If you have a direct connection to the relevant persons at the various manufacturers, please make use of this and let me know of the results so I can update this blog post.
  3. Your BIOS has to support the full 32 character ATA password specification. The Samsung laptop I’m typing this on only supports 8  character ATA passwords, so I’d think carefully about installing a hardware-based encrypted SSD in here. My desktop with the Intel 520 SSD has the ATASX bios extension and supports up to the full 32 characters. When you buy a new laptop or motherboard, make sure it has a good ATA security extensions implementation, supporting the full 32 characters.
  4. Although ideally the built-in hardware encryption would be usable and secure, the disappointing state of affairs leads me to the conclusion that a good option at this point is still to select an SSD that is impacted as little as possible by the software encryption (avoid the Sandforce controllers, or any other controllers that make use of hardware compression), and then use a solution such as TrueCrypt or luks/dm-crypt (even for a non-Sandforce controller such as on the OCZ Vertex 4, the negative impact is significant, unfortunately). For my next SSD purchase, I will again compare the super-fast hardware encryption of the Intel 520 vs. SSDs that are able to cope to some extent with software encryption, although I am currently leaning towards the Intel 520.

Other resources

  • Vincent Tenniglo sent in this article by AnandTech where Anand himself experiments with the TCP Opal 2.0 compliant Crucial M500 and the Windows 8 eDrive support. In theory, with eDrive-compatible drives (meaning Opal 2.0), Windows BitLocker makes use of the drive’s hardware encryption. Ed: Because this is Windows closed-source, we are unfortunately even less sure of what’s happening behind the scenes. It’s an interesting development nonetheless.
  • Great 2012 overview paper, titled Hardware-based Full Disk Encryption (In)Security Survey, by Tilo Muller, Tobias Latzo, and Felix C. Freiling. Also see the accompanying website with demonstration videos.

Updates

  • 2014-07-02: Updated with AnandTech Opal 2.0 Windows eDrive Crucial M500 article submitted by Vincent Tenniglo.
  • 2013-02-08: Updated with confirmation by Intel tech support concerning the Intel 520.
  • 2013-01-15: Updated link to Muller et al. overview paper.
  • 2012-12-23: Added the Samsung PM830 to the “perhaps” list (thank you Pieter Kitslaar), and linked to great hardware-based full disk encryption overview paper.

170 Comments

  • I recently got a new Dell Latitude 6530 laptop which has a Samsung PM830 SSD. This also supports AES 256-bit encryption.
    According to http://joeraff.org/20120704/software-encrypted-ssd-performance-a-surprising-outcome/ it does use the HDD password but only supports 8 character MAX which is not that great. But I think you could add it next to the 840 in the list.

    • Pieter, thanks for popping by!

      As I understood, the consumer 830 does not expose encryption to the user. Some OEM versions, like the one in your Dell, reportedly do. That blog (I fixed your link) is a bit thin on sources.

      I did some more searching and found this: http://www.dell.com/support/drivers/us/en/19/DriverDetails?driverId=F76F0

      Is the 830 in your Dell also a “Samsung PM830 256GB FDE 7MM”? The FDE in there = full disk encryption. It also seems the PM830 (vs just the “830) is the professional version only found in OEM products. I think I can add this specific model to the “PERHAPS” list. Please do keep me up to date if you run into more details as to the link between ATA password and the AES keys, as well as the 8-character limit.

      • I am currently evaluating this as well, and it seems that at least mainboards from intel and asrock have the same 8 character limit.
        I am left wondering if this enables brute force attacks, as this really depends on drive behavior. Old drives used to be restarted every 5 tries, which made brute forcing even for the shorter password pretty much prohibitively expensive. But many drives also had backdoors and master passwords, and I am not really comfortable with this idea.

        The 8 character limit might stem from the fact that the maximum length for an ATA password is 32 bytes, which might fit depending on the encoding and localization. On the other hand, 8 characters is just the old unix limit which has been dragging security down in many places just because it always was so, and we all know that BIOS development isn’t really on the forefront of anything.

  • Any chance you can confirm or not on the 520′s:

    1: A TPM chip is NOT required period for this to work. The TCG OPAL standard states it not in the FAQ (http://www.trustedcomputinggroup.org/files/static_page_files/B1105605-1D09-3519-AD6FD7F6056B2309/Opal_SSC_FAQ_final_Jan_27_4_.pdf) but would love it confirmed before I spend money AS Intel never stated, far as I can tell, these are officially Opal compliant.

    2: Happen to know if Intel plans to fix the controller? I.e. is it a hardware failure or something they can fix in the future via a firmware update.

    • 1. It does NOT require a TPM chip. I am running the Intel 520 with encryption on a board without any TPM.

      2. What do you mean by “fix the controller”? If you’re referring to the AES-128 instead of AES-256 support, probably not.

  • One BIG question concerning any/all of these drives having usable crypto built-in: At what point are the keys used to encrypt/decrypt the actual drive generated? I understand the details of encrypting those keys by way of an HDD password, but I wonder, what is generating the actual keys in the first place? Can the consumer do anything to change those keys? What algorithm is used to generate the keys? How is it seeded? Exactly what algorithm is used to hash the keys?

    According to a post at AandDTech, someone spoke with Samsung who stated that the 840 Pro requires a bios capable of setting an HDD password AND contains a TPM chip. If that’s true, then people having systems without a TPM will be lulled into believing that they have locked-down their drive by setting an HDD password. You also pointed out the need for a bios that supports 32 character passwords — yet another major detail that the drive manufacturers don’t specify.

    I assume that the process of manufacturing the drive includes generating keys that it will use. Is there a way to change those keys before you use the drive for the first time? If not, then isn’t it possible that a record of each drive’s serial number and its key exists somewhere?

    Any reasonable documentation that outlines how *anything* implements crypto technology begins with an explanation of how the underlying key(s) in play are generated. PGP, TruCrypt, and MSFT Bitlocker all document very thoroughly details concerning what/how/when keys are generated, the exact algorithms used to encrypt those keys, where the keys are stored, and the protocols for decrypting those keys.

    The complete lack of documentation regarding the self-encryping drive’s crypto technology makes the security of those drives highly questionable.

    Finally, I think its noteworthy that modern processors all have hardware encryption/decryption built-into the chips themselves, so there won’t be any major performance benefit of using a self-encrypting drive in a system using something like an Intel i7 chip. In the little bit of testing I have done on a box containing an i7 chip, I have seen very little perf. degradation by turning-on Bitlocker with 128 bit AES encryption.

    I like the idea that a self-encrypting drive is going to be immune to O/S pre-boot holes. Self-encrypting drives also don’t come with the headaches associated with backing up and restoring systems using software encryption. These are major benefits. Its really too bad that the technology in self-encrypting drives is so dubious.

    • 1. When you do a secure erase (recommended when starting with a new SSD), the firmware generates a new random encryption key. This is one of the reasons for implementing hardware-based AES encryption: fast secure erase!

      2. The performance impact of third-party software encryption on SSD drives is significant. This is not due to the CPU needing more time (you’re right that AES-NI helps here), but due to the way modern SSDs store your data. Encrypting the data in software beforehand negates a whole bunch of optimizations in the SSD, leading to severe performance degradation.

      • Thank you for the response. I’m wondering if you would elaborate on your statement that 3rd party FDD software causes a significant perf. hit due to the way modern SSD’s store data.

        It seems to me that one stream of bits is just as good (or bad) as any other. Whether the bits were previously encrypted by software or not is entirely transparent to the SSD controller, so should not affect in any way how an SSD stores those bits. All the SSD controller knows is that the O.S. has given it a stream of bits with an instruction to serialize them to its storage medium. It shouldn’t know or care where those bits were before they arrived at the SSD. No matter what went-on during their prior journey, all bits are entitled to the same love and equal treatment under the laws set forth in the firmware code. The processes, procedures, and optimizations it undertakes should be the same on the bits, whether encrypted or not.

        Am I wrong?

        • You are wrong. :)

          Many modern SSDs use on-the-fly compression to improve performance. Not only the well-known Sandforce controllers do this, also many of the custom firmware designs. Encrypting the data beforehand makes it significantly less compressible.

          Read this answer on superuser.com for more this and more problems with compressing SSDs + third party encryption: http://superuser.com/a/358137/130835

          Even with the Crucial m4, which does not compress data on the fly, third party encryption still has a significant effect: http://www.ausgamers.com/forums/general/thread.php/3236998#post3237039 (the poster claims it’s not a problem, but looking at the measurements, that’s a huge hit)

          The bottom-line is that SSDs use all kinds of tricks (modern ones have multiple processors on the drive!) to increase performance and increase the lifetime of the drive. Your logic that all types of data should be the same in the eyes of the drive does not hold anymore. :)

    • I asked Samsung support about the requirement of a TPM chip for the SSD 840 EVO.
      The answer was, that an TPM chip is NOT required for the encryption to work. The only requirement is , that the bios is able to set / pass the password to the ssd controller.

      By the way, not only the unknown implementation of the encryption in the ssd hardware is a potential security risk, but also using the Bios functions for setting the HDD password. For example, I figured out that my DELL E6400 sets only the ATA-User-Password to the password that I provided, but sets a second so-called ATA-Master-Password to a unknown “dell secret”. This means, DELL would probably be able to unlock the drive or a script kiddy that could find a DELL HDD keygenerator online… Solution for this is as follows: Don’t use any Bios functions to set HDD Passwords, do it directly with HDPARM tool in e.g. Parted Magic.

      • Not to worry. The Master password (which is generally fixed in the BIOS, you can’t set it) has two modes. One is that it simply acts as a second password. This is really stupid since, as you observed, only a zillion people probably know it. There goes any security you were trying to achieve.

        The other mode only allows the Master password to be used to reset the drive, effectively wiping any data on it. Should you forget your password (or someone steals it), this mode doesn’t allow you to recover the data, but you can recover the drive and start over.

        Note: Any password you set with a tool like HDPARM can be read by anyone else. This varies per drive vendor, but I understand that most do store it only as a hash. If so, and if you use a REALLY GOOD password, then you are OK. By “really good” I mean something very random, uppercase/lowercase/numbers, and 16+ characters long. If your drive stores the plaintext password then forget it. If you use a poor password just realize that the person with your drive isn’t going to be limited to 5 tries a second or anything like that. They will copy the hashed password to their machine and attempt to crack it at full speed. There are even web services, running multiple machines, who offer to do it. So you want at least 100 or 128 bits of entropy.

      • P.S. Don’t think that a simple password, once hashed, is secure just because the hash used is a good one. Yes, trying to “undo” the hash is near impossible but that isn’t what the thief is going to do. He will probably use one of the standard cracking programs to try dictionary words, then a brute force attack. So it won’t matter how good the hash algorithm used is. When he tries “p@ssw0rd” and it matches what you used, he will get the same resulting hash and now he knows your password.

  • Handy article, thank you. Here’s another candidate:

    Kingston V200+ probably counts as ‘perhaps usable’. I’ve got one for my laptop so I have reasonable confidence that client data is safe in case of theft, loss etc; encryption enabled through ATA password mechanism. It’s apparently Sandforce based, and probably does AES-128 encryption. I don’t know the detail of the implementation though. One reference to the encryption here,
    http://news.softpedia.com/news/Kingston-SSDNow-V-200-and-KC100-Affected-by-Encryption-Flaw-275237.shtml

    and Kingston’s own page on the drive,
    http://www.kingston.com/en/ssd/vplus#svp200s3

    • Can you find any more information, for example in the manual that you got with the drive, or from tech support? The two links are very thin on information… All Sandforce conroller drives encrypt, the question is how exacly they use your ATA password. Ideally, it should be used to encrypt the randomly generated keys.

      I simply logged a support ticket with Intel, and after some weeks finally got a clear answer confirming this for the Intel 520. Would you be interested to try something similar for the Kingston?

      They need to answer YES or NO to the following questions:
      1. Does the V200+ encrypt its AES keys with the ATA password?
      2. Is the ATA password stored as a non-reversible hash on the firmware?

      Would be great to add the drive to the top list, and not the “maybe” list. :)

  • Thanks again for the reply. I understand the issues surrounding encryption and compression, and see what you mean there. Encrypted files are frequently larger than their decrypted counterparts. There are also tricks for encrypting text that can’t be used on encrypted text. So, I can see how 3rd party FDD encryption could have the effect of reducing a drive’s overall capacity, and arguably their lifetimes.

    I’m not sold on the idea that 3rd party crypto software *necessarily* causes performance degradation, at least not when running on a processor having dedicated crypto logic. Obviously, it also depends upon the drive too, so the trick here is to use drives that are not implementing a lot of compression. Don’t get me wrong: I would prefer to use a self-encrypting drive for the reasons I originally stated — I am puzzled by the fact that the manufacturers publish NOTHING about their encryption technology; not even a user’s guide.

    I’m using a Samsung 830 with Bitlocker 128 bit AES. The various benchmarking tools I have used on it reveal that the drive performs almost exactly according to Samsung’s published specifications. That does not prove that Bitlocker is not a drag, but it implies that it is not a significant factor in limiting the drive’s performance.

    When I get around to it, I will decrypt the drive and publish before and after results. From what I see now, I will be very surprised if there is much perf. improvement once the drive is decrypted.

  • Hi Guys,
    I think the reason True Crypt (and BitLock also might fit in the same category)doesn’t recommend using software based encryption on SSD’s isn’t so much because of compression issues or even a speed hit, it’s more a problem for the wear leveling firmware used onboard SSD drives.
    The way i see it, when you write some data to an SSD the firmware spreads it around evenly on different NAND chips and tries to use them all evenly so as the name implies, the NANDS wear out evenly, thus getting the longest life possible out of the NAND chips limited write span.
    BUT software like TrueCrypt write random data to the entire drive so that someone can’t differential between encrypted data and empty drive space, see?
    As far as someone reading the drive, the entire drive is full of the same encrypted data. SSD’s would wear out very quickly with such a data handling scheme bypassing their internal data wear leveling tricks. If all the data on every bit of NAND looks exactly the same (random bits)then the internal firmware can’t do its job of balancing the data over less used empty spaces. So basically encrypting the entire SSD is like wearing out every single bit of NAND memory all at once. Totally defeating any chance of wear leveling firmware to properly extend the life of the NAND chips, and i would think extremly shortening the life of the SSD.
    That’s why I think the internal encryption handled by the ssd’s own firmware is ideal and secure the problem is there are hardly any motherboards with HDD password Lock capability.

    I wish even an add in SATA controller card would be sold with HDD Password feature enabled in the cards own BIOS which would allow SSD’s to be password locked before the motherboards BIOS even gets to detect the drives.
    That’s what I am hoping to find in the future.
    Thanks for this page, it’s helpful!
    Regards all,
    AnthonyNYC

    • Thanks for stopping by!

      The effect of third party encryption on the SSD wear-leveling is certainly also an issue. I think we all agree that hardware-based FDE is to be preferred, but that we need more transparency from the SSD manufacturers, and that we need better support from the motherboard makers.

      As you will have seen elsewhere on this blog, the ATASX BIOS extension to a certain extent alleviates the motherboard-support problem, but it’s still not ideal.

    • Actually, the best reason not to use software-based encryption on SSD’s is security: http://www.truecrypt.org/docs/?s=trim-operation

      But I guess that it is still more secure than obscure hardware encryption that we know nothing about.

      • So when did you last compile the truecrypt source code yourself? Most people just use the binaries. There’s not much difference between using the truecrypt binaries as they are made available on the website, or an “obscure hardware encryption that we know nothing about”. :)

        • There’s a lot of difference. TrueCrypt is not safe if:
          - the makers of TrueCrypt lied (ie they put a hidden backdoor in it)
          - the makers of TrueCrypt are bad programmers (ie some unintentional bug creates a security flaw)

          Your SSD is not safe if:
          - same conditions as above (ie hidden backdoor or unintentional bug)
          plus
          - the security model of the SSD is bad

          The security model of TrueCrypt is entirely known. You don’t even need to read the source to know it. The same is not true of the security model of your SSD. The manufacturer of your SSD may have decided to use strong AES-256 encryption… but with a pre-defined encryption key that is stored without encryption inside the SSD, which is just used when the user sets a HDD password in the BIOS. It is not a bug (because it’s designed to work this way), it is not a lie (because the data are actually encrypted with AES-256). It’s just a flawed design. With TrueCrypt, a flawed design would be obvious and the software would quickly get a bad reputation. If your SSD has a flawed design, then you may never know it.

          By the way, I don’t trust TrueCrypt, I would rather trust dm-crypt/LUKS.

          • I agree with you that having fully open implementations would be ideal. On all my non-SSDs I run dm-crypt.

            However, the performance hit + security problems on SSDs are too much. In the absence of an open implementation, I’ll settle for certification (FIPS 197, etc.) and explicit and clear documentation by the drive maker. The Intel 520 comes close (FIPS197, documentation to be found, just not very obvious). This blog post is an attempt to improve the current situation somewhat.

            You have no choice: In the future the market is going to be flooded by SSDs, the good ones will have usable encryption. Eventually you will have to start trusting your drive maker, just like you trust now the maker of your motherboard, its bios and its firmware not to log your keystrokes, or all of your encryption keys that have to live in an unencrypted state in your network-connected computer’s RAM. :)

  • I took your advice to a previous comment that the two main questions which SSD drive company support teams need to answer are:
    1. Does the encrypt its AES keys with the ATA password?
    2. Is the ATA password stored as a non-reversible hash on the firmware?

    I asked this question to OCZ support in regards to their OCZ Vector 256GB device as this drive received the highest performance marks on Tom’s Hardware.

    Below is a copy/paste of their reply. Do you think this is sufficient to conclude the hardware level encryption was properly implemented on the OCZ Vector drive? If not, are there other questions I should direct to OCZ support?
    Thanks for the great and detailed blog posting!!

    Comment by Eric Von Stwolinski from OCZ Support.
    “The drive does support 256-bit AES. It is enabled by setting an ATA level password.

    Once a password is set the drive is completely inaccessible until the password is provided. There is no master password for the drive or any way to access the drive other than to supply the correct password once it is enabled.”

    • I’m very happy that you took time to contact OCZ tech support!

      Unfortunately they somehow always manage to evade the very direct questions that we ask, which makes one wonder. He unfortunately has not answered the very simple question (I’ve improved the phrasing somewhat): “Is the AES key, that is used to encrypt the data on the drive, encrypted using the ATA password?”

      With previous OCZ drives, OCZ explicitly said that this was NOT the case. Having drive firmware that refuses to decrypt without the ATA password having been supplied is one thing. Encrypting the AES key WITH the ATA password is another, and is preferable. In the former case, it is STILL possible for the manufacturer to retrieve the AES key from the firmware, in the latter they need your ATA password.

      Do you think you could reply to his answer using my rephrased question above? I would love to add another drive to the list!

      Thanks again,
      Charl

      • I copy/pasted your question and received the following reply, “It uses AES encryption, but this feature is enabled and used by setting the ATA password on the drive.
        If no ATA password is on the drive then the AES encryption is inactive. Only when an ATA password is applied to the drive is the AES encryption used.”.

        I’ve now replied back saying the following. “Unfortunately, your last response doesn’t directly answer my question. I’ll repeat and rephrase my question. Thanks for your assistance in clarifying this important point for me.
        Repeat: ‘Is the AES key, that is used to encrypt the data on the drive, encrypted using the ATA password?’
        Rephrase: I understand that the AES encryption is only activated once the ATA password has been applied. My question is about how the ATA password is applied in relation to specifically the AES encryption key. AES encryption requires a key to encrypt and decrypt the data. The handling of this AES key is the focus of my question. Is the AES key itself encrypted using the ATA password?”

        What do you think? Is there a better way to rephrase the question? I hope I understand what you’re trying to have me clarify and that my rephrase gets to the core of the issue.
        My concern with this 2nd reply is that I thought AES encryption was always active as this is how the SSD drive easily formats/erases the data, by deleting the AES key used to encrypt the data. Apparently either I’ve misunderstood something or the response isn’t very clear/incorrect.

        Thanks again for your feedback and assistance!

        • OCZ replied, “The ATA password is the AES key.

          The key for AES is enabled, disabled, or set using the ATA level password function. If an ATA password is set then AES is enabled, and the key to unlock the drive is the ATA password.

          This means the ATA password must be provided every time you want to access the drive or if you want to change/disable the password.

          Any attempt to access the drive without providing the ATA password would require getting through AES 256 bit, which isn’t possible to do with currently existing computers.”

          The ATA password is the AES key? Is this sufficient to add the drive to your list as properly implementing full disk encryption?

          • You’ve done a sterling job of formulating very clearly the question.

            If we can believe the OCZ representative, it is starting to sound like they did it correctly.

            If we can take his answer literally, they’re using your ATA password (maximum length 32 characters according to the BIOS spec) directly as the AES-256 keys (256 bit = 32 bytes). I’m going to add the drive to the list, with a pointer to your comments here. Thank you very much for taking the time to get to the bottom of this.

            If OCZ has any official documentation further corroborating this fact, please feel free to let me know here in the comments!

            (I do share your doubts with regard to the fast erase by changing the AES keys. I’ll add this to the blog body.)

          • I really don’t believe that that representative knows what he is talking about. Otherwise, it wouldn’t be possible to change the HDD password without either rewriting all of the data or permanently losing it.

            • Indeed!
              I believe that the only way that it can work is that it encrypts data all the time with preset key, probably unique for the device, but unless HDD password is set, those keys aren’t encrypted. Setting HDD password should encrypt the key.

  • I came accross your website while looking for information on the M5 from Plextor, and then came accross one of their blog.

    Basically it seems that they use ATA password:
    The AES key is generated by the SSD controller. To fully secure your data, you will want to set the ATA password on the computer you are using the drive with. Access to the AES key is then not possible without the ATA password. If you don’t set the ATA password, the AES key is accessible; meaning the data on the SSD can be decrypted.

    • I read through that comment. The Plextor representative still does not state whether the AES key is encrypted with the ATA password, and that’s a crucial point. I have just left behind a comment on that blog asking for clarification. Let’s see!

      • Was writing just the same when you posted yours :)

  • Just bought&installed Intel 520 SSD. I made the decision after reading your blog. Full-disk encryption was a critical factor for me. Thank you for taking the time to look up the specs, too bad the manufacturers do not make this information readily available!

    • Awesome, thank you very much for stopping by to comment!

  • Seems the prior comments and replies hit the limit of depth and no further replies are allowed.

    I asked both questions proposed cpbotha and data. My questions and the OCZ tech replies below. Let me know if there is anything else I should ask or if we know enough to be certain?

    Tech, Eric Von Stwolinski: “The notes about AES support are just on the product page for the Vector drive:
    http://ocz.com/consumer/vector-7mm-sata-3-ssd

    My reply: “Hi Eric,

    I have two follow-up questions. I do appreciate your assistance is sorting the AES encryption on the OCZ Vector SSD!
    1) The product detail page you linked is very vague only saying, “256-bit AES-compliant, ATA Security Mode Features”.
    Is there a more detailed public resource that provides the same level of detail you’ve provided regarding the AES encryption key and relation with the ATA password?
    2) Regarding your previous comment two responses ago, “The ATA password is the AES key.” If this is true, then changing the ATA password will change the AES key, since they are the same. The current data on the OCZ Vector SSD, which was encrypted with the prior key, can’t be decrypted with the new/changed key, rending the current data unreadable? To summarize, you’re saying if the ATA password is changed, the current data on the OCZ Vector SSD is lost?”

    Tech, Eric Von Stwolinski: “We have no further documentation about the drive’s security features. This is only a consumer grade drive. Our enterprise grade drives have much more documentation available. If you are looking for a high security drive I strongly recommend looking into an enterprise grade drive.
    If you wish to destroy all information on the drive forever, that can be done using the secure erase function in the toolbox utility. This is the only way to reset and wipe the drive. A secure erased drive is not recoverable by any means.”

    My reply: “Hi Eric,
    Thanks for clarifying the documentation. I’m still not clear on my previous follow-up question. I’ll rephrase and attempt to clarify.
    Is it true that changing the ATA password will render the data on the drive unreadable or inaccessible?
    This is based on your comment that the “ATA password is the AES key”. If this is true, changing the ATA password would change the AES key. Without the previous AES key (previous ATA password) that the data was encrypted with, the drive can’t decrypted the stored data.
    Can you confirm that changing the ATA password makes all data, prior to the ATA password change, on the drive unreadable or inaccessible?”

    Tech, Eric Von Stwolinski: “Changing or removing a password will not wipe out all information on the drive. That can only be done by a secure erase using the toolbox.
    Forgetting a password will render the drive inaccessible and all data is lost, but merely changing or removing the password (which requires that the correct password is first supplied) will not destroy any information on the drive.”

  • Hi, A very interesting read!
    If anyone has time please could they answer the following:
    I’d like to install a new Samsung 840 Pro SSD in my laptop and wondered what order I should do things in. Is the following correct?

    1. Set a HDD password
    2. Securely erase the SSD drive
    3. Install the OS

    My laptop supports TPM and I’m wondering what advantages, if any this will offer to me?

    Thanks
    Simon

  • This page provides some valuable information on SED implementations on current SSD drives. However another big problem seems to me to be the support for ATA passwords within the motherboards from major brands. A lot do not support this Feature!

    Many people who buy the drives you describe can therefore never use the encryption function because their motherboard does not support the method to set the drive encryption.

    Almost all ASUS, MSI, Gigabyte etc motherboards do not support this feature.

  • This is not as conclusive as I’d like, but there is an implication that there’s a link between the HDD password and the encryption on the Samsung

    Yes, the implication is the following: choose an HDD password and the encryption system will be activated. That’s all, it does not imply at all that the encryption key is derived from the HDD password.

    On the product page the graphic shows quite clearly that ata passwords are related to encryption keys, but it does not specify in which way these are linked

    The graphic shows that there is a user password + a master password. Does it mean that the manufacturer has a master password that can bypass the user password?

    • That drive is in the “perhaps” list for a reason.

  • There are only 3 SSDs with encryption enabled beyond a simple ATA password (TCG OPAL).
    Certain versions of the Samsung PM830.

    Specific versions of the Micron (but not Crucial) C400 drive, specifically marked SED.

    And every Crucial/Micron M500 drive, with OPAL 2.0. If you have this drive, a UEFI BIOS, preferably TPM and Windows 8, Bitlocker can manage the OPAL directly. This is a very recent development.

  • Thank you so much for this thorough, thoughtful research. I wish I had found this just a few days earlier! I was so excited to get this massive and well-rated 500GB Samsung 840 (http://www.amazon.com/gp/product/B009NHAFEC/ref=ox_sc_imb_mini_detail?ie=UTF8&smid=ATVPDKIKX0DER) for about $350 total. I’ve never had an SSD, and I’ve been eager to see how fast it really is. I was just looking online at the best way to transfer over my full-disk-encrypted (TrueCrypt) when I saw all the warnings about wear leveling, couldn’t find anything substantial about Samsung’s marketing about AES 256-bit encryption, and went from excited to totally disheartened when I read this article and comments. It sunk in: if I switch over to this SSD, I may never be sure that my data is truly (as you say, “usably”) secure. That’s vital to me, because my work in healthcare absolutely requires (truly secure) encryption of the information I document…. So in light of your really helpful investigation here and the 840′s subsequently questionable security status, I think I’m about to return it to Amazon and go for a smaller but verifiably secure 240GB Intel 520 (http://www.amazon.com/Intel-Series-Solid-State-Drive-2-5-Inch/dp/B006VCP90C) for about $270 total. I’ll happily give up the luxury of keeping worlds of music etc. on this drive in exchange for so much more confidence that my data is truly secure. Anyway, just reporting in, so that 1) you know how grateful I am for the good information you hunted down (and did or did not find) and 2) if there’s any new development about the Samsung 840, you can let me know on here (and maybe I can “enjoy” a second wave of regret, if you end up moving it to the “usable” category after all!!). Many thanks!

    • I really appreciate you dropping by!

      The link you posted is the Samsung 840. Only the Samsung 840 Pro has exposed and usable self-encryption for about a $100 more (it’s also much faster than the 840 straight). Samsung’s own documentation is unfortunately also very vague on the matter, but one of our readers, who bought a 840 straight, has confirmed this difference.

      • Thanks for the reply, and so quick! So it sounds like you’re saying that the Samsung 840 Pro (I don’t mean to favor Amazon, but http://www.amazon.com/Samsung-Electronics-2-5-Inch-SATA_6_0_gb-MZ-7PD512BW/dp/B009NB8WTI) is basically in the USABLE category now? Would you still say the Intel is more secure (e.g., in light of the FIPS-197 compliance)? If not, maybe I’ll spring for the big Samsung 840 Pro after all. (Tangential issue becomes the form factor: I’m on a Dell Latitude E6500, built for 9.5mm hard-drive height. These Samsung SSDs come in “ultraslim” 7mm. The 840 “straight” has versions that come with an adapter, but I’m surprised that I can’t find an 840 Pro version that comes with such an “installation kit.” Maybe there’s some other way of getting the 7mm drive to fit snug in the 9.5mm bay, or maybe not and that’s another factor for your readers to consider: usable built-in hardware-based full-disk encryption in a height that fits their setup. I dunno.)

        And I’m yet more amazed and thankful for your thinking this through with me/us. It’s really generous. Thank you!

        • JB, I have a Samsung 840 Pro, and I don’t use hardware encryption because the amount of information provided by Samsung is ridiculous. I read that the drive requires a TPM module to activate encryption (see the comment by “Geoff” on this page). If this is true, let’s say you don’t have this module, you enable the ATA password, and you think that your data are protected, while they’re not. I think that the drive actually always encrypts its content (so the ATA secure erase is fast and does not require to write to every cell, reducing wear), but we don’t know how the encryption key is stored. Is it stored unencrypted ? Unencrypted only when no ATA password is defined? Is it defined in factory? Derived from the ATA password? If so, is the key derivation function known to be secure? Unless you have answers to those questions, you can consider that your data are not encrypted, even if they are. I don’t know about FIPS-197, but I’d be careful about it, if I were you. If I understand correctly, FIPS-197 just mean that the device uses AES, which is not enough (AES encrypted data is useless if the encryption key is stored unencrypted inside the drive). What you want is probably FIPS 140-2. The Samsung PM810 SSD is FIPS 140-2 certified.

          FIPS 140-2 validation goes well beyond simply testing the cryptographic algorithms—such as AES, random number generation, digital signature, and hashing—into testing the overall security strength, tamper resistance, and risk aversion within the identified secure boundary of the drive

          But still, I wouldn’t be surprised if a device could be FIPS 140-2 certified, but does not provide a way for the user to know if the encryption is really activated or not (what I said about the TPM module). That’s why I use software encryption (LUKS/dm-crypt). It is quite fast, and some CPUs (Intel Core i5 and above) have hardware acceleration for AES encryption. It is not FIPS certified, but I trust it more than anything that comes from Samsung, Intel, and others.

          • Hi Raco,
            Thanks for all the wisdom and trying to think this through together! I’m with you: so, so frustrating that manufacturers don’t just come out with this info more clearly.
            I especially appreciate your lead into FIPS 140-2 and the Samsung PM810. I found a corroborating press release from Samsung celebrating that rating and calling it a first for SSDs (http://www.samsung.com/us/news/20050). (It also seems like that same PM810 model is also known as the 470 Series.)
            You also bring up the possibility that a processor could be especially equipped to do AES without it dragging everything down too slow, in which case one could work around all this hardware-encryption mystery and shortcoming by just going with software, like you’re doing. But no, I can’t :-( My processor’s a P9500, not on this list at Intel (http://ark.intel.com/search/advanced/?s=t&AESTech=true) of AES-New Instructions processors.
            So looks like going with the Intel 520. Or just saying “uncle” and waiting to see if this market improves (i.e., becomes more transparent and with moresome more clearly secure hardware encryption).
            Anyway, just emailed Samsung too, just to see if they can give any more info.
            Sorry if this is like spewing too much or old news into the forum. I hope I don’t bring down the quality at all; this has been a really, really helpful thread.
            Thanks,
            JB

        • Hi folks. I emailed with Samsung a bit this week, asking them the questions given above about a) the precise relationship between the ATA password and the AES keys and b) where the ATA password is then stored on the firmware. Similar to the above discussion involving OCZ, I don’t think I got the direct answer I was looking for. But here’s what they said, for what it’s worth: “The 840 Pro SSDs support AES 256 full disk encryption which means that if your computer has the ability to create a password from BIOS to lock the entire drive the SSD will support it. This password is entered at the hardware level. If you set the password then move the SSD to another machine the SSD will remain locked. You will only be able to unlock the SSD if it is connected to the machine where you set the password from inside BIOS.” Also/later: “The ATA password is itself encrypted. The ATA password is non reversible but is [sic] can be erased using a secure erase.” Does this affect the verdict on Samsung 840 Pro? Are we saying usable or still unsure? Thanks, all. JB

        • Thanks JB, this is interesting. Samsung said “You will only be able to unlock the SSD if it is connected to the machine where you set the password from inside BIOS“. The question is: how does the disk know that it has been installed in another computer? This may indicate that the SSD requires a TPM module. I wouldn’t be surprised if, as I said in a previous comment, the absence of the TPM module would not trigger any notification of any kind, letting the user think that the setup is secure because he entered an ATA password, while in reality only the basic ATA protection is activated. Also, even if you have a TPM module, does a failure of your motherboard mean that your data are lost forever?

          I’m no encryption specialist, but in my opinion, the best way to provide hardware encryption would be to accept an ATA password but to not store it, even in a non-reversible form. The disk would not really implement protection at the ATA level (which we don’t care about as the whole disk is encrypted), but it would derive an encryption key from the ATA password given by the user (with some key derivation function as PBKDF2). This encryption key would be used to encrypt another encryption key, which in turn would be used to actually encrypt the data on the SSD. That way, you can change your ATA password without re-encrypting everything on the disk. And because the ATA password is not stored in any form, it won’t be breaked (unless PBKDF2 has a flaw). SSD manufacturers don’t tell how they store the ATA password. Samsung says “non-reversible”, but non-reversible does not mean secure at all. f(password) = ‘a’ is a totally non-reversible hash function, but it is not secure at all (as any password would grant access). If the ATA password is stored in MD5, then the security of the disk is as weak as MD5, while it should be as weak as AES.

          • Raco, thanks for the reply. Yes, I see the connection between those earlier thoughts about TPM and this response from Samsung. I have a TPM, so maybe I would go for it—but no, especially in light of what you say, there are still too many question marks I think :-( So I just ordered the Intel 520. Thanks for all the guidance, folks. It’ll be interesting to see how this all plays out, if companies come out with more info on their process, if they go to the more secure processes you’re describing. I’ll keep following this thread. Again, thanks everyone for the thorough research and discussion!

          • Samsung support replied to me, that a TPM is not required for the encryption of the SSD (840 EVO) to work. Only requirement is, that the Bios can pass a Password to the SSD controller. Furthermore, they said, if the Bios is using TPM for this procedure, you might have the additional protection that the drive cannot be unlocked in a different computer.
            Also, from what I know and researched, not every Bios is passing the Password, which the user entered in the dialoge, in the same way to the disc controller. This would also implicit problems when moving the SSD to a different machine (example: Newest Dell E6400 bios passes the User password directly to the hdd controller, but older Dell bios from different system pass the keyboard scan codes to the controller).

            • I’m curious about what happens if you use TPM and your motherboard burns up. Does this mean that there is no way to use the drive on another machine?

              ATA Only: Yes, the BIOS might (probably?) mess with the password before sending it to the drive. A given vendor probably uses the same approach, but no guarantee. Thus, unless you have a twin machine, you might be up the creek if the motherboard burns us.

              Can you say “Backups”? :)

              Opal Only: Since the PBA stores the password, and the BIOS isn’t involved, most of the vendors tell me that the drive can be moved. Good! Notice that I said “most”. You have to check because some say “no”.

              • I had already some similar experience. I have set HDD password for Samsung SSD 840 Pro. Later I have updated BIOS and the password stopped to work. Hard to say why exactly. I imagine that the HDD ASE key is encrypted using HDD password that is combined of password provided in BIOS and some Motherboard/BIOS key.
                There was similar case somewhere on the net, and AFAIR the solution there was to restore previous BIOS, which solved the problem. Unfortunatelly on my mo-bo it was impossible to revert this concrete BIOS version to previous one.

  • My question is with the automatic encryption on every SSD, what happens if a user or a business has a disaster and the controller doesn’t work anymore? They may not have wanted encryption, but their important data is encrypted and now lost permanently I believe (if they didn’t have a working backup). Of course everyone should have a backup, but not everyone does, and not everyone has a working one – they don’t know it until they try to use it. This seems to remove one important avenue for disaster recovery without the user’s knowledge. They were never given the choice of which was more important between protection of their data from thieves or protection from more mundane accidental loss of their data. Of course this doesn’t affect SSD makers at all so they don’t care. “Secure data” sounds good to everyone, right?

    • If that were to happen, and the encryption keys are lost, you lose your data. This is the way it has to be.

      For example, trying to protect users against themselves is the unfortunate reason that the maker of my laptop built a HDD password backdoor into the BIOS, and an extremely weak backdoor at that. (I have to work-around this by booting with a Linux USB, unlocking my encrypted HDD, and then soft-booting into my real Linux, all bypassing the BIOS) The requirement for a really secure encryption solution should be considered much more seriously than users who can’t be bothered to backup their data. Put differently: How safe would you sleep knowing that even if you were to forget your password or lose your encryption keys, it would still be possible for other interested parties to read and distribute all of your private data?

      The only thing the SSD _should_ be blamed for, is not being completely open about the encryption, how exactly it works and what exactly the risks are to the user. With this knowledge, people would be able to make a better purchase decision, whether they want to be sure that their data is securely encrypted or rather completely open (as you suggest).

  • Well I’m definitely a person that values my privacy but I probably value having my data more. I would prefer to have an out if I need it, and this is only accessible if you have physical possession of the device.

    If it was a work computer and there were sensitive trade secrets on it or something, then maybe I’d be worried about that more, or the company would be.

    With your example of the HDD password backdoor, I agree that is a terrible idea. If a user is setting a password and encrypting their HDD, then they have an expectation that is solid protection and the manufacturer has failed there. However in the situation of SSDs, the user didn’t do this.

    It’s not all or nothing. They don’t have to require every single device to encrypt all data. They haven’t in the past. They choose to probably for manufacturing efficiencies and the consumer doesn’t get the choice.

    “How safe would you sleep knowing that even if you were to forget your password or lose your encryption keys, it would still be possible for other interested parties to read and distribute all of your private data?”

    I’d sleep ok because I have the device, I don’t expect it to be stolen, and I’d rather be able to get my data if the device failed and I screwed up my backup than prevent bad guys from seeing it.

    • Actually in the last part I should have included this -
      I never encrypted the device. It did that automatically as default behavior. If I chose to encrypt it then I would expect that it would be protected from bad guys reading it or from myself trying to fix my mistake of not backing up properly. However that’s not the situation. I didn’t choose to encrypt it.

    • Hi Mike, I think I understand your concerns here but maybe I can help in a way.
      Traditional Hard Drives stored data in physical locations created magnetically around the disc like a record with grooves almost. So if the drive electronics were say to go bad, theoretically the data can still be read off the disc, and most can be re-created because of it being stored like that.
      But the way Solid State Drives function in general, data isn’t located in any particular spot for too long because the devices electronics are constantly shuffling it all around so any particular flash cells don’t wear out before they all get used up pretty much evenly. This is what is know as wear-leveling and the SSD firmware does this internally constantly. So basically, even if the data wasn’t encrypted at all in an SSD drive, if the onboard electronics (the controller and its allocation maps) where to die on you, then having someone try and read the data off the chips somehow directly and try and reassemble bits and bytes from all over the place, scrambled and shuffled around daily so that they can try and figure out what kind of file that originally was I believe would be next o impossible to begin with.
      Knowing this, your fear that it is the automatic internal security that will not allow your data to be retrieved is unfounded. Your data would basically be irretrievable anyway if stored on an SSD drive if the drives onboard circuitry went bad. It’s just the nature of the new technology.
      At least this is what I’ve read somewhere about SSD’s in general, it could be wrong, I am not positive.
      Having said that, if you never set an HDD Password using your BIOS settings, then if the computers electronics die, nothing happens to your data on the SSD. You can easily connect it to any other system and read the data back. Only setting a password would require the original hardware to be present.

      I hope this helps and makes sense. If you think you would sleep better at night because you think you might not have backed up all your data safely then perhaps using conventional magnetic disc storage will help you?
      SSD’s are in general prone to complete data loss if the electronics die, at least much more prone than conventional magnetic storage media I believe.
      Perhaps others can also give their opinions on that.
      Thanks
      AnthonyR

  • I believe that data recovery companies and maybe computer forensics people can recover SSDs. A quick search and look around confirms it. I do know of the wear leveling used, and I imagine that makes it much more difficult to reassemble the data, but they can do it somehow.

    And even if they couldn’t reassemble the data, they would be able to see the blocks of data used in wear leveling and there would be some small file data in there that might be useful to someone. Anyway, wear leveling doesn’t kill all chances. I’m sure data recovery is an expensive option but it’s an option.

    “Having said that, if you never set an HDD Password using your BIOS settings, then if the computers electronics die, nothing happens to your data on the SSD.”

    Yes. It would have been pretty bad if you couldn’t move your working SSD from one computer to another without bricking it. But what if the controller electronics on the SSD dies and you have one of those that encrypts all data no matter what? Encryption key is gone and probably even data recovery companies have no chance.

    Well all of this is hypothetical discussion for me personally… I sleep fine at night :) I have an SSD but I only have the OS installed to it and all my storage is on a hard disk. I also have a backup. I know that’s not the case for everyone though and I wanted to point out this effect of always encrypted SSDs.

  • Great write up! I’m a little curious about the verdict on the OCZ drives though where it is stated that ““The encryption key is not directly linked to the ATA Security password (or the BIOS password).” What exactly does that mean? That OCZ has a master password that could decrypt the drive and other than that “risk” it would be just as secure as the Intel drives? Thanks in advance!

    • It means that, by definition, the drive is able to decrypt your data without your ATA password, which means that a sufficiently skilled hardware hacker is also able to do so. :)

      • Interesting…now isn’t cracking the ATA password easy with just BIOS access much like cracking the BIOS power on/setup password? If so, then anyone wouldn’t need to be a “skilled hardware hacker’ beyond that point even on the Intel drives or am I missing smth?

        • The better drives store a non-reversible hash of the password, so it’s absolutely not straight-forward. This purpose of this post was to classify good drives and bad drives, at least cryptographically speaking. The good ones 1. store a non-reversible hash of the ATA password and 2. encrypt the AES keys with the ATA password. In short, without the information in the user’s head, the drive is nothing more than an expensive brick.

          • Don’t trust the Intel drives just because the ATA password is used to encrypt the AES key. We don’t even know what algorithm they use to encrypt the AES key. We don’t know what hash function they use to store the ATA password. We know almost nothing, so we should consider that their drives are not secure.

          • Couldn’t reply to Raco’s post for some reason but if Intel drives meet FIPS requirements, doesn’t that indicate some level of compliance with security standards? If not, what would you recommend as “secure” if anything?….thx

          • LS1: Intel drives comply with FIPS-197, which means they use AES to encrypt the data and that AES itself is correctly implemented. But it means nothing about the way the encryption key is made from the ATA password (I’m no specialist, so I may be wrong). FIPS 140-2 is a better certification because it does not focus only on the encryption algorithm. Some Samsung and Seagate SSDs are FIPS 140-2 certified. The manufacturer I would trust the most is Seagate. They provide more information than the other manufacturers, and some of their drives don’t use the ATA password at all (but they are complicated to use because they require special software to boot your computer with).

            If you want to protect your data from some random guy who may steal your laptop when you fell asleep in the subway, then most self-encrypting drives will be fine. But if you fear industrial espionage, if you want to be certain that your data won’t ever be seen by anyone, then don’t use self-encrypting drives. Use software encryption, or use software encryption over hardware encryption (may sound overkill, but it’s probably a good option is you really want strong security).

            Keep in mind that I’m not a cryptography specialist, though.

  • I have a pair of Samsung 840′s, not the PRO model. The other day I looked into their SED capability. Both the Samsung website (main page describing the drive, near the bottonm) and their Tech Support confirm that they are SED, using 256 bit AES. Tech Support told me that the encryption is running all the time, regardless of an ATA password or not. They also told me that the ATA password is stored in the drive as a one-way hash. They did not know what hash algorithm was used.

    However, Tech Support told me that they are not OPAL compliant and do not support the Secure Erase function, nor is there any way to change the factory set encryption key. OPAL compliance is on the horizon, they said. This surprised me since Samsung is often mentioned on the TCG website as an OPAL supporter, and I found a Samsung tech note for a drive produced in 2011 claiming it was OPAL compliant.

    Samsung Tech Support was unable to point me to any documentation on the 840 drive other than the extremely skimpy “specifications” on the website. There is no manual for it.

    JB: I also have a Dell laptop. Mounting the “internal” drive was easy. Just screw it in. Everything lines up just fine. Mounting the “external” drive requires a work-around since gravity pull the drive down but it needs to be up. I simply put a small piece of folded cardboard in first. This was all it took to make the drive position itself correct to plug into the socket. Securing the rear end was then no problem also.

    Cpbotha: I doubt that these drives are “usable” by your definition. When I entered, and later changed, the ATA password via the BIOS the data previously on the drive was still available. Thus I would conclude that the key is used for encryption and it stayed the same.

    Dell Tech Support was uncertain about this, but the BIOS offered an optional feature when I set up the ATA password. If offered to erase the drive if the Recovery Password was used to change the ATA password, instead of the normal method which requires that you know the old password. This seems like a good idea to me, since anyone at Dell can generate the Recovery Password at will. Apparently it is based on the machine’s Service Tag or something like it which is unique to the machine.

    One thing I am unclear about: How secure is the ATA password? I read one article which said that there was a program which could attac the BIOS and remove it within seconds. Is this so?

    • Correction

      > Thus I would conclude that the key is used for encryption and it stayed the same.

      Should be:

      Thus I would conclude that only the key, and not the ATA password, is used for encrypting the disk’s data.

    • I have also read that the BIOS passwords are easily attacked (or at least cleared) but your data on a self encrypting drive should still be secure since there’s a seperate key internally that is used to encrypt the data…at least that is my understanding of it.

      • The data on a SED drive is automatically encrypted. So if the drive is disassembled then the disk platters (or FLASH memory) contains only encrypted data. When used normally in a computer the data is automatically decrypted, also. What secures it from being accessed is the password.

        Think of a SED drive like a bank vault. The encryption is like the steel vault. The authentication, which allows access to the steel vault, is like the door to the vault. Having an impenetrable vault but with an open (or easily openned) door offers no real security.

        In an Opal drive the authentication is handled very securely with a shadow MBR which runs a pre-boot authentication routine. The data on the drive isn’t unlocked till the user has authenticated. On a SED non-Opal drive, authentication depends on an ATA password.

        The various BIOS’s and drive manufacturers handle ATA passwords differently. A good BIOS will pass the hash of the password, not the password itself, to the drive. From what I gather, the drive stores this sometimes (all the time?) in a non-secure area which can easily be read. If the password isn’t hashed then it’s trivial to see it. If it is hashed then you can attempt to crack it. Some BIOS’es limit the password length to 8 characters. Thus the very poor reputatiion ATA passwords have.

        Perhaps SED (non-Opal) drives do a better job, storing the password where it can’t be read while the drive is locked. I don’t know. I’m trying to find out how Samsung and Intel do this currently. Does anyone here know?

        Other than the somewhat obsolete Samsung P810 drives, the only Opal SSD drives currently shipping that I am aware of are from Micron / Crucial. The M500 is the current model. Samsung is shipping a SSD 840 EVO model which they say will be firmware upgradable to Opal sometime next month.

        • That being said should the Crucial M500 be listed under “Drives with USABLE encryption”?

          • I would think so. It is Opal 2. Indeed, any drive which is Opal, 1 or 2, should be listed, I believe.

        • I have a deeper understanding of things now. Let me revise some of my earlier posting on 8/15.

          > The various BIOS’s and drive manufacturers handle ATA passwords differently.

          This means that moving a ATA password protected drive to a new machine might not work if the new machine’s BIOS delivers a different version of the password to the SED drive than the old machine’s BIOS did. Ouch! You better hope that your motherboard doesn’t die.

          > A good BIOS will pass the hash of the password, not the password itself, to the drive.

          Although this sounds like a feature at first (it did to me!), it really doesn’t help security at all (see below) and just complicates compatibility (see above).

          > From what I gather, the drive stores this sometimes (all the time?) in a non-secure area which can easily be read.

          If the drive stores the password as given to it by the BIOS then it doesn’t matter if the BIOS hashed what the user typed in or not. Either way, what the drive uses to validate the authentication can be read from the drive. It can then (using a simple custom hardware interface) be used to unlock the drive by emulating a BIOS authentication attempt.

          On the other hand, if the drive does something to protect the password from the BIOS then it gets interesting. It could hash it before storing it or it could store it in some non-readable (except by the drive’s firmware) part of the drive. In the latter case, the drive would have to prevent firmware updates on an unlocked (if protected) drive, too.

          Given this, I see no reason to believe that the Intel 520 and 530 are “secure”. It doesn’t matter that the drive’s encryption key is protected by the user password (or whatever the BIOS sent over) if you can reproduce the user password. In other words, it doesn’t matter how thick the bank vault’s steel enclosure is if you know the lock’s combination.

          I have contacted Intel to find out more. I’m waiting to hear from them and from Samsung.

      • “Thus I would conclude that only the key, and not the ATA password, is used for encrypting the disk’s data.”

        Yes, but the key is (on some drives) encrypted with another key. Which should be derived from the ATA password. This is done on purpose, to allow the user to change his password without having to re-encrypt the whole disk. When you change your ATA password, the key used to encrypt the data is re-encrypted (but does not change) with a key derived from your new password. At least, it should be done this way. According to what Samsung told you, the key used to encrypt the data is set in factory. Do they keep a record of it, along with the serial number of your drive, or is it randomly generated for each drive and even Samsung does not know it? We don’t know, so it should not be considered secure. It’s also possible that all their drives uses the same key. From what they told you, it’s not clear wether the key used to encrypt the data is stored unencrypted or not. It’s possible that if you can break the BIOS password, then you can have access to the unencrypted data. Having a separate key, as LS1 said, does not guarantee that your data are safe when the BIOS protection has been hacked. The separate key is there to add flexibility of usage, not security.

        • “Yes, but the key is (on some drives) encrypted with another key. Which should be derived from the ATA password.”

          On Opal drives I believe that this is part of the spec. On non-Opal SED drives all bets are off, but you would hope so. I agree with what you say about the user’s password being used to encrypt storage (not use) of the drive key.

          From what I read, the encryption key is generated inside the drive itself and can not be read even by the manufacturer. The drives do have individual encryption keys. Again, on non-Opal SED drives how this works is deceided by each manufacturer. I sure wish that they would publish this info!

          Yes, if you can authenticate with the drive (Opal or non-Opal) then you have access to the drive’s data (SED or non-encrypted drives). Leaving the door to the vault open means that the steel vault isn’t doing you any good. :)

          • From what I read, the encryption key is generated inside the drive itself and can not be read even by the manufacturer. The drives do have individual encryption keys.

            I thought about this as well. We’ll never know for sure as they probably hold how this works this pretty tightly. And this would be the controller chip company. They probably don’t want anything to do with the key for individual drives otherwise law enforcement would be able to ask them for it. So they have probably developed a process so that they don’t know the keys and they aren’t saved or easily retrievable, and they can always say they do it that way for best security. They don’t care whether people lose their data or if someone can hide their data from law enforcement as it doesn’t affect their business.

  • I believe that as long as customers care about good security, the manufacturers have to also. Otherwise, they will end up with no customers.

    I spent some more time trying to read the Opal specs. It isn’t easy! They go from just a few, very high-level lines of description to bit level detail.

    Key generation is done in the drive. You can also “revert” the drive back to factory defaults. In this case the key is erased and another generated. It seems that you can also Re-Encrpyt. This done on the fly, in the background, using both the old and new keys. Nice!

    For an Opal drive you need to purchase a management program to set up the Pre-Boot Authentication passwords and run a Pre-Boot program which they put in the Shadow MBR. This is a very secure method, unless there is a flaw in the Pre-Boot program. The programs are generally a stripped down version of Linux. Some vendors are FIPS 140-2 certified, giving you some additional confidence.

    I’ve seen such software sell for $40 – $100 for individual workstations. There are also enterprise management versions which would certainly be nice if you have a number of machines to manage.

    For non-Opal, SED drives all bets are off. You are stuck using the old ATA password mechanism, which is generally very unsecure unless the manufacturer has possibly implemented an improved version. I’m still trying to find out about this from Intel (520′s and 530′s) and Samsung (840′s and 840 Pro’s).

    Non-Opal SDE SSD drives will soon be moot due to the increasing appearance of Opal drives. So vote with your feet. :)

    • So if one got an OPAL compliant drive such as the M500 then they would still have to buy some additional boot software to use encryption or would using Bitlocker for Windows 8 with the “eDrive” support do the same thing?

      • As I understand it, Microsoft’s eDrive requires that the drive itself be an Opal drive. I’ve read that the M500 does meet eDrive requirements. Thus the Bitlocker software would use the drive’s hardware encryption. But there are also some other requirements which your system has to meet, including running Windows 8 and using UEFI (not BIOS) to boot, for example.

        I believe that the Bitlocker software takes care of the Opal interface itself. Here’s a good article about it: http://www.anandtech.com/show/6891/hardware-accelerated-bitlocker-encryption-microsoft-windows-8-edrive-investigated-with-crucial-m500

        • Thanks! I guess this means you wouldn’t need a BIOS which even supports setting an ATA Hard Disk Password as long as you met the other requirements, OPAL, UEFI, Windows 8, etc,?

          • Correct. Side note: From what I read, some (many?) UEFI boots also support the BIOS mode, for those who prefer it instead.

            I don’t know if UEFI supports ATA passwords or not, but an Opal drive doesn’t, so you need not worry about them. :)

    • “I believe that as long as customers care about good security, the manufacturers have to also. Otherwise, they will end up with no customers”.

      Unfortunately, customers don’t care. Even worse, reviewers don’t care. They focus mainly on speed and price. If an SSD is super-fast, it will get very positive reviews. No reviews exist that really care about the encryption system. Sometimes, the reviewer mentions that the SSD can do hardware encryption, but that’s all. So the manufacturers get good reviews in magazines, and they don’t have to try to prove that their encryption system is reliable. I talked with two reknowed reviewers on the web about this. They both told me that they are not able to evaluate an encryption system because they are not encryption specialists. I think that things won’t change until the disks get bad reviews because of their obscure encryption system. Likewise, I was not able to find critics about Opal or FIPS, which shows that people don’t care about security. It seems that no hacker tried to hack a FIPS or Opal certified device. Which is a very bad thing. If no one had tried to hack WEP, then we’d be still using it to secure our WIFI connections, and we’d still think it’s as secure as its name suggests (Wired Equivalent Pivacy).

      • How about this: Some customers care, some don’t. :)

        Also, some reviewers care, some don’t. For example: http://www.anandtech.com/show/6891/hardware-accelerated-bitlocker-encryption-microsoft-windows-8-edrive-investigated-with-crucial-m500. This is an entire (!) review about Bitlocker on a CM500.

        Probably the best way to evaluate the disk’s encryption is to see if it is FIPS 140-2 certified. Check the list yourself at NIST: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2011.htm.

        Note: Don’t get fooled by a manufacturer’s claim that their product was designed to meet the FIPS 140-2 standard. While a good goal, this doesn’t mean that they achieved it.

        No hacker has tried? They generally don’t report failed attempts, so how can you be sure? On the other hand, if the NSA tried and succeeded they might not report it either. If you are this concerned, then you probably should use two, independent forms of encryption. Perhaps TrueCrypt software encryption on an Opal (hardware encryption) drive. :)

  • I was looking at http://www.anandtech.com/show/6891/hardware-accelerated-bitlocker-encryption-microsoft-windows-8-edrive-investigated-with-crucial-m500

    and it mentions that you must have UEFI 2.3.1 (Class II no CSM/Class III). ANy ideas how to determine if a specific PC has that?

  • Did anybody mention the missing possibility to change the AES key which is used for the actual encryption? All stuff performed before the “encrypt(data, key)” process is useless (even not interesting) if for example Intel uses the same “key” for every SSD. Even if it is not the same, Intel could maintain a list of all S/N / keys. For real security this is not enough. I would like to set my own AES key.

    • Most SED and all OPAL drives will not let the user set or see the key used to actually encrypt the data on the disk. There is really no need, thus it would only hurt security to do so.

      Most will let you force the key to be changed. This effectively “erases” the data on the drive because it can no longer be unencrypted. This feature of a SED drive is sometimes called Fast Erase. It takes only a few seconds, thus saving a lot of time if you want to wipe a drive prior to discarding or reusing it.

      btw – Do look for drives which use a 256-bit AES key. Some older ones only used a 128-bit key, and this isn’t considered a good idea for data which needs to be protected for more than 10 years or so.

      An OPAL drive generates its own key. Even the drive manufacturer doesn’t know it. There is supposed to be some random seed to make sure that they aren’t the same. As for SED, but non-OPAL, drives – good luck trying to find out!

      At the end of the day, we have to trust the drive manufacturers to some extent. They could put a backdoor in even if it looks like it is designed and working correctly. With hardware (unlike software), it’s hard to check.

  • I was looking at http://www.anandtech.com/show/6891/hardware-accelerated-bitlocker-encryption-microsoft-windows-8-edrive-investigated-with-crucial-m500
    and it mentions that you must have UEFI 2.3.1 (Class II no CSM/Class III). ANy ideas how to determine if a specific PC has that?

  • In case anyone is interested: Some of the Asus UX-notebooks (the UX31a, in my case) contain an Adata XM11 SSD. I first contacted Adata, but they pointed me to Asus. So I contacted Asus and asked them if the AES key is encrypted with the ATA password and if this ATA password is hashed irreversably, but they refused to say anything, “to ensure the saftey [sic] of the encryption.” I tried to explain to them that secrecy is not a good thing in this case and that if they did everything the right way, then nothing is lost by explaining how they did it, but they kept refusing. Doesn’t inspire much faith in their implementation.

    • Yes! Anytime that a vendor tells you that his method is secret, then you should assume the worst. There is a much higher chance that it is inadequate and/or flawed. This has been shown in many cases over the years.

  • Great thread!

    Am using the ATA password approach on the 960GB M500 in a HP 2760p with a TPM module. Am digging into the details on this exact combination to understand the degree of security. There are many posts on recovering ATA passwords from specific hard drives by using software utilities that write directly to the hard drive bypassing the BIOS, and some direct hardware hacks as well, but each of these is specific to a drive manufacturer and model, and I have not yet found any describing how to recover the ATA password from any SSD nor specifically the M500. Net, while researching, I know I have a modest amount of security via the ATA password on my laptop with the M500, but will keep digging until I better understand the limitations and alternatives with this exact hardware combination.

    Here is a link from the Crucial forums with a bit more info on M500 encryption capability…

    http://forum.crucial.com/t5/Solid-State-Drives-SSD-Knowledge/An-introduction-to-the-encryption-features-of-the-M500/ta-p/128272

    I’m hopeful that the ATA password MAY be more secure on this exact combination than previously, e.g.., if there is interaction with the TPM and ATA password module to secure and encrypt the ATA password such that it cannot be recovered from the drive directly. Will post what I learn.

    • Look into using your M500 in the OPAL mode, rather than the ATA mode. It will generally be much more secure this way! You will need to purchase software to handle the OPAL PBA (Pre Boot Authentication) for you, however. For a single-user, stand-alone version I’ve seen prices in the neighborhood of $40 – $110. There are also enterprise versions with centralized management, if you have many machines.

      • Hello, any idea about such softwares handling OPAL 2.0 SEDs on GNU/Linux? Because I’ve been trying hard to make use of M500 SSD’s hardware encryption feature on my new Clevo W540EU laptop, but in spite of digging always more into the details of hardware encryption, I haven’t found any way to leverage asuch drives on GNU/Linux.

        I have a custom American Megatrends BIOS that doesn’t handle disk/user ATA password (this was confirmed to me by my PC vendor) and forces “security freeze” on my drives (I have tried the “put to sleep” method with no luck). Hence I cannot go the ATA password way through hdparm, especially since I have the mSATA version of the M500 (integrated in the Clevo next to the main 1 TB HDD), making it unconvenient to hot swap the drive (the other recommended workaround for the hdparm “frozen” security problem).

        Contacting Crucial was of no help : they gave me vague answers, confirming I had to use third party software but without citing any but BitLocker and Wave (Windows softs). They don’t even know of a software that could make use of the PSID number printed on the SSD so as to revert it to factory state, if something ever goes wrong with the hardware encryption (they told me that in that case they prefer users to contact them for a return… So why implementing a PSID?).

        So, no ATA password (American Megatrends BIOS that doesn’t handle user/drive ATA password and no supported way to upgrade it with ATA Security Extension by my PC vendor), no third-party software to handle the OPAL operations on GNU/Linux, no way to unbrick the drive if something happens… Hence I’m resolved to go with software encryption (dm-crypt/LUKS), but I’m afraid this will have nefast consequences on the M500. Although according to what I’ve read, the Marvell controller should handle software-encrypted data without too much a hit on performances, and the Anandtech review says somewhere that the M500′s controller is optimized to behave well with the drive appearing as “full”, what will be the consequence of the LUKS encryption if I understood correctly.

        Anyway, thank you for all the info you gave about this drive, this blog post and its comments are the most exhautive ressource I could find on the web!

        • Most of the FDE vendors who support Opal use a Linux-based PBA (Pre Boot Authentication). Thus I would generally expect that they would work on a Linux system. When I asked them, however, some declined. Those who agreed that it would work pointed out that they didn’t have Linux client software, so you wouldn’t be able to manage the PBA from inside Linux. Thus you would need a Windows system to manage the PBA setup. Awkward!

          Good news: One vendor does support Linux (and Windows and Macs)! Check out WinMagic’s SecureDoc Standalone Windows Edition. I haven’t used it myself, but I very much like the spec’s. Also, the people there were very knowledgeable and helpful when I called. I believe they have a demo available, so you can try it out first. Note: They have qualified the M500, too!

          More good news: They also support the Opal PSID Revert. Many vendors don’t, which baffles me.

          If you decide to give it a try please let us know how it works out for you. :)

          • Thanks for the info. I had stumbled upon WinMagic products before, but couldn’t find what I was looking for. And actually checking the system requirements for the product you mention (WinMagic’s SecureDoc Standalone Windows Edition), it doesn’t seem to support GNU/Linux OSes either… Even their server edition is tailored for Windows ones!
            I tried to contact them through the “Contact Sales” form, but they required me to enter a “non-free” email provider address –refusing my gmail’s one… They really are targeting corporate clients!
            The only product they have that seems to really support GNU/Linux OSes is their Enterprise version, with the SecureDoc OSA (installation trough a LiveCD/USB, hence no OS compatibility problem), but it’s only part of their full-featured product… Could you point me at the product you understood was really compatible with a GNU/Linux client OS? Thanks a lot!

            But you’re right : the fact that that FDE vendors using Linux-based PBA doesn’t support GNU/Linux clients is baffling. Not even speaking of developing a package for every distro out there, but they could go with the LiveCD/USB way! I guess the PSID revert feature is not that much popular because they promote master ATA password to circumvent a device bricking… Anyway.

            On the other hand I try not to rely too much on closed software, especially for security matters. But obviously as we have no OPAL-compliant libre software yet, I should get pass this and fund the development of one myself (anyone interested in a crowdfunding campaign for this?) ;-)

            • I didn’t realize that WinMagic’s Enterprise version supported all 3 (WIndows, Mac, Linux) but that the Standalone version doesn’t. Bummer. But I do see that they have Standalone versions for both Windows and Mac. Perhaps if enough people ask them for a Linux version… :)

              Although it would be extra trouble, you could set up the Enterprise version. They charge per user and it’s about 30% more than the Standalone version. I don’t know if they have a minimum number of users for the Enterprise version, however.

              Or, you could probably use a Windows system to set the PBA up and do any follow maintenance but run the drive normally in a Linux system. Check with them to make sure that this is OK, but I would suspect so. This might not be a bad solution.

              Unfortunately, I don’t know of any other vendor who supports Linux directly at all (Standalone or Enterprise).

              Opal’s PSID Revert command: I think that it is important. I don’t know if the ATA commands will work on the drive after Opal has locked it. Also, then you are dependent on the BIOS and how it handles the password. Yuck!

              I didn’t ask all of the vendors about this, only the ones who made my first cut. Of those, about half did support it and half didn’t. Something to consider when choosing a vendor.

              I guess that this isn’t as much of an issue if you are using the Enterprise version, since the passwords will be backed up, securely, on the Enterprise server. Handling passwords yourself is dangerous (lots of ways they can be compromised – like deleted files not really deleting the data), so I’d be happier not having to do it.

              I agree with your concerns about closed vs open software with regard to security. One of the vendors wouldn’t answer my questions regarding how their PBA secured passwords on the Shadow MBR (where the PBA is located). After all, if you can manage to get the user or the drive password from the PBA then the drive encryption is useless. They told me the method was proprietary and that I would have to sign a NDA first. I declined and disqualified them on this basis. There’s a very common, very secure way of doing it (which every other vendor does!) so their doing it some “custom” way isn’t justified in my mind.

  • All disk in the “usable” category should be removed. The usable category should stay empty forever. Read this carefully:
    http://www.propublica.org/article/the-nsas-secret-campaign-to-crack-undermine-internet-encryption

    We have to be careful even with open-source software:
    http://www.theregister.co.uk/2010/12/15/openbsd_backdoor_claim/

  • Can anyone recommend a haswell desktop motherboard where I can use ATA Password as described here? Or at least one where I could add bios extension myself?

  • I’m concerned that ATA password security, no matter how well it is implemented, is not secure against an experienced attacker?

    I found an article that documents how to break ATA password security. They demonstrate ATA password removal using A-FF Repair Station software.

    On A-FF’s website, they list supported drives they can crack, including Fujitsu, WD, Toshiba, Maxtor, Seagate, and Samsung. It seems this is only for spinning drives, not SSDs. However, I’m sure the process can be adapted to SSDs, if not already by other organizations.

    It seems feasible if one were to analyze enough “fresh” drives and data writing patterns, that you could predict the location of the password store and forcibly overwrite it, thus circumventing the ATA security system.

    Is my concern legitimate? Is ATA security not reliable?

    • Yes, ATA security is sometimes not very good. As long as the drive stores the password (even if hashed) in an area that can be read before the drive is unlocked, an attacker can grab it and try to crack it. If it is hashed, and salted, and it’s a really good password, then you should be OK. Even worse, if the area can be written to then you can overwrite the password (even if hashed) with a new one which you know.

      Unfortunately, SED (non-OPAL) vendors such as Samsung and Intel won’t release this info to the public. So I consider their drives to be suspect.

      Also, you have to consider the BIOS which is handling the ATA password for you. I understand that some limit it to 8 characters, or convert all text characters to the same case. Either of these would make the password very weak.

      On the other hand, SED OPAL drives can have a very high level of security. The “weak link” is the PBA (Pre Boot Authentication) routine. If done correctly the overall security is very good. If not (because passwords used by the PBA are stored in such a way that they can be cracked) then you are in trouble. I’ve contacted a number of the disk encryption vendors who support OPAL drives to ask them about how this aspect of their PBA works. A few gave me the answer I was hoping to hear. A few did not. And a few just don’t seem to know!

      • Great reply! Which ones gave you the answer you were looking for? I’m looking at getting a Samsung EVO which is supposed to be OPAL complatinat with an upcoming firmware update.

        • I’m still gathering info from some of the vendors who sell FDE (Full Disk Encryption), so I can’t give you a complete answer at this time. But here is what I have so far.

          By the way: I don’t know of any vendor who offers support for just Opal drives (except one, but they couldn’t give me an example of even a single Opal SSD drive they worked with).

          Assuming that you want at least Opal 2 (including Secure Erase) compatibility and a single user (not certralized management) version, here is how the various vendors rate.

          These don’t qualify.
          Absolute Software
          Check Point Software Technologies
          CryptoMill Technologies
          McAfee
          Sophos
          Symantec (was GuardianEdge)
          Trustwave
          Wave Systems

          I don’t know. For 6 weeks I’ve been trying to get info from them.
          Dell (was Credant)

          These probably qualify but I haven’t asked about PBA security yet.
          Secude
          WinMagic

          These qualify.
          Softex

          So, as it stands, I’d recommend limiting yourself to one of the last 3. Give me a week or two and hopefully I’ll be able to get some more info and eliminate the middle two groups.

          Also, a few of the vendors told me that there was some wiggle room in the Opal spec and it caused compatibility issues with some drives. Fortunately, most have a demo period so that you can check their software with your drive before committing.

          • Thanks again. I was looking at http://www.anandtech.com/show/6891/hardware-accelerated-bitlocker-encryption-microsoft-windows-8-edrive-investigated-with-crucial-m500 and http://forum.crucial.com/t5/Solid-State-Drives-SSD-Knowledge/An-introduction-to-the-encryption-features-of-the-M500/ta-p/128272

            The first article makes no mention of 3rd party software needed to handle the PBA and the second one mentions you only need such software if you don’t have Windows 8 (assuming you meet all the other requirements of course).

            That being said is it correct to say you don’t need any 3rd party PBA software if you have an OPAL 2.0 compliant drive, Windows 8 Professional with BitLocker, UEFI support (with a Windows 8 Professional UEFI install), and UEFI 2.3.1 (Class II no CSM/Class III) – which I still don’t know how to determine?

            • I have not worked with eDrive myself, but from what I read I believe that you are correct. If your system and drive are eDrive compatible, and you trust BitLocker, then you are all set.

          • Addendum to my previous post.

            I now have additional information from Dell, Secude, and WinMagic. All 3 qualify. So there are 4 to choose from, total.

          • I was also reading that BitLocker officially requires you to use a TPM chip (if you PC has it) or a USB drive each time you boot but some people have found a way to use a password to avoid all that. Makes me wonder how good that last option would be. I know you mentioned you have never used BitLocker but have you heard of reasons not to trust it so far? Thanks again!

            • I’m glad to hear that eDrive/BitLocker doesn’t always require a TPM chip. I was wondering what someone would do if their motherboard failed. Could the drive be used from another machine?

              I’ve heard good things about BitLocker in general. So I have no specific reasons not to trust it. On the other hand, Microsoft has produced some bad (and some good!) security systems in the past. Also, the code is not available for review – which many consider a “must” for high trust.

              When used in an Opal/eDrive environment, however, the drive is doing its own encryption (do you trust the drive vendor?) so the only real issue is PBA (Pre Boot Authentication). I know nothing about how Microsoft has implemented theirs. I’m guessing that it is Windows based. Almost every other FDE (Full Disk Encryption) vendor uses a Linux based PBA. Personally, I prefer Linux’s track record for security.

              Finally, Microsoft has been mentioned in some of the press recently for possibly cooperating, perhaps more than legally required, with the US government regarding security issues. So, if you are trying to hide something from the NSA then you might consider this, too.

              Of course, if you are really shooting for that high a level of security then I’m recommend using two, independent schemes: An Opal drive and TrueCrypt (for example). :)

          • Here’s an example of such a way: http://rics.partners.org/show_article.php?id=274

          • Hi JohnS, thanks for the info. It seems you did your homework! Sorry if any of these questions were there, but the formating of this blog’s comments seems corrupted and hard to read.
            I am I correct, that you put together four vendors who are doing standalone OPAL SW, and they are WinMagic, Softex, Secude and DELL? Did you do any more research how they works internally, did you try them?
            Also, am I reading correctly that you get under the NDA info from intel, how they are handling ATA-passwords? Thats quite a result! Can you just say yay or nay on the security of the mechanism?
            Thanks!

            • Hi Jensen.

              Yes, unfortunately the blog does seem to remove paragraph breaks. Ug!

              Yes, just those 4 PBA vendors all offered stand-alone versions. All offered enterprise versions, if memory serves.

              I did ask each a list of questions, but I’ve mentioned most of the security-related stuff here already

              I have not personally tried any of their software. Most had demos of some sort. In some cases they are available on the website for download. In other cases you have to speak to a salesperson to request it. Also, pretty much the same with manuals. Some are on the website, while others have to be requested.

              I didn’t discuss internals with the PBA vendors past my list of questions. All use at least AES-256. Some are FIPS 197 and/or 140 certified, but not all. Some have been providing this sort of software for years, but for others it is a new product, and some don’t support Opal at all yet.

              Intel SED SSD drives with ATA passwords: Yeah. :)

  • In the conclusion it is stated that “Your BIOS has to support the full 32 character ATA password specification.” Where was this information obtained from? Is it 100% confirmed that a less than 32 character ATA password support WON’T enable encryption on any SED?

    • The BIOS will take what you give it, possibly mangle/adjust/change it, then give it to the drive. So the issue isn’t the ATA spec, but what your BIOS does. Good luck finding that out from your computer vendor!

    • I doubt it. From the SSD’s point of view, it always gets 32 bytes of data as password. It does not have any way of knowing how that data was generated and whether it represents ASCII data (if BIOS supports passphrases) or keyboard scancodes (which is what BIOSes without passphrase support / passphrases disabled usually send as password). Unless it disabled some security features if it deemed the password too short (having too many null characters), but there is absolutely no reason for the SSD’s firmware to do that. Modern SSDs ALWAYS encrypt data to be able to perform fast secure erase, they just – more often than not – do not protect the keys.

      I think it is their way of saying that a short HDD password consisting of keyboard scancodes (so no difference between a/A, 4/$, [{ etc.) defeats the purpose of FDE with AES256…

  • According to this Samsung whitepaper, their encryption is usable by your definition.

    http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/download/Samsung_SSD_White_Paper.pdf

    • I’ve got a pair of Samsung 840′s and I’d like to know if they really are secure or not. I’ve given up trying to find out. I won’t be buying or recommending Samsung SED drives any more.

      I read the white paper you referenced. I don’t see any mention in it that they use the user’s password to encrypt the drive encryption key. I suspect that they do, but nothing I’ve been able to get from them says this. Also, I have not been able to get any info from Samsung about how (hashed?) and where (diag track?) they store the user’s password. Some SED vendors avoid using the diag track for this since there are lots of drive utilities which can read/write it, thus making it easy to get around it. Indeed, there are a few places which offer to do this for under $100. Instead they put the user’s password into an area which only the drive’s firmware can access.

      I did get this info from Intel after waiting 2 months. I can’t discuss it, however, because I had to sign a NDA first. I can say that I have no problem using or recommending their SED drives.

      Also, any Opal 2 drive should handle this correctly since it’s part of the spec. You have to check out how the PMA software handles it, however. From what I’ve seen, most do it right.

  • I have a Samsung 840 PRO. I wanted to use the FDE, unfortunately setting the SATA controller in RAID mode in UEFI disables the possibility to set a hard disk password. It only works in IDE or AHCI mode (and I need the controller in RAID mode for other drives). I am using windows 7 ultimate. Is there any other way to set and use the hard disk password without having to try ATASX (I’d like to avoid messing with this if possible)?

    • Check out WinMagic. They told me that they did support RAID. It would not surprise me if you had to use the same password on both drives, however.

      • JohnS, thanks a lot. Reading all of your comments, it seems like you sure did your homework! Thanks for all the information you provided. This thread is one of the only place with as much information gathered regarding SEDs!

        I just contacted Winmagic to ask if they support the 840 pro in RAID mode. What worries me when using such a method though, is how do you do if you need to re-install windows. I assume Securedoc installs a pre-boot auth screen to unlock the drive. Won’t the drive stay locked then? Do you have options to diable the pre-boot auth in the pre-boot menu itself for example? I forgot to ask them that actually, I only did the thinking afterwards :)

        • Glad to help. I did the research for 2 clients who were interested in securing their data better.

          The PBA is generally installed after you have a running operating system (Windows or whatever). But it is totally stand-alone in operation. It’s not part of the operating system’s boot up, it occurs before it, and it doesn’t ever touch the contents of the operating system partition(s) in any way. Once the PBA is done, and the drive is unlocked, and then the operating system boots up.

          To answer your question: What if you have to reinstall Windows? No big deal. The PBA should continue to function. After you finish reinstalling Windows then you will also have to reinstall the PBA client program which is used to install/manage/monitor the PBA, should you want to. But the whole time the drive remains protected.

          • what I have trouble understanding is how can you unlock the drive to re-install an OS on it when you are installing the OS from a CD for example? Does WinMagic give you the possibility to fully unlock the drive (and thus disabling the ATA password?)

            • When you start up your computer the first thing to run is the BIOS (or UEFI). It, in turn, runs any startup code on various devices. This is when the PBA code on the Opal drive gets executed. The PBA talks to the user (or back to a network server in some enterprise setups) to get authorization for the drive. Once the PBA is satisfied it unlocks the drive. Now, to the rest of the system the drive now looks like an ordinary drive.

              All this happens regardless of what (if anything) is on the drive – just as long as the PBA is set up. The operating system could care less that it’s an Opal drive (excepting: An optional Opal client utility to manage the Opal drive which is just another ordinary program).

              Back to the boot-up sequence – Once the drive is available the BIOS checks it for an “active” partition. If it finds one, it activates it. This is when the operating system starts up. If the BIOS is set to boot off CD instead, then it will. And whatever it boots from the CD will just see a normal drive.

              WinMagic, and other Opal software vendors, allow you to change the locking setup. Normally this is done by using the client utility you install in the operating system. But if your operating system is misbehaving then you do need another way of doing it. Either a rescue CD or by moving the drive to a working system. Or perhaps the PBA would let you do this when it runs – I don’t know.

              ATA security is different than Opal, however. ATA is handled by the BIOS. You can use the F2 BIOS manager to change or remove an ATA password.

              I hope this helps.

          • Now I get it. Thanks!

          • Well after a few more days of research and a couple of emails exchnged with Winmagic, there just is no solution to my problem. RAID is not supported, Windows 7 is not supported, only OPAL is supported… seemed very complicated. They said they were mainly laptop oriented, not desktop. The limitations/requirements seemed to be the same ones as Bitlocker. (Windows 8.1, UEFI Secure Boot, etc)

            So I guess I’ll just use software FDE. From my research, Diskcryptor has great benchmarks, almost similar to non-encrypted benchmarks. I’ll just have to pay the CPU price for it.

            • Hmmm… Something doesn’t sound right. As I understand it they do support Windows 8 but don’t require it. RAID – they told me the did, but considering that almost nobody does I was surprised. Only Opal? No way. They support non-SED drives, doing their own encryption. They also support the Seagate “Drive Trust” models.

              If you do decide to forgo using Opal, consider ATA instead (still SED). Otherwise, TrueCrypt is free and has an excellent reputation.

          • Sorry, I meant Opal only for hardware encryption. Otherwise it defaults to software encryption. They don’t use ATA commands.

            Since ATA Security doesn’t work with RAID and I’ve read at lot that ATA Security was easily breakable, I’m going for software… until hardware becomes easier maybe in a a couple of years :)

  • My german is a bit rusty but I found this:

    http://www.heise.de/ct/projekte/ATA-Security-284169.html

    Seems like a bootable CD/floppy allowing to send ATA commands to the drive? Can anyone better with german than me confirm this?

    • Not quite: The article it references describes the possibility of an attacker or malware attacking a PC by setting the password for the hard disk using ATA commands; the article you’ve found describes how to prevent this – basically by booting from a known-safe medium that disables the ability to set the hard disk password until the next reboot, and/or utilities within Windows / Linux / OS X that do the same at the earliest opportunity. So it’s an interesting article but addressing a slightly different issue to that discussed here. Relevant for any disks being used that aren’t password-protected though.

      • PS – A couple of further thoughts on this – (1) I’m assuming that a hard disk won’t allow a new hard disk password to be given without first having the old one supplied, but I may be wrong about that, and (2) the article is from 2005, so some more recent operating systems may in fact disable the ability to set a hard disk’s password, but I don’t know.

  • Well I have a real world test for the Intel 520 series with ATA password.

    My laptop has Intel 520 SSD drive with ATA password enabled.

    It has been in the possession of the Ohio crime lab, either BCII or Toledo Lab for almost 4 months. They are trying to access the drive data as was admitted to just last week at trial.

    So far it hasn’t been broken,

    Will keep you informed.

    • Wow! Interesting! What type of laptop was used to set the ATA password? Was it one with a BIOS that supports a full 32 character password?

      • You will understand that I am charged with two felonies by grand jury indictment at the moment.

        I won’t give out any details that could help the state to hang me. You may be the state for all I know, wanting to narrow your search-space..

        If they break it, I will post all the details so everyone will know what didn’t work.

        If they don’t break it and I regain possession of it (they can motion to forfeit all evidence in Ohio) I will destroy the thing as I wouldn’t trust what they could have put on it. But in that case I wouldn’t post the details because they may have an image of it if that is possible with an SSD.

        Either way it will be interesting to know as I had many questions about SSD security before I bought one, now those questions are about to be answered unequivocally by the power of the state one way or the other.

  • Suppose I’m using hardware accelerated Bitlocker with Crucial’s eDrive compliant M500. (I’m not yet, but that’s the eventual plan.) At some point, I will want to re-purpose the drive (or donate or sell). How do I go about ensuring that no one else will be able to access the data on it?

    If using ATA password via BIOS instead of OPAL via Bitlocker, I would just perform a secure erase using something like Parted Magic. But, according to some threads I’ve been reading (e.g. New M500, Can’t Secure erase. No security set feature like other SSDs. What gives? and 2nd M500 – Win 8.1 kills ATA cmds including Secure Erase), that process doesn’t look to be possible with the M500 after having used Bitlocker (or perhaps even just having used Win 8.1).

    Am I overcomplicating things? If I just delete all partitions (including WinRE, System, and MSR), will that also remove the PBA and effectively prevent anyone from accessing the encrypted contents? And the recipient of the drive can then treat it as if it were a new, blank drive?

    Thanks!

    • More questions occur to me:

      Where is the PBA stored? In the System partition? If so, is there any way to recover the data protected by the PBA (e.g. the Windows partition) if something happens to the System partition (e.g. corrupted or deleted)?

      If I have two Bitlocker-protected M500 drives in the same system, are they both protected by the same PBA? What happens if I transplant one of the drives to another system — how would I access the transplanted drive’s data in the other system?

      Sorry if this is deviating too far from the original topic, but this is the only place I’ve been able to find the depth of information I’m interested in (without going to far over my head).

    • Interesting…perhaps this is issue is limited to the M500 only?

  • It would appear the the Surface Pro which uses a Micron C400 SSD might be the SED variety with OPAL support for Windows 8 Bitlocker + eDrive based on this..perhaps someone can confirm?

    http://answers.microsoft.com/en-us/surface/forum/surfpro-surfhardware/ssd-in-surface-pro-using-hardware-based-encryption/7cc9fcb0-bfb9-4fed-b925-ae75291e3de9

    • Well I have the Surface Pro a try and it does not appear to use eDrive since it asked if I wanted to encrypt the used space or the entire drive then it ran through the encryption process which took a few minutes (based on the AnandTech article for the M500 this should not happen although I didn’t notice any performance loss even after checking with ATTO disk benchmark).

      Also tried a 2.5″ Samsung PM830 which is OPAL compliant and even says so on the sticker of the drive with the same results as with the Surface Pro. I thought the Samsung would be eDrive/OPAL compliant like the M500 but it doesn’t appear to be. Am I doing something wrong or perhaps the PM830 is OPAL 1.0 and the M500 and eDrive needs OPAL 2.0?

      On another note, the Samsung EVO firmware update to make it OPAL compliant is out now but I haven’t had a chance to try it out. Will report back when I do!

      • EDIT: Based on this http://www.wave.com/self-encrypting-drive-compatibility-list and reading the AnandTech article again it would appear you need an OPAL 2.0 compliant drive for Bitlocker + eDrive and the PM830 is not but the M500 and EVO are.

      • Reporting back on my experience with the Samsung EVO after updating the firmware to the TCG/OPAL complaint version and I was not able to use eDrive even though I believe I am meeting all the other requirements (UEFI, Windows 8, etc.). It was tested on a Lenovo K410 desktop without a TPM chip and on a Lenovo ThinkPad T430 with a TPM chip…if I can’t get it to use eDrive on a business class T430 then I don’t know what else to really try. Perhaps I’m still doing something wrong when I try to encrypt using BitLocker…I would appreciate any feedback from others who have had success with BitLocker eDrive on something other than the Crucial M500.

        • Finally got eDrive to work on the Samsung EVO but I had to install the Samsung Magician software and enable “Encrypted Drive” which instructed me to perform a secure erase and a clean install of Windows 8 which I did and it but I had to make sure the EVO was #1 on the boot order in UEFI/BIOS and also had to run “bcdboot %systemdrive%\Windows” from the Windows command prompt since I kept getting BitLocker errors saying “element not found”. After it’s done however the same problem as the Crucial M500 exists where the ATA security set is disabled and one CANNOT perform a Secure Erase on the drive and the Samsung Magician software doesn’t allow you to set “Encrypted Drive” back to “Ready to be Enabled” or “Disabled”.

          • So I spoke with Samsung about the Secure Erase and ATA commands not being available after using eDrive with Windows 8 and they told me that is part of the security features to disable ATA commands and if I want to perform a secure erase from this point forward I should run DISKPART ===> CLEAN. Ha! I don’t see how that is the same thing as a true secure erase which resets the NAND chips but Samsung claims that using DISKPART’s CLEAN command is how they reset all their drives.

            • I know next to nothing about eDrive, but it also doesn’t make sense to me that it would not allow a means of executing the Opal Secure Erase. This is a major feature of SED drives in general – the ability to securely erase an entire drive in just a few seconds. Admins love this and you see this feature hyped in many SED/Opal advertisements. Indeed, any PBA software (including eDrive) which doesn’t allow this I would consider brain-dead!

              The description of DiskPart’s Clean command (http://technet.microsoft.com/en-us/library/cc766465(v=ws.10).aspx) says nothing about it executing an Opal Secure Erase. I doubt that it removes the data in a secure fashion. Note: Using the “all” switch won’t help. The SSD generally isn’t going to overwrite the actual data location with the new data because of wear leveling algorithms. This is why non-SED SSD drives are hard to erase.

              • I completely agree. However, if you have a non-SED SSD doesn’t a secure erase command on that do the same thing as a SED SSD? (i.e. sending a higher voltage to the NAND chips and resetting them to a clear/fresh state)? One other thing I noticed in the Samsung Magician software is under “Security” it gave me three options for the EVO…the first dealt with setting an ATA hard disk password through your BIOS, then TCG/OPAL and “Encrypted Drive”. This “Encrypted Drive” option is what had to be enabled to use BitLocker’s eDrive but when TCG/OPAL was selected it said something like “Must be managed by third party software” which would almost seem like BitLocker eDrive has nothing at all to do with OPAL compliance since it had it’s own option (#3). While I’m guessing OPAL 2.0 compliance is needed for BitLocker eDrive it makes wonder if BitLocker eDrive is somehow in it’s own lower class compared to other OPAL security solutions or if a manufacturer could make a BitLocker eDrive compliant drive that was NOT OPAL compliant. Do you know of a program that can perform an OPAL secure erase? Perhaps it’s something I could try on the EVO.

                • > However, if you have a non-SED SSD doesn’t a secure erase command on that do the same thing as a SED SSD?

                  I don’t think so. On an SED drive changing the drive encryption password and showing all the sectors as unused is all that’s needed to do a secure erase (make data non-recoverable).

                  > (i.e. sending a higher voltage to the NAND chips and resetting them to a clear/fresh state)?

                  You would have to do this for every block, thus taking some time. When done, the drive wouldn’t be able to read the data but possibly specialized hardware could, unless you were willing to do multiple passes with varying patterns. This is similar to what it takes to securely erase a magnetic (rotating) hard drive.

                  > One other thing I noticed in the Samsung Magician software is under “Security” it gave me three options for the EVO …

                  Strange! I would think that the ATA software (BIOS and perhaps TCG manager) should be able to do any ATA function needed, and that the OPAL PBA and client software should be able to switch to Opal mode and handle any functions needed.

                  > This “Encrypted Drive” option is what had to be enabled to use BitLocker’s eDrive …

                  To me this implies that either the Samsung drive is not totally Opal standard, Microsoft BitLocker is not totally Opal standard, or both. It sounds like reason #12 to not use BitLocker. :)

                  > Do you know of a program that can perform an OPAL secure erase?

                  Any of the PBA vendors, but you would probably have to use their software to set up the drive and load the client program on your operating system first.

                  Side note: Beware when installing/updating the Samsung Magician software. It sets itself up as an autostart service (look in the Start program group). I don’t see any reason to have it loaded all the time.

                  Also, I can’t say for sure, but twice short after upgrading Magician I found that my laptop’s power profile had been switched from my customized version back to the Microsoft default. Next time I upgrade I’ll know for sure. :)

  • Hi to all,

    At first, i would like to thank the author for bringing this subject up. I would also like to thank the people in the discussion because it is suprisingly good. I am also into HDD/SSD security and I have lost huge amount of time by studying this subject, it is frustrating that the info on this is so unclear. In my opinion only transparent is really secure, and it is clearly not this case.

    I wanted to buy Samsung’s 840 pro SSD with the ATA-enabled encryption. Because there are unclear rumors how the ATA password can be bypassed (but to be honest, I did not found a single one case where it has been demonstrated how [check Tuco here, even the goverment wasn't able to do so far]) I tried to study the OPAL SSDs. It sounds great on paper, but there is IMO also the flaw in it the same way like in the ATA-passwords, and that is, the SW handlinlg OPAL seems to be not transparent. I checked vendors who do the opal SW, and usually they are providing some sort of recovery password (marketing speaking as a benefit), but if some mechanism like this exists, than other master password can exists I think. Also it seems that none of this SW can be downloaded easily without given your credentials to these companies, so not even you cannot try it easily but also it brings more questions about pairing their products with a specific customers.

    So, now some questions.
    - does anybody here tried OPAL SW for standalone user in a real world, does any reviews of this SW exists?
    - does any open source OPAL SW exists, that would solve all the questions
    - is ATA-password really that bad? Yes on non-encrypted drives before it was bypassed, but now on modern SSD’s?
    - does OPAL SW have master password backdoors? How the HASH in there is generated? What is the real mechanism of encrypting the SSD’s key? This from what I red is vendor-dependend, and since they are not providing this info its a blackbox anyway.

    So in the end, so far the core problem is to be this: If I want to do maximum for my SSD security, should I trust ATA-password or OPAL more?

    P.S.: one of the OPAL vendors (secude) isbased in Switzerland and they say that are not under NSA like others. How about that.

    • The ATA password on most non-SED drives can be cracked. There are a half-dozen or so companies who offer to do it for you or offer products which will. SED (except for Opal) drives are another story. Only one of these companies claimed they could, and the person I spoke with said some things which I knew to be incorrect. He finally admitted that they hadn’t done one but thought the could.

      The SED (non-Opal) drive vendors generally do not generally release information about how they do it, so you have to assume the worst. This includes Samsung, who refused to even let me speak to someone past the Tech Support department.

      Exception: On certain models, both Seagate and Intel have proprietary schemes which they both claim are secure. I didn’t look into Seagate (since they didn’t have any SED SSD’s) but I did check with Intel. After about 3 months and having signed a NDA they answered my questions. I can’t discuss the specifics but suffice it to say that I was satisfied by their response.

      Opal drives provide a secure means for the PBA (Pre-Boot Authentication) software vendor to safely secure the drive as long as the PBA software itself is implemented correctly. Most who I spoke with used some version of Linux. One wrote their own custom software and another used Windows. Considering the lack of any significant track record and Windows dismal security history, I personally would not consider either of these. Almost all of the PBA vendors secure the passwords in about the same way. First, please realize that there are 3 sets of passwords.

      First: The drive’s encryption password(s) are stored by the drive’s Opal firmware on the drive and they NEVER enter/leave the drive. Never. They are encrypted by the drive access password(s) when stored. The drive access passwords don’t need to be stored. They are only used when unlocking the drive for access and the Opal firmware can easily determine if a supplied password is any good or not. Neither the user nor the PBA software ever reads or writes the drive’s encryption passwords. NEVER.

      Thus if the Opal drive falls into the wrong hands, and the bad guys manage to read the raw data from the drive, including the drive’s firmware storage area, it won’t do them any good. They would still need a drive access password to be able for the drive to be able to unencrypt the drive data password, and then use it to unencrypt the data. If the bad guys try a brute-force attack (supplying all possible drive access passwords) they will be blocked by the Opal firmware’s bad password rate-limiting. So as long as the PBA software does a good job protecting the drive access passwords, your data is safe.

      Second: The Opal drive’s access password(s) is what the PBA (not the user!) uses to unlock the drive for user access. The actual user NEVER reads or writes this password. The PBA stores this password and supplies it to the drive after it is satisfied that the user is authenticated (however).

      The PBA protects the storage of the drive access password(s) in two (or possibly more) ways. First, they are stored (as is the entire PBA itself) in a special area of the drive, the Shadow MBR (Master Boot Record). The MBR is where the boot process for a drive starts. So any code there runs before anything on the drive can be accessed. An Opal drive ensures that this is so by “locking” all other areas of the drive until a satisfactory unlock command (with drive access password) is supplied. At this time the Shadow MBR is disabled in favor of the regular MBR so that the drive can boot normally.

      With one exception (CryptoMill Technologies), all of the PBA vendors I asked about this assured me that they did not store the drive’s access passwords in plain text (or hashed). They are stored only after being encrypted by the PBA’s user access password (the password which the user uses). So even if the bad guys have the stored copy, it won’t do them any good unless they also have the PBA user access password.

      Third: Again, with the same single exception, all of the PBA vendors assured me that they either did not store the PBA user access password at all or that it was stored only as a salted hash of the password. This is potentially the weak link. If a user chooses a simple password then the bad guys could brute-force it. So it’s important that the user choose a password with at least 100 bits of entropy (128 to be safer). Generally, most ASCII characters in a password have about 4 – 6 bits of entropy. Thus a 20 to 30 character password is needed. A long password is better than a “complex” (lots of types of characters) short one.

      There you have it. The scheme seems good to me. The weak points are the user’s PBA access password choice, a bug in the Opal drive’s firmware, and a bug in the PBA software. It makes sense to choose vendors wisely. However, if you are securing top secret stuff, or you are just paranoid, I’d generally recommend using 2, totally separate schemes, including separate passwords. An Opal drive and TrueCrpyt (full disk) software would make a nice pair.

      Summary: I wouldn’t trust an ATA password on a non-SED drive (of any type) at all. On an SED (but not Opal) drive, I personally would trust Intel but not Samsung SSD’s. Opal drives I would trust in general. Make sure you get Opal-2, not Opal-1, by the way. The price premium for Opal is pretty small, so I’d recommend it even if you don’t feel you need it right away but might in the future.

      Master and Backdoor Passwords: There are generally 2 classes of passwords: Master (for the IT department) and user. The Opal drive firmware supports both as does all of the PBA software. Generally a master password is only set up by the PBA in the case of an enterprise which has a PBA server. The storage on this server is encrypted, of course, so that only the appropriate IT people can get to these passwords. Nothing to fear here.

      There are no backdoor passwords that I’m aware of. However, most PBA vendors do offer some sort of a “recovery” scheme. How can they recover the user’s password? If there is an enterprise server, then it has it stored. The user calls IT and hooks his machine to the LAN and they can activate it for him.

      Also, most PBA vendors offer a recovery option even for the stand-alone user (no PBA server, or he’s on the road with no office LAN connection). Most of the time this depends on the user having previously set up a few (at least 3) question & answer tests. Most (but not all) PBA vendors allowed this to be disabled if you didn’t want it. If not, you could always type in 30+ character junk answers.

      Most (but not all) PBA vendors also allowed the user to write his own questions, in addition to the answers. This is important because such questions as “Mother’s maiden name, City you were born in, Name of your high school” can often be Google’ed. So allowing the user to set up his own questions helps. Regardless, the answers need to total 20-30 characters else the bad guys could brute-force them.

      Other recovery means used by some included a backup of the password on a flash drive (don’t carry it with you!), or alternate multi-factor authentication.

      Finally, don’t think that the NSA’s influence doesn’t extend to other countries. Other governments often cooperate with them. Foreign companies typically have financial stakes in the US. All it takes is one employee to implement something for them. So if you have something which you don’t want the NSA to be able to read, act paranoid. Use two orthogonal schemes. This also helps limit the damage should a flaw be discovered later in one of the schemes.

      John

      • Thank you John for your extensive reply. I understand.
        I have contacted three OPAL vendors and none of them replied. I contacted them directly, since I refuse to give them all my credentials for just asking if they support my setup. What a shame.

    • Dear Jenson, John and the rest,

      Thank you for the super coherent and informative discussion that you are maintaining here, I’m super happy with this!

      1. Today I finally had time to read more about Opal. As a security-conscious Linux user, the fact that Opal management software all seems to be Windows based (with one or two hard-to-come-by-closed-source exceptions) is quite upsetting.
      2. I spent an hour or so diagnosing the strange comment formatting on this theme. I found the problem and managed to fix it: http://wordpress.org/support/topic/enabling-newlines-linebreaks-carriage-returns-in-comments?replies=1 — comment formatting now much improved (it doesn’t eat your carriage returns anymore). However, it only nests to a few levels. I’ll send some more minutes to see if that can be fixed.

      Keep up the good work everyone!
      Charl

      • I’ve increased the maximum nesting level to 9 (it was set to 5). The theme looks like it should be able to handle it.

  • Found some more info on BitLocker’s eDrive where they mention that the drive must meet some requirements from TCG & IEEE standards but no mention of OPAL and that the drive must be an “Encrypted Hard Drive” which they say is not the same as a SED. This would seem in line with the Samsung Magician software which shows three security options for the EVO (Class 0/ATA HD Password, TCG/OPAL, and Encrypted Hard Drive). This leads me to further believe that drives that work with BitLocker eDrive are in a seperate class of their own and not the same as OPAL 2.0 drives or typical SEDs.

    http://technet.microsoft.com/en-us/library/hh831627.aspx

    • I believe the Microsoft reference to the TCG Trusted Storage Device is just another way of saying Opal. I think that they need at least Opal 2, not Opal 1. Why they just don’t say Opal, I don’t know.

      Microsoft eDrive does require a few other things, however: TPM (which I understand you can work around if you try hard enough), UEFI 1.2, and IEEE 1667. Perhaps the Samsung eDrive setting turns on IEEE 1667 support.

      From what I read, just about all of the Opal 2 drives also have IEEE 1667 support, so this shouldn’t be an issue in general.

      Good luck! Let us know how it works out.

      • I’m still having problems finding an easy OPAL Secure Erase option. I was able to find this under “Crypto-Erase”/SecureDoc but cannot seem to access the linked download http://www.utexas.edu/its/help/encrypt/1838

        One other thing I’ve determined is that BitLocker eDrive can only be enabled after a clean install of Windows 8 Professional & the ATA security features are disabled immediately before BitLocker even runs the system check where it requires a reboot before encrypting! It seems that if you meet all the requirements for eDrive and attempt to use it it destroys the ATA feature set even before the encryption or full reboot system test is even completed.

        I am trying to determine how to enable it without doing a clean install and restoring an existing Windows 8 Professional image backup from programs such as Acronis, Norton Ghost, etc on a machine that has been verfied successfully with eDrive (even without a TPM chip btw!). I’ve tried a few things including doing a clean install then only restoring the data partition and leaving the freshly installed EFI and System partiions but each time I get the BitLocker options to “Encrypt either used space or entire drive” and eDrive cannot be enabled. Doing a Windows “refresh my system” does allow eDrive to be enabled on an restored image backup but it of course removes most if not all of your third party software. It seems that reinstalling Windows either fully or partially initializes the drive to be “eDrive ready” and I’m wondering if there is a command that one can issue or do something to make it work on an existing installation or backup image without doing a refresh or clean install. Any suggesions would be greatly appreciated :)

        • Looks like in order to make it work with an existing installation one has to use the Microsoft Standard SATA AHCI Controller and not the Intel one…I had to remove the Intel one and go into safe mode in order to get it working right and eDrive can be enabled. Apparently after BitLocker eDrive is enabled one CANNOT update the standard SATA controller driver to the Intel one or Windows won’t even boot. Got this idea from a forum on Crucial’s site where a user had the same issue with the Crucial M500. Reminds me of some problems people had with the OCZ 3 series SSDs where they had to use the standard controller to prevent BSODs in Windows. Now to figure how out to perform an OPAL Secure Erase on this EVO drive.

          • So, just to confirm, you *WERE* able to use Intel drivers on a fresh install, correct? If so, any idea whether the Intel drivers can be updated henceforth?

            Also, if I have no interest in using the various Intel features (Rapid Response, Rapid Start, Smart Connect), is there any disadvantage to using the Microsoft drivers?

  • I’m aware this article is a bit old, but maybe you would like to ask Kingston if they correctly implemented encryption in they products (specifically i’m interested in mS200 series) and update it.

  • Here is my dialogue with Samsung UK. Only took them 12 hours to respond and the response seems very clear to me. Hope this helps.


    I have the 840 pro SSD. I am aware the the encryption option can be set via an ATA password in BIOS even WITHOUT TPM.

    However, I have a TPM motherboard with a TPM chip, my question is: will the SSD utilise the TPM chip to increase the encryption security?

    If the answer is ””yes””, my further question is: if I somehow damage/lose the TPM chip/motherboard, will the SSD be completely useless or will I be able to use it (I acknowledge that the data would be lost but that is a different matter).

    thank you for your email.

    The SSD can use the TPM to increase the security, but if something goes wrong on the TPM the SSD will be useless because you won’t be able to run anything onto the SSD, not even the secure erase or the format. Anyway, if the SSD is still in warranty, you will be able to send the SSD to the Samsung repair center asking for a RMA number and it will be repaired.

    • I would really be curious HOW the TPM can enhance 840′s security on a pre-boot level. Don’t they talk about SW encryption?

    • I only scanned the preboot article quickly, but I would suspect that it doesn’t apply to most Opal drives because Linux is used for the PBA by most Opal utilities. It is no longer accessible once the PBA completes, and the boot to the OS takes place. Also, the attacker would need access to a booted system. If he has this access, then he already has access to the unencrypted drive data.

      • I read this article, most comments and many other related articles on SED.

        I still have questions:
        1) When using a SED drive such as the Samsung 840 Evo/Pro with Truecrypt as full system drive encryption, is this encryption hardware assisted (so faster than what it would be using the same setup but with a NON SED disk)?

        2) If so, are you still as secure as you would be on normal hard disk (non SSD)? Truecrypt mentions that when using SSD with TRIM (most modern SSD’s) things are not so safe..

        3) The only way to take FULL advnatage of the hardware accellartion of SED’s and to be as secure as possible is to have the damned ATA password in the BIOS? In that case you don’t need Truecrypt or any other software right?

        4) What happens if you use the ATA password with a SED-SSD and motherboard breaks down? I suppose you lose all the data but can you take the SSD on a different pc and format it?

        Thanks

        • 1) I’m not 100% sure, but I believe that Truecrypt does not use encryption done by the drive itself.

          2) When doing software encryption on a SSD then TRIM (and a few other things) are issues. I’d opt to use the drive’s encryption since it avoids these issues.

          3) Some self-encrypting SSD drives handle ATA passwords well. Intel does, for example. I tried to find out about Samsung but was unable to get the necessary info.

          4) If the motherboard breaks, then you are in trouble. An ATA password gets “massaged” by the BIOS, so you have to find another machine with the same BIOS. Tacky! I’d depend on my backups instead.

          Consider an Opal drive (with support software) instead of using an ATA password. You can probably move the Opal drive to another machine if you need to (but check with the Opal software vendor!).

          • Thanks John, you re-confirm what I already thought.
            So conclusions:
            1) All modern SSD’s shouldn’t be used with TrueCrypt.
            2) The whole SED thing is sort of useless for use on most desktop systems as they don’t support ATA passwords (and on most laptops too).
            3) Even if you have an ATA password and an SED, you are tied on the speciifc motherboard you have. Again, this makes SED use practically useless, as motherboards can fail, or you might wanna simply move the drive to a new PC or laptop, which means you have to always keep backups (which will not be SED secured, so u will have to secure them using software again..).
            4) OPAL drives are equally useless, my Samsung 840 Evo is OPAL, but again needs an ATA password, OR a clear format and then installation of Windows 8 only with Bitlocker (so again, not hardware only secure).

            What is the point of all of this then???
            Luckily I didn’t buy my SSD cause it was SED/OPAL but just because it was a good fast and reliable SSD..

            • Hi Pro.

              I think that your conclusions are somewhat pessimistic. SSD’s are a recent technology so you expect some “bleeding edge” effects. If you are tryping to protect your drive data with encryption (a good idea!) then using a SSD (vs a hard drive) does add some complications. SED’s eliminate the SSD complications and help with the encryption itself. I consider this a “plus”.

              Yes, it would be nice if TrueCrypt took advantage of the SED drive encryption. Some encryption software does currently (BitLocker does, in some cases) and I expect that the percentage will increase with time. But it is a chicken-or-egg thing, and you have to start somewhere. :)

              It seems that ATA password implementation on drives is generally better on SSD drives than hard drives. And Opal drives are better yet.

              It is unfortunate that more desktops don’t support ATA. I guess that theft is more of a concern to laptop owners. But with all the recent attention to encryption in general, perhaps the desktop vendors will add it. it wouldn’t hurt to contact your vendor and make such a request.

              I wouldn’t worry too much about not being able to move an encrypted drive to a new machine. This should be an uncommon event. When it does happen, restore from a backup. You need to make backups anyway (in case the drive is stolen) so it’s no big deal, just an inconvenience.

              I don’t see why your Opal drive would require an ATA password. In general, an Opal drive doesn’t.

              Summary: Bleeding edge right now, but forecast looks better.

  • Hi,

    I’m able to activate (and deactivate) the ATA password on my Samsung SSD using hdparm, but my BIOS doesn’t ask for the password, it acts all crazy instead (Asus motherboard). I’m now wondering if there’s a way to automate the boot-up procedure:
    - boot into some Linux (command line only) on a USB flash drive
    - unlock the drive (a script that asks for the password and runs hdparm)
    - reboot into main OS (Windows in my case)

    Ideally, the only interaction during the whole process would be to enter the password and hit enter. As I am by no means a Linux expert, I’m hoping that someone could give some tips as to how rebooting is handled and what Linux flavor is preferred.

    Thanks for this blog post, I’ve learned quite a lot!

  • I bought a Samsung 840 Evo SSD and have a Dell XPS 15 laptop.

    Is it possible to set the SSD ATA password with a third party software like hdat2 or hdparm?

    I’m worried about the way Dell BIOS sets the password, as described here: http://thaeial.blogspot.com.br/2013/01/locking-and-unlocking-hdd-with-dell.html.

  • There doesn’t seem to be much on the net about SEDs at the consumer level. Looking into it, it doesn’t look like it will be that hard to code a piece of basic management software. One thing I see in here is your concern about what is actually stored on the drive for a password. Can I ask why? If someone has the ability to read the protected part of the drive they will also have the ability to return whatever is stored in the PIN field of the SID without trying to figure out how it was derived. What would you like to see stored in the authorization table? An arbitrary piece of a hash of the password, the MD5 sum of the hash of the password … ??? I’d be interested in hearing your input on this, I’m not heavy into the security, I nod off well before they start talking about elliptic curve domains.

    I’m also wondering how long it will be before a piece of malicious code starts floating around that takes ownership of OPAL drives that are still in the manufactured state and locks the user out? A “we haz crypted ur data, wanna buy a key” type of ransom-ware would be easy to wrap inside a virus/trojan.

    • Not sure if anyone is still following this thread but I just wanted to let you know that I released the first part of a GPL Opal implementation. This release only contains the host management software. The reason for releasing this without a PBA is to enable people to PSID Revert their drives if they need to.

      Source code is available on GitHub at https://github.com/r0m30/msed
      Linux and Windows executables are available at http://r0m30.com/msed/files

  • “With the introduction of the SSD 840 and 840 Pro Series SSDs, Samsung has added AES hardware-based SED technology to its consumer SSD lineup. Simply enabling the ATA password via the BIOS will automatically render all data on the drive unintelligible without the proper password. Because it is implemented at the hardware level, there is no performance penalty like there is with a software-based FDE implementation. This feature is a valuable privacy tool for anyone who uses a portable computing device (e.g., laptop), especially frequent travelers.”

    See http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/about/whitepaper06.html

    • Unfortunately Samsung refuses to say how and where they store the password on the drive. Traditional (non SED) drives with ATA passwords are often easy to crack. So without this information, the security of the Samsung drives is questionable.

  • What about Crucial’s M500 SSDs? After hours of searching on the Internet, I came across this answer from Community Moderator, Crucial_YogiH in their forums. Does it mean that the M500 meets the requirements to be added to this list?
    “Yes, the M500 does support the ATA command set, formally known as the ATA Security Feature Command Set. If you choose to use this, the drive gets locked by a BIOS password.”
    http://forum.crucial.com/t5/Solid-State-Drives-SSD/Crucial-M500-ATA-Password-and-Disk-Encryption/td-p/146088

    On a side note. If I have enabled the ATA password on the M500 (or any drive), then my laptop dies, can I put the drive in an external eSATA enclosure and supply the password to access the data? Can’t find this information anywhere on the Internet. (I understand USB enclosures probably don’t work as they don’t support the required ATA commands.)

    • @Ming,
      Re: your side note. As is often the case, “it depends”. If you know how the bios manipulates the password you enter before sending it to the drive then yes you could use something like hdparm to unlock the drive and recover the data. Unfortunately most (all?) bios vendors do not document this so in the vast majority of cases the answer will be no.
      The bios could use the ascii characters you enter as the password, or it could use the keyboard scan codes as the password, it could also pad the password (often with hex 00). The bios could also perform some type a hashing on the entered password before sending it to the drive. Without documentation it is unlikely you will stumble across the correct password.

      Your best bet for recovery is backup the data often then back it up again.

Join the Discussion

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>