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

  • I’ve written another post documenting my successful experience with r0m30’s open source TCG Opal configuration utility and PBA image.
  • 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

  • 2015-02-11: Added link to my msed, PBA and Opal post.
  • 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.

209 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).

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

        That’s incorrect. That’s only the way it has to be for people who want to use encryption, and accept the chance of data loss because of it – and keep a backup of course.

        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 actually don’t have any issue like this and I suspect it’s the same for a large majority. Someone would have to steal one of my desktop computers or my wife’s laptop from our house most likely, and they’d have to care about our data enough to do something with it. And if it was encrypted, they’d need to be able to find the backdoor way around it. It’s possible, but it’s probably more likely that I’d have a device failure than it would be to have a theft by a thief that would find our most sensitive private data (not sure what) and distribute that. I value my privacy, but I’m not really storing state secrets. It would be different, particularly on the laptop, if I did have some very sensitive data or data that’s valuable to people other than myself.

        I agree about being open about the encryption. Consumers should know if they are losing the possibility for data recovery by the choice of which SSD they purchased, or was included in their computer or device. Guess what though? No SSD company wants to advertise that downside. They advertise the encryption. The consumer likely doesn’t know all of the consequences. I recently had a chance to speak with members of a university physics club and the professor about flash data storage and this topic came up. They all seemed surprised that the failure of a single controller chip (and not a data chip) on an SSD could cause complete data loss without any chance at data recovery, whether the user wanted to use encryption or not.

        I don’t know if I agree that the security requirement needs to be taken more seriously than users that don’t backup. Now of course if you want a secure device, or you are producing a secure device, you need to do it right. But, as any company, these companies need to make money. That is the company’s requirement. It depends on who they are targeting, but I have to guess that the consumer market for data storage is the biggest market for a lot of the SSD companies, and of course also the OEM computer makers. Now if you are making most of your money with those people, and then you tailor your device so it can meet the needs of a smaller group and still work ok for the rest of the market, except for an important difference that is a detriment to the larger market, then I see that as a problem. It’s almost an insidious problem to them as well. This problem is not openly disclosed to the consumer. It is only discovered when they lose their data. These are the people most likely to not have a backup. I’m not blaming the SSD, I’m blaming the lack of communication of the risks and the lack of choice.

        Now, offer both options, and be open about the encryption, and I am happy with that.

  • 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?

            • Yes, IIRC that worked just fine using the Intel drivers that are installed by default. I never tried updating the drivers but I suppose it can always cause issues. I can’t think of any major disadvantage to using the Microsoft drivers…but perhaps performance might suffer to a point where one could measure it, but likely never notice it?

  • 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.

  • does anyone know if it’s possible to use hdparm to activate the ATA security that the user is required to enter a password at bios, to use hd parm to set the passwords user and master? is it possible to do this with hdparm commands on the majority of laptops/desktops or do you really have to know exactly how the bios manipulates the user password you set with hdparm?

    secondly does anyone know why adding this layer of security is such a pain in the ass? there has to be a reason or all vendors would happily advertise it and charge as much as possible for it.

  • You may want to amend this article a bit to include a list of motherboards with UEFI BIOS that support ATA passwords. It seems that despite the ubiquity of SSDs that support the fast, simple and reliable hardware encryption (Samsung 840/850 EVO and Intel 300,500, 700 series), ASRock and others do not have the ability to set an ATA password in their BIOS. Further, this particular feature in a motherboard is never advertised nor is it brought up as a feature in review articles that compare motherboards. And before I get these comments on how “ATA Passwords are not secure”, please read this first:

    https://www1.informatik.uni-erlangen.de/filepool/projects/sed/seds-at-risks.pdf

    If you just turn off your machine, a hardware encrypted SSD is near, if not completely, uncrackable.

    And to see just how lame the reasoning is for not providing the ATA Password feature in BIOS is:

    http://www.pugetsystems.com/labs/articles/Introduction-to-Self-Encrypting-Drives-SED-557/

    In other words, this feature is not implemented because it works well. What the . . ?

    ASRock, would you PLEASE implement this functionality in your UEFI BIOS!!

    • “And to see just how lame the reasoning is for not providing the ATA Password feature in BIOS is:
      http://www.pugetsystems.com/labs/articles/Introduction-to-Self-Encrypting-Drives-SED-557/

      “So rather than risk having an angry customer that accidentally locked their drives, they leave that specific feature of SEDs disabled.”

      It sounds like they see the costs as not being worth it. They don’t see saving money and customer satisfaction as lame. They could offer two options. That way people that want the encryption and associated risks can have it done right, and the rest don’t have the risks slid in behind them.

      • I can see both sides, but it sways toward having the BIOS ATA Password option. There will be the occasional customer who screws up the password situation. On the other hand, there are millions of customers using Samsung and Intel SSDs who would like this feature. The cost to amend the BIOS is minimal, the potential business opportunity is huge.

        So ASRock’s tech team responded to my request and gave me their BIOS with the ATA Password option. But they didn’t post it on their BIOS update website. Hence they have the option for it, as you suggested HikingMike. It would be great if this option were both advertised so people know it’s available (perhaps with a small hurdle so they understand the risks) and if more motherboard manufacturers even offered it. Kudos to ASRock for having it available, at least.

      • making a non encrypted backup defeats the whole purpose of encryption..

        Could you make a clone that IS encrypted? With TrueCrypt I’m sure you can..

        • making a non encrypted backup defeats the whole purpose of encryption..
          Could you make a clone that IS encrypted? With TrueCrypt I’m sure you can..

          Not necessarily. I’m guessing you’re replying to Al Winston’s idea below. His idea is pretty simple. If you access your non-encrypted backup device very rarely and normally keep it in a different location (a locked safe even), then that can be a valid strategy for a user. They may carry their laptop around everywhere, leave it in a public place by accident, or have it stolen, but the other backup device doesn’t have the same exposure so that makes sense to me. It definitely does not defeat the whole purpose.

          You can make a clone that is encrypted by just using another encrypted drive in the same computer (that may only be usable if it’s in the same computer), or by using TrueCrypt like you say so you can actually access it with any computer that has TrueCrypt. Mentioning TrueCrypt, you have to bring up the situation that software is in that causes some people to no longer trust its encryption solution. However it is currently undergoing an independent security audit, Phase I is complete (looks pretty good). Whether or not you trust the auditors is another thing :)

          • Well, there’s still debate on whether Truecrypt increases wear on SSDs, although I do not claim to know about this. It fills the entire SSD, so things like overprovisioning no longer increase the life of the drive, supposedly. Also, since Truecrypt is no longer supported or being developed, there’s that concern as well. It just seems easier and simpler to go the hardware encryption route.

            • No reason the backup drive needs to be an SSD if wear is a concern. I’d guess it’s not a concern for most though.

              Only the SSD itself can access the overprovisioned space.

        • Better yet, back up to a SED drive. Then you don’t have to worry about exposing the data if the backup drive is stolen.

  • OK, I’ve got some news here. Because I want to make sure this is found by people wanting an ATA Password, I’m going to throw in buzzwords like ASRock Extreme6 Z97 motherboard, Samsung 840 EVO SSD with AES encryption (or Class 0 as they call it in Driver Magician), the Intel 320 and 520 and 530 systems with AES hardware encryption. There. Now, I received an email today from somewhere in Asia where they write the BIOS for ASRocks UEFI BIOS. They said they wrote “me” a new BIOS, but I’m going to suspect that they had it but didn’t release it because they were afraid people would lock themselves out of their drives. The bottom line is, there is an ASRock UEFI BIOS 1.07B, an addition to the 1.07 BIOS. This B version has ATA Password capability for each drive in your system. Now, I’ve not tested how many characters, nor have I looked to see if it can do hash marks, or symbols or caps vs lowercase. What I have tested is encrypting it with the ATA password on my ASRock machine and then putting the SSD into another machine . . . it would either not be recognized or completely unreadable, even by some forensic software I’ve got. This was true for a Samsung 840 EVO 1tb and for an Intel 520 480gb. Sooo, if you have an ASRock motherboard, you’re in luck. I hope I don’t cause any trouble by providing the email address of the technical support team that sent me the BIOS: Asrock_TSD@asrock.com.tw For all those with Samsung 840/850 EVO and Intel SSDs, if you buy an ASRock motherboard, you can do hardware encryption with all the advantages noted above. HOWEVER: based on what I’ve read, if you power off the machine and then forget your ATA Password . . . no one can help you. Not Samsung, Intel, ASRock or the NSA. Unless somehow you can brute force it.

  • So that others who encounter this excellent thread can understand, an encrypted SSD can be backed up/cloned to a nonencrypted drive as backup. The nonencrypted drive can then be stored/secured offsite or away from the computer. This would then address both security and the concerns about a single chip failure in the SSD preventing drive access.

  • A few thoughts here:
    1) This thread is excellent indeed.
    2) Call me paranoid, but if I have data that is encrypted, it means I consider it too important to encrypt it in the first place. To me, making a non encrypted backup of stuff that I did bother encrypting still makes no sense, even in a safe. That’s just me though. On The other hand, I don’t encrypt the whole drive (with the exception of my work’s computer which is at work, which other people like the admin, the cleaners, or basically whoever (our building is very very low security) have physical access too..). Do I care if my hdd at work fails? Nope, cause the files that are important to me, I have also on an encrypted USB..
    3) As far as TC is concerned, I know it’s not supported anymore, but I don’t care, I choose to trust it, it has never been proven to be cracked in the past. As far as I know, Microsoft bought out the creators, just so that it can monopolize it’s own encryption software. If I was the creator of TC and MS paid me a couple of million or whatever, I’d say whatever they wanted me to say too!!!
    4) I just contacted ASUS for the possibility for a beat bios with ATA password for my main PC, and they said it’s not happening,. shame that most manufacturers don’t support ATA pass for desktops..

    • Pro shows that there’s a lot more than one way to do this. I’d go with hardware AES encryption for my SSD, because it’s fast, which is why I’m using an SSD. For a regular hard drive, TrueCrypt is probably better, although I am going to claim ignorance ’cause I’m not sure. Hard drives don’t have the hardware encryption of the EVO or Intel SSDs, I don’t think. Anyway, locking stuff up in a safe is pretty reliable (as is storage off-site), but ultimately security can be breached. Sony. Need anyone say more? What’s best is what makes the user the most comfortable, and all options should be available. Hence my annoyance with ASUS and Gigabyte and such who won’t give BIOS with this feature. I’m still somewhat stunned at how quickly ASRock turned around and gave me the updated password. I also am stunned at their most recent email: They KNOW about this feature and they knowingly are NOT posting it on their board out of concern that newbies would lock themselves out of their drives with no recourse. The same reason ASUS gave for not doing it at all.

      • Interesting thoughts in last 2 comments, and shows what different viewpoints people can have. Also about TrueCrypt, yeah I don’t have a problem trusting it myself personally. The situation is strange (still not sure what happened), but I’m sure it still works fine, and definitely good enough for me. And for #2 by pro… that’s a good point. I cannot imagine how terrible I would feel if I had such important data that I’d encrypt it and then the chance that I could forget the password or something and lose it forever. Anyway, making backups is light years higher on the list than encrypting for me personally but lots of people here put it higher than I do obviously. For work, that can certainly be another issue.

        I’ll end by saying that security is really not an absolute thing. Yes, information security is hard. This probably applies to network security most of all but I’ll include data storage. There are different strategies, different pros and cons and trade-offs, and there is a whole spectrum of how secure something can be. The general public are beginning to realize this more as the news items continue to build up.

  • Just want to correct Al’s statement on hard drives not having hardware encryption. While currently most do not there are some on the market, the ST500LT025 (OPAL 2.0) is one I know for sure does, Seagate also makes some “cloud” drives that are OPAL Enterprise and Toshiba makes some OPAL 2.0 drives as well but I haven’t tested any of those so can’t comment further. I would expect to see more come to market as eDrive is now “standard” as of Win 8.1.

    Before I stir up a hornets nest, I am *NOT* promoting eDrive. I think it is criminal that to have eDrive fully implemented for non-domain (essentially non-business) users you have to give M$ an administrator account on the machine.

  • Hello all,

    Just wanted to let everyone know that I have released a version of msed that supports OPAL compliant drives. msed will allow you to enable the TCG/OPAL encryption without the need for any additional bios support. The just released version (0.20beta) only has a PBA for BIOS computers (no UEFI support yet). There is currently no support for sleep (s3) but hibernation does work. The program is open source. Source code is available on github at http://www.github.com/r0m30/msed (host management utility) and http://www.github.com/r0m30/syslinux (PBA). Executables and a prebuilt PBA are available at http://www.r0m30.com/msed/files.

    This is still early lifecycle code but I’m using it on my primary machine so bugs should be fixed pretty quickly.

    Documentation is being developed now but there are some quick and dirty instructions for getting it running at http://www.r0m30.com/msed/project-updates

    • r0m30, I’m super happy that you wrote msed, thank you very much!!

      Up to now I’ve been using Intel 520s, but I’m currently waiting for a new workstation with a Samsung 850 PRO SSD, which looks like it’s OPAL compliant, in it. If I manage to get your tool working, I’ll probably write another post here, and/or amend this one.

      • @cpbotha

        Hope it works well for you. If you have any problems please open an issue at https://github.com/r0m30/msed/issues

        I have an 850 EVO (non-pro) and that drive is OPAL compliant and works with msed. msed has also been tested on the 840 EVO as well.

        • Hi there r0m30!

          I was able to build, configure and install your msed and PBA image on my new Samsung 850 PRO. I wrote up everything in this post: http://vxlabs.com/2015/02/11/use-the-hardware-based-full-disk-encryption-your-tcg-opal-ssd-with-msed/

          Thank you very much for this fantastic utility! (please let me know in the comments to the other posts if you’d like anything changed)

          I’m also quite curious if you know how exactly Samsung treats the hash your tool passes to it. To they use it to encrypt / decrypt the actual drive encryption keys (that would be great, and would count as “usable”) or is the hash simply compared to a stored one, but not actually used to encrypt the drive encryption keys (“unusuble”).

          Thanks again,
          Charl

          • Hi Charl,

            Thanks for trying msed and posting on your experience.

            I don’t “know” but I doubt that ANY OPAL drive encrypts the DEK with the AK. OPAL is designed to be a multi-user solution. It is possible to give multiple users the ability to unlock a Locking Range. You could give user1, user2 and user3 the ability to unlock the Global Locking range (the OS and swap partitions) and then give each of them the ability to only unlock one user unique Locking Range that controls the portion of the drive that has a partition with their home directory. Whose key would you use to encrypt the Global Locking Range DEK (or more accurately the Range Encryption Key)? With the ability to define multiple users and multiple locking ranges it would be quite difficult to encrypt a DEK (REK) with a single users AK.

  • Do you need to install this “ATA security extension Bios” only to set the password or do you also need it to enter the password later at startup?

    If only needed for password setting, then why not plug the SSD to a notebook with a bios supporting 32 characters ATA password. Then unplug the SSD and put it in your desktop.

    Even if the desktop mainboard would not have any feature to set or modify an ATA security password, the password (hash) is already “in” the SSD, because it was placed there as shown above. When the machine now boots, the SSD should provide the short boot up routine to enter the password for its unlocking. This is how I understand the “TCP OPAL” specification – that the SSD runs a boot routine to enter the pw for itself.

    So what is your experience? Do you still need the mainboards’ BIOS in order to enter the pw and send it to the SSD or does the SSD manage the pw entry on its own after it has been set once?

    Cheers, Mosquito337

    • Ok, after reading almost all posts here, I think to answer my questions myself:

      1. For ATA security password you need the Bios for both, setting the pw + entering it all the times needed for boot. If you change the drive to another machine with another mainboard/ BIOS version/ type, it is likely the transfer of the ATA pw will be handled differently so that you cannot access your data anymore. You would likely need the same mainboard + BIOS version as when the ATA pw was set. Further, there is intransparency in many cases by the manufacturers as how the AES encryption key is generated or protected by hashing the ATA pw. It can be everything from using the key openly and the same for all drives and so on or have it properly defined, encrypted, decrypted by utilizing a hash from the ATA pw.

      2. OPAL is a new specification for some newer SSDs or firmware updates to some older ones. Drives with that are independent from the mainboard. However, you need a 3rd party software in order to provide a PBA-programme that is then executed first at boot to let enter the pw. The pw is set by a management software within the particular operating system. The PBA-programme ist stored at some open (=always unencrypted) space on the SSD – because there must be something unencrypted before the encryption pw can be entered. This storage area for the PBS is different from the rest of the SSD that is inaccessible due to its AES encryption as long as no correct pw is provided.

      There is a software “Embassy Security Center” for about 40$ that seems to do this job:
      http://store.digitalriver.com/store/wavesys/en_US/home/ThemeID.13077500

      I only need this software in order to modify or initially set the pw, but I can move the drive to any other machine, even without having this software installed on it, because the PBA works directly from out of the SSD and this is enough to enter the pw to unlock.

      So far so good. I will try it out in the next days after I receive my new PC with a Samsung 850 EVO 1TB in it.

      – A side comment: I wonder why the OPAL guys or drive manufacturers do not provide a universal PBA on their own? They could make a completely independent SSD, not depending on 3rd party software (OPAL Management), nor 3rd party hardware (Mainboard with BIOS for ATA pw). Just put a PBA in the SSD that at first start asks to set a pw and for later starts asks to enter the pw for unlocking or type in a listed command to modify/ delete the pw. That should not be so difficult. Why all this mess with relating SSD-encryption to BIOS, OS managed software, etc.? SSD encryption could or SHOULD be a stand alone solution.

      • @Mosquito337

        If that new computer is Windows 8.1 and you don’t mind giving Microsoft an administrative account on your machine and your keys eDrive will manage the hardware encryption of OPAL 2.0 drives.

        Re: the ability to move the drive with OPAL. You MAY be able to move the drive. It depends on the implementation of the software you use. The software could use the computers TPM to generate/manage the key and in this case moving the drive would probably not be possible. I don’t know for certain but from the description of ESC it looks like that is the case.

        It is also not required that a PBA be used, the software could install a UEFI module to manage the unlocking of the drive. The Enterprise SSC does not require the implementation of the shadow MBR table (where the PBA is stored).

        That is an interesting idea of combining the management environment into the PBA, I’ll have to take a look at making that an option for msed. As to why there is no universal PBA. The TCG (the OPAL guys) are a standards body and developing/releasing software would put them in direct competition with their sponsors. I wouldn’t expect to see the hardware vendors releasing OPAL management simply because the vast majority of their customers are going to be windows users who will use eDrive and blithely surrender their keys to MS.

    • “” I wonder why the OPAL guys or drive manufacturers do not provide a universal PBA on their own? Why all this mess with relating SSD-encryption to BIOS, OS managed software, etc.? “”

      Mosquito337, that is a good questions. All this hype and advertising of OPAL drives and SED’s and in practice it’s unusable by most users.

      Has anyone used r0m30’s software? I wouldn’t use some non official tool in case I got locked out of my own drive..

      • “I wouldn’t use some non official tool in case I got locked out of my own drive..”

        That’s interesting, one of the premises of this post is that you modify your bios to enable the use of the ATA password on motherboards that don’t have “official” ATA password support.

        The primary use of msed for the last year has been to recover Crucial SSD’s that the owner had been locked out of by Windows or another OPAL management software program, because until very recently Crucial did supply any software to do that job.

  • Hi r0m30,

    my new computer is Win 7 Ultimate. No Win 8(.1) or 10 😉

    I have no TPM chip installed. So I expect the OPAL management software to place the PBA on the SSD directly with no relation to the machine or mainboard, etc. I wonder, if I could put the SSD in another machine that boots up from another drive. There, I could install again the OPAL management software and access the SSD this time as non-system drive? It should be possible to unlock it without deleting it, as long as I provide the right pw, no?

    Anyway, as I have an ASrock mainboard (X99X Killer), I also contacted the support on the email provided above by Al Winston. They returned one day later with the BIOS Update including ATA security password handling. I understood the rest of their email, that 32 characters is fine and that nothing is stored in the CMOS of the BIOS, but transfered to the SSD. They say to not be able to help me, if I forget the pw – which is exactly what I want from them.

    I think, I will go with this feature to use the ATA security BIOS, if it was provided to me for free and there is no guarantee, too, that the OPAL management software will support moving the SSD to another machine, etc.

    I understand, that my data may be lost, if the mainboard fails. But this is just another risk as if the SSD would fail. I can do backups from time to time and store them in a Truecrypt (or Veracrypt) container on a USB external HDD. If the mainboard really would fail, I will get back the same as long there is warranty, and later, I could get one of the same cheap on a flea market, a used one at ebay, etc. I just have to store the BIOS Update at a safe place to reload it then. So actually nothing that could not be handled, I think.

    • Great update Mosquito. Is there any chance you could try that test? After your configuration is complete, bring your encrypted SSD to another computer to learn if you could access it.

  • @Mosquito337

    Yes, msed managed drives can be unlocked and read on a different computer that boots from another drive if you install the host management program. One thing to be aware of is that msed only supports ATA attached drives. It will not try to manage/unlock a drive in a USB enclosure (although some usb enclosures under Linux do look like ATA attached drives so the host management software does work).

    The PBA and AK are managed independently of the bios/motherboard. The loadPBAimage command will place the PBA in the shadow MBR table on the drive. The drive then presents this image to the bios at boot time if the MBREnable flag is set. The password is hashed using the PBKDF2 function salting it with the drive serial number as returned by the ATA IDENTIFY command before it is sent to the drive as the “C PIN” (what the TCG calls the password). This creates a drive unique password for each managed drive.

    msed doesn’t create any superAdmin or other backdoor either, it never stores or saves your password, so if you forget your password you are in the same situation as with the BIOS password, except that, unlike ATA security, OPAL provides a way to crypto erase and reuse the drive if you have forgotten the password.

    You seem to have done your homework and are aware of the issues around encrypting your drive using the ATA password and/or OPAL, good luck and enjoy your new system.

  • @r0m30

    Just got my PC with the Samsung 850 EVO. It seems to have this shitty master password already set and “security level high”, not “max”.

    I applied hdparm and it looks similar like this other guy found for his 840 Pro:

    https://www.zeitgeist.se/2014/09/07/enabling-ata-security-on-a-self-encrypting-ssd/#comment-3910

    hdparm –Istdout /dev/sda
    (for me it is drive a, he has it as b, then sdb)

    the “word 128″ tells about the security setting:
    “word 128 (0021): security status (bit 8: MASTER PASSWORD CAPABILITY ~ 0 = high, 1 = max; bit 4: SECURITY COUNT ~ 1 = EXPIRED; bit 3: SECURITY FROZEN; bit 2: SECURITY LOCKED; bit 1: SECURITY ENABLED)”

    I am stuck here. May move to OPAL if this could help, however, I am not sure, if this is a general feature, so that the “master password” will remain active even when I used a OPAL software (ok, I could check with hdparm afterwards, if this “bit 8″ in “word 128″ had changed to 1, finally.

  • I’m no ATA security expert, I’ve never owned a machine that supported the BIOS password.

    What I can tell you is that once OPAL security is enabled the ATA security feature set is disabled by changing the DCO, OPAL and ATA security are mutually exclusive.

    You haven’t mentioned if the drive has data you want to keep on it, fair warning some of the steps below can/will erase the drive, Backup any data you value.

    Write down your PSID so you can revert the drive if necessary.

    Now do another backup :-)

    I’m guessing but the master password is probably there as a backdoor for Samsung magician to be able to “rescue” you from a forgotten/lost the ATA password. You can’t handle real security after all so the benevolent Samsung will make sure you don’t hurt yourself;

    Have you contacted the PC manufacture to see what they have to say about the master password? Maybe the are the ones creating the backdoor.

    Have you tried Samsung Magician? It has the capability to change the security state of the drive. You could try setting the drive to TCG status and seeing what hdparm and msed –query tell you after it makes the changes. I’m leery of the “eDrive” security status because I don’t know what Samsung thinks is so special about eDrive, it’s OPAL 2.0 with Single User Mode but they claim it’s special so they could disable the PSID user making a PSID revert impossible. This is against Microsoft’s recommendations for eDrive but without transparency you can’t be sure.

    On my 850 non-pro I didn’t do anything but run msed to setup the drive, but it was a new drive not part of an OEM package.

  • Thank you r0m30 for this fruitful discussion!

    What you describe would be my next step. However, before that I will give the ATA security one last chance:

    According to
    https://www.zeitgeist.se/2014/09/07/enabling-ata-security-on-a-self-encrypting-ssd/
    there should be a way to reset the Master Password, as long as the drive is unlocked (no user pw set) and the security level is 0 (“high”):

    hdparm –user-master m –security-set-pass masterpass /dev/sdb (or sda, if this is the SSD): “will overwrite factory default master password”

    I am not sure about the syntax, but hope that “masterpass” means the new password, so masterpass = BennyBunny for example (not my pw ;-). I should be able to then set a different user pw (e.g. Jabberwocky) in my Bios. Restart the system (with power off to let the drive lock), then enter the user pw to boot up my system and in a second run use the master pw to do the same. This should give proof, if I could redefine the master pw.

    Btw, yes I did backup my system. However, it is a clean one, so not much than OS itself on it. Will transfer my important data later to it, if all works.

    Here is more background information from Samsung about this master password:

    http://www.samsung.com/us/pdf/memory-storage/840PRO_25_SATA_III_Spec.pdf

    “The 840 PRO is shipped with master password set to 20h value (ASCII blanks) and the lock function disabled. The system manufacturer/dealer may set a new master password by using the SECURITY SET PASSWORD command, without enabling the lock function.” I hope this is same with 850 evo.

    -> I will try first before I change the master pw, if I can enter my drive after setting a user password (e.g. Jabberwocky) with just typing ” ” (space) as factory installed master password. That would be a great joke! Imagine millions of people feeling secure with their user passwords for pretty AES on SSD and anybody could compromise them by just entering a lucky space.

    Will let you know about that after I try it out later this day.

  • Back from testing:

    1. The good news is, the “master password” as space ” ” did not work. It could not be used instead a set user password to unlock the drive and get in to the data. Also “tttttttttttttttttttttttttttttttt” (32 times t) as found somewhere in the net as known Samsung master password for hdds did not work.

    2. However, there is still the indication that a master password exists and is set: I get that info in the Bios “Master password: installed” and hdparm shows “fffe” as indication for master password. It also shows “security level high” and not “max” which means whatever the master pw is, it can be used against my encryption.

    3. I had a phone call with a support guy from Samsung in the US (although I do not live in the US; but in Switzerland, however there is no local supply). I asked him for the default factory setting of security level, high or max, and his answer was “max”. I did not trust him, because it sound like saying what I wanted to hear without the ability to prove. However, as mentioned above I could prove. Poor support (except he is right and it was the OEM PC builder to change settings).

    4. The bad news is, I could not reset the master password with hdparm. I use the windows version and it says to not have all the security commands available to the time it was build. Maybe the linux version is different, but I give up here and will not test that. I also could not modify the security level from displayed “high” to “max” as this would still be ok to make the master password useless entering my data, but just allow to erase it.

    5. I did not try to set the user password with hdparm, because I would not risk to be outlocked due to the mainboard maybe transferring the pw as scancodes (do not know that).

    6. I have mailed my OEM computer supplier, if they have set a master password on their own or know what the one of Samsung is. I will let you know if I get a reply on this.

    7. I thank so much ASRock support, even if they do provide to set the user password only and not the master password in the UEFI BIOS – at least they display the existence of this “Master password: installed” which made me suspicious that there is hiding something. I guess that one or the other mainboard manufacturer may leave that information out. Then people may be happy to set a user pw and think that it was – without knowing even the existence of something hidden master password to compromise them. Many big thanks to ASRock, please.

    8. I will move on to OPAL and see how this works..

    Cheers,
    Mosquito

  • Finally moved ahead with TCG-OPAL using the Software Embassy Security Center for 40$. It took me less than 15 minutes to install and set enverything up.

    Meanwhile, I received some email responses for my investigation regarding the ATA security “master password”:

    1. The OEM PC manufacturer (Alternate) claims to not be the culprit and not set or change passwords on harddrives.

    2. ASRock support returned back with the following email, which I interpret as if they know and are setting this master pw:

    “The Master password function is designed for situation that forgot or lost the password.
    Because the ATA password is built in hard disk, if you got lost the password, the hard disk will be not able to use. This mean the Master password function is a backup solution and it’s needed. We will not make public about the rule of Master key, only in special situation like losing the password. Also, the Master password function is not able to be modified by user.”

    Anyway, thanks to them for the open communication, however, anybody using this ATA security function from ASRock as provided by the support should be aware, that they have a backup key to decrypt the data! Not really what one should expect using encryption. So obviously, this ATA security is no option to follow at all !!!

    • wrt ATA Master Password: I believe that there are two modes which the Master Password can be set to use. One works just like the regular password. In this case, I agree with you about it being insecure. The other mode, however, triggers a “wipe the disk” operation when used. Thus it allows recovering use of the disk but not the data on it.

      The BIOS on my Dell laptop allows me to choose which mode the Master Password should use. Needless to say, I chose the second mode. Any BIOS which doesn’t give you this option is severely flawed, in my opinion.

    • Well at least you found out who was compromising the security. I agree that it isn’t what you or I would want but I’m certain that the mobo and drive vendors get orders of magnitude more complaints from the how could you let me brick my drive with my own stupidity complaints than how could you compromise my security complaints.

      I’m curious, did ESC install a driver to handle S3? If they did do you know where in the driver stack it lives?.

  • I sent an email to Charl and he suggested posting it here, so that others could benefit from it as well.

    Question:

    How do I know if my motherboard supports ATA password? There’s just no info anywhere on this, not in the reviews nor on manufacturer sites.

    Are there any updates on any other drives? I.e. Toshiba Q Series and Samsung 850 EVO and 850 PRO drives, and OCZ Vertex 180 and 460? And Intel 530 and 535? Those are newer versions for Samsung, OCZ and Intel, as I understand, so I think that’s quite relevant to the general public too.

    Answer:

    See this post: http://vxlabs.com/2015/02/11/use-the-hardware-based-full-disk-encryption-your-tcg-opal-ssd-with-msed/ — TCG Opal support makes all of this much more convenient. I currently have a Samsung 850 Pro with which I use the open source MSED tool. There are more easy to use solutions if you’re not on Linux.

  • According to this webpage http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/whitepaper/whitepaper06.html BOTH the Samsung 840 and 840 Pro support what you call “usable” encryption.

    Also, if you setup an encrypted drive in a Lenovo laptop that is now broken, you can still access your data, see https://jbeekman.nl/blog/2015/03/lenovo-thinkpad-hdd-password/

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=""> <s> <strike> <strong>