Are Intel 520 AES keys encrypted with ATA password?

[idata]

(I've also posted this question, slightly differently worded, as a reply to another relevant discussion: /message/174081# 174081 http://communities.intel.com/message/174081# 174081 )

I'm putting together a blog post on vxlabs.com listing drives that do and don't do usable AES encryption, that is encryption where the AES keys are themselves also encrypted with a user password.

All of the Intel documentation on the 520 (AES tech brief; the manual; etc.) vaguely states that the security is based on the AES encryption together with the ATA password, but I have not been able to find any official documentation confirming or denying the following details:

1. Is the ATA password used to encrypt the AES keys?
2. Is the ATA password itself stored as an irreversible hash?

I know that both of these have been confirmed for the 320, but I'd like to see explicit proof for the 520 as well. It's a new drive with a new controller, so it's not guaranteed that Intel has followed exactly the same path as with the 320. Once again: I'm looking for proof, either in official Intel documentation, or by an Intel representative, or by drive firmware hacking.r

[idata]

Here is the long answer...

SSDs (unlike traditional Full Drive Encryption hard drives that have been around 5 years) are NOT NIST certified! NOT OPAL compliant! Don't trust them for much. They are very immature right now as far as firmware and compliance goes in general - let alone any real encryption standards.

http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html

See this paper about how AES encryption works:

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

And how the drives are supposed to be programed:

http://www.trustedcomputinggroup.org/files/static_page_files/E70FFABD-1D09-3519-AD656F3E95ED9DBE/TCG... http://www.trustedcomputinggroup.org/files/static_page_files/E70FFABD-1D09-3519-AD656F3E95ED9DBE/TCG...

No wonder they are full of firmware bugs!!!!!!

The firmware and methods used are totally at the whim of the programmers. Given the track record of SSD firmware failures from all vendors - be vary very afraid!

But unless they have done something horribly wrong it "should" work like this.

1. You enter you password at the boot prompt.

2. The BIOS passes that plain text password to the drive controller. (They are normally not hashed by the BIOS otherwise you can't move drives from machine to machine and software password control programs fail. And yes, if your BIOS only allows say an 8 character password, your password really is just that weak. (Although the software password management solutions bypass that. - But they are even more frightening to use.)*

3. Now your password is indeed salted and hashed inside the drive controller and turned into some messy 128 bit code in the usual cryptographic ways (key expansion). That code is is stored in the drive and is used to enable** the encryption system.

4. The drive has its own 128 bit password too that is set at the factory and is supposed to be erased and reset if the drive is secure erased. This password is stored as is and some drive makers even print it out on the label just for sport. Thus, if no ATA password is set they really can read off the bare drive platters or NAND with that found password. Of course, they can also just read the drive directly so who cares... But this IS the important one!!! Be sure to reset and erase the factory password when you get the drive so it is a new unknown password. Then, it really will be just about impossible to read the data out.***

So wait until the NIST and OPAL certified SSDs com out. And get a computer that allows really long ATA passwords. The standard say 250GB certified FDE magnetic drives are about $100 right now... So buy the SSDs for the wonderful speed and forget about security unless it is really just for keeping children and small animals out. But the hardware side of the Intel 520 is very good!! And if you don't try to play any encryption tricks you should not run into firmware troubles.

*

128 bit encryption == 2^128 = 340E36 or 259E18 years.

8 characters with 94 possibilities == 94^8 = 6.1E15 = 1.7 hours.

There are 94 possible keyboard characters normally. All those computers at the NSA are not trying to break 128 bit passwords. They are used to make rainbow tables to help find the limited set of say 8 digit password hashes. Just this Toshiba I have here has a 10 character ATA password limit but that would take 1.7 years. So just a few extra ATA password characters really counts there!

** That IS the weak spot. If you can get into the drive's brains. Find a way to trick in into thinking the password hash is just fine - you're in.

*** Use ONLY the drive makers software and methods to do this!!! Don't use Linux on the 520 SSD to reset the password or you will find a bug, like I did, and brick the thing out... BTW – NIST and OPAL compliant drives can't be bricked.... You can always secure erase them back to a fresh ready to go state. That's not rocket science there... I have 520 with an apparently scrambled ATA password now that can't be reset just by resetting the whole drive. Guess how happy I am about that. The drive being perfectly fine mechanically and electrically, but it is as dead as a brick now because Intel could not figure out how to reset the passwords on a full security erase. So it is dead now due to firmware...

[idata]

Thank you for your extensive answer.

I already have an Intel 520. I am already using a long ATA password, via the ATASX extension that I patched into my mainboard BIOS. When I got the drive, I secure erased it before installing strong ATA user and master passwords. I know how the encryption should work.

My question is exactly concerning your ** footnote. It has been confirmed by Intel on these forums that the Intel 320 in fact stores the ATA password as an irreversible hash. It has also been confirmed that the AES key is encrypted with the ATA password.

I would like to see this same official confirmation concerning the Intel 520. I have read more than my fair share of speculation over the past few days.

[idata]

I've finally found official confirmation that the Intel 520 does indeed encrypt its hardware AES key with the user-supplied ATA password. See at the bottom of page 3 in this Intel white paper: /docs/DOC-19512 http://communities.intel.com/docs/DOC-19512

I also wrote a blog post summarising the sad state of usable hardware encryption in current SSDs: http://vxlabs.com/2012/12/22/ssds-with-usable-built-in-hardware-based-full-disk-encryption/ SSDs with usable built-in hardware-based full disk encryption | vxlabs -- the bottom-line is that of all current consumer SSDs, the Intel 520 (and 320) are the only ones of which it has been confirmed that they encrypt their AES keys in the correct way.

[idata]

I just must say....

As Andrew Grove warns - "Only the paranoid survive"...

Then read this "spec update"....

Can you really trust anything they "print"... Do you really actually think the dramatic difference between AES 256 and AES 128 bit encryption was an 'accidental flaw' "discovered" by quality assurance... "Exactly", how would they actually "test" for that??? Ask them for a the "full report" on there testing there, and just see how far you get... Will the next 'update' say, "No real encryption at all! It was all just a big lie since Toshiba was getting more sales... And all your data is public as of two years ago..." Their disclaimers and agreements cover that situation very well, if you read them!!!

Look at Microsoft's SHA1 - 14 character encryption... That was really 2 x 7 character encryption that actually only takes 90 seconds to break...

Look at wireless encryption. WEP - Way too Easy to Pork, so they replaced it with the super ultra secure WPA... Ten minutes... So I guess it is "more secure"... TrueCrypt has so many SSD problems....., let alone that cool virus that snatches and sends off the clear text password to some strange IP address...

Encryption really needs third and fourth party verification, in third and fourth countries, by third and fourth persons. Or, it needs to by fully open source so nobody trusts it anyway...

Security Expert Wanted - Extreme paranoia required...

Sorry, but basing 'facts' on corporate handouts.... You need to read the fine print at the bottom tooo!!!!!!!!!!!!!

"

This paper is for informational purposes only. THIS DOCUMENT IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY

OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY

PROPOSAL, SPECIFICATION OR SAMPLE. Intel disclaims all liability, including liability for infringement of any proprietary rights, relating to use of information in

this specification. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted herein.

"

They really do lie, right directly into your face, you know......