How secure is the ATA password?

Hi,

I will get my T420 tomorrow and I plan to replace the HDD with a Intel 320 SSD or a Vertex 3. I usually encrypt my discs with dm_crypt or Truecrypt, but although the new CPU supports AES-NI extensions, I guess the encryption would slow down the SSD speed significantly.

Now I've read that the SSDs encrypt the content by default with AES using a random key generated on the SSD itself. If you specify a ATA password in the BIOS they use that password to encrypt the AES encryption key (?).

Now my question is how secure is this "poor man's encryption"? There are many results when searching for "ATA password recovery" on Google. I also found this website with a tutorial on how to recover the BIOS password from older Thinkpads by soldering a connection to the BIOS chip. Does that also apply to the ATA password and does it still work on newer models?
Will the encryption with the ATA password survive a few hours googeling and trying by a clever thief? Will it even survive the attempts of a professional data recovery company with a budget of 1000-2000$? Or is it about as secure as Truecrypt?

 

ATA password is only a password stored on the hard drive. Don't expect it to protect your data, it only prevents unauthorized access to your hard drive while it is inside your powered-off laptop.
Crack the ATA password was a very simple job. Because the password is a very old way to protect data (at least it have a history of 25 years), the cracking softwares are most likely running on DOS. There are free tools that can do it in a few seconds.
So I simply summarize it for you: DO NOT COUNT ON IT.

 

Check this out:
Intel 320-series SSD and FDE (Full Disk...: Intel Communities

Long story short: it is clear that the whole encryption thing is unclear.

 

Some do. The vast majority do not.

It's right at the "broken by a bored teen with some Google skills" level of security. There are exceptions to this, but unless you know that your drive does FDE and that its FDE implementation is strong, it's best to assume that the ATA password is a useless security measure.

My advice would be to use a known-good FDE scheme (Truecrypt, LUKS, etc.) unless you have good reason to do otherwise.

 

I found this post to be fairly convincing: Intel 320-series SSD and FDE (Full Disk...: Intel Communities
It looks like whilst an ATA password on its own isn't secure, an ATA password used to encrypt whole disk encryption keys such as on the 320 is rock solid.

 

There are reports (as people have linked to) that some manufacturers are using ATA passwords correctly now. However, if you really need the security then Truecyrpt or PGP FDE should be mandatory. The performance hit exists but it would be a secondary priority for those who can't live without FDE.

 

With AES-NI there is basically no performance hit for using full disk encryption. Even the mid-range Sandy Bridge CPUs will push 2500MB/s using AES-NI which is 10x more than any SATA 3Gb/s device can deliver.

Keep in mind that no FDE solution is foolproof. If you leave your laptop asleep the decryption key is still in memory and there are attacks (e.g. freeze attack, reading memory via FireWire) that can trivially decrypt your disk. With BitLocker in transparent (no-PIN) mode this is even worse because the same attacks work when the laptop is off (since the attackers can simply boot it into the OS). And of course if you choose a weak password/passphrase that's a potential attack vector too.

If you use PGP or TrueCrypt, use a strong passphrase, and remember to turn your laptop off after you use it, FDE can be quite strong. Otherwise it mostly serves as a deterrent to the typical thief.

 

Thank you for your posts! Its true that a CPU with AES-NI can encrypt and decrypt data faster than the SATA 6GBit/s port. However, look at a benchmark on the German Tomshardware of Truecrypt 7.0a with and without AES-NI on a SSD. The impact on the Input/Output operations per second is HUGE. As far as I understood this I/O operations are even more important than the raw bandwidth for the feeling of snappiness of the system... And the OCZ Vertex 3 with the Sandforce SF-2000 chipset gets its speed from compressing the data before writing it. That is difficult for encrypted data.

But since the ATA password doesn't seem to be serious, I guess I will get the (cheaper) Intel 320 and use a real encryption with dm-crypt/LUKS.

 

I would really love to have FDE hardware based discs. The main thing is, where are the ATA passwords stored. If they are stored also encrypted in the disc storage area, then I think it is quite secure in a real world life.

Sadly, manufacturer's documentations are really poor at this. They say "data is not readable to user" the end.

 

Uh... and how exactly does that encrypted password get retrieved?

The above posts make some good points: for software FDE to work correctly, you have to address a couple other factors.

Personally, I never leave my machine unattended without shutting it down, I use PaX's memory-scrubbing feature to reduce the risk of encryption keys lingering in freed memory, and I disable (physically, if needs be) any DMA capable ports that I can (i.e. IEEE1394 is out, USB is OK, etc.)

 

The encryption module is between the interface and storage, so that way.

 

So what exactly does this proposed setup gain?

I mean... with most FDE systems, the user-supplied passphrase goes through a key expansion function to generate the key used to decrypt the key used to encrypt the drive. What exactly does encrypting the password and storing it somewhere on the drive gain? Even if you're hashing it (since encrypting it with a known key would actually be a *very* bad idea), what does that provide over the aforementioned design?

 

So where the ATA password is stored and in what form?

 

On a drive that does hardware FDE like I described, it's not stored at all.

Actually, I'd hope that pretty much any sane security implementation would *never* store user passwords, encrypted or otherwise.

 

ThinkRob, do you have any documentation where this is explained? I am not sure if I understand you properly.

Are you saying, that on FDE drives (we are talking about the HW based drives, right), the user/master passwords are not stored at all? How the passwords are confirmed on startup then? When you write the password on startup, then it must be compared to "anything" if it is right or not, isn't it?
I believe that on regular drives, ATA passwords are stored in a non-alocated (by OS) service area in the beginning of the drive. But some utilities and HW can read this area, and this is the reason why ATA passwords are weak. I thought, that passwords on FDE drives are alocated the same, but hashed by the encryption circuit, so you cannot read them.

 

Hmm... explaining this might get a bit tricky. I'll try to make this as general as possible, but I fear my ability to explain and simplify is substantially worse than my knowledge of cryptography.

First, you need to keep in mind that encryption is different than hashing. Encryption -- at least properly functioning encryption -- is reversible (i.e. you can encrypt a piece of data with your key, get some ciphertext, and then decrypt the ciphertext with the same key to get the original data.) A cryptographically-secure hash function is not (i.e. once you've hashed some data and gotten a hash, you can't then use that hash to recover the original data.)

In most systems that require a passphrase (and that aren't implemented by clueless programmers), user-supplied passphrases are hashed prior to storage, and the original input discarded. This makes it basically impossible for the password to be recovered simply by obtaining the hash. (If you're wondering why they're not just encrypted and later decrypted to check subsequent input... well... if you encrypt them, where do you store the key?) [1]

Now in some cases it doesn't matter if you store the passwords in the clear. Traditional hard drives are one such example; for a drive that features no built-in encryption, anyone who is able to access the flash on which a user password is stored can simply pull the platters and read the data that way. In this case, since physical access means game over, there's really not much security gained by hashing the password prior to storage. I'm sure some implementations do, and some implementations probably don't -- but without FDE, the difference is really just academic when it comes to security against a well-prepared attacker.

Enter encryption.

With FDE, the data that's written to the platters is encrypted -- presumably with something like Rijndael -- so physical access to the disk itself doesn't necessarily mean game over. Of course when you're dealing with private key crypto, your information is only as private as your key, so we've now got a problem of 1) creating a strong key 2) storing that key in a way that allows us to decrypt the data on command, yet does not expose the key to anyone who comes across the machine when the drive is powered off.

The first, and most obvious solution would be to use the user's passphrase as the key. Simply grab the bits of the corresponding ASCII characters and use those.

Consider the following procedure:

Code:

.----------.                   .----------------.                    .------.
| password | --- get bits ---> | encryption key |  --- encrypts ---> | data |
`----------'                   `----------------'                    `------'

That solution sucks for a couple of reasons:

1) The key length might be the wrong length.

2) The user will never be able to change the password, since doing so would require us to re-encrypt all the data on the drive.

Ok, so that's right out. We can solve the first problem pretty easily though. We can create a key expansion function which will create a key of the requisite size from any given input. It won't make up for a weak passphrase choice (since an attacker can simply run their guesses through said function), but it will allow us to use any size passphrase we choose.

Our encryption scheme now looks like this:

Code:

.----------.                   .--------------------.                    
| password | --- used in --->  | expansion function |  --- which produces --.
`----------'                   `--------------------'                       |
                    .------.                         .----------------.     |
                    | data | <--- which encrypts --- | encryption key | <---'
                    `------'                         `----------------'

Right, so we've solved the first problem... but we're still kinda stuck. The user can use any password, sure, but he can never change it. He's not gonna like that...

But what can we do? We can't simply let him change the password, since then he'd lose access to his data, and we can't just keep using the old password, since that might put the data at risk (if the password is compromised, for example.)

We can introduce a second key, this one stored on the drive (or on flash, etc. -- the location doesn't really matter.) So now we're going to use two keys, let's call them 'K1' and 'K2'.

K1 will be generated when encryption is enabled. It will be entirely random -- we'll literally just generate the requisite number of random bits. This will make it virtually impossible to guess, and thus very strong.

K2 will be based on the user's password (via some expansion function, see above). We'll use K2 to encrypt K1.

Confused? Here's some ASCII art:

Code:

.-------------.                            .----.                    
| random data | --- used to generate --->  | K1 | --- which is stored, and... -.
`-------------'                            `----'                              |
                                                                               |
.----------.                   .--------------------.                          |
| password | --- used in --->  | expansion function |  --- which produces ---. |
`----------'                   `--------------------'                        | |
       .------.                           .----.                   .----.    | |
       | data | < --- used to encrypt --- | K1 | <--- encrypts --- | K2 | <--' |
       `------'                           `----'                   `----'      |
                                             ^---------------------------------' 

So now we're in good shape. The data is encrypted with a very strong key (K1) produced from random data. That key is stored on disk or in flash, but that doesn't matter because it itself is encrypted with K2. K2 is generated from the user's passphrase, so now when the user changes his passphrase, all we have to do is decrypt K1 with the previous passphrase and re-encrypt it with the new K2. This is fast (we don't have to re-encrypt all the data) and easy.

We're reasonably secure against a physical attack when the drive is off. Even if the attacker can dump the flash or pull the platters, they can only access the encrypted version of K1, and without the passphrase they can't generate K2, and thus can't decrypt K1.

When it comes time to decrypt the data (such as when the machine boots), the process is simple: we run the user-supplied passphrase through our magical expansion function and produce a key. This may or may not be the correct key -- we won't know right away. We have to take that key and use it to try to decrypt K1. That too will produce a key, again, not necessarily the right one. We can then take that key and try to use it to decrypt the drive. That might work (if the key was decrypted successfully), or it might not (if it wasn't.) If it worked, the passphrase must have been correct. If it didn't, it wasn't.

Simple.

---

So that's how FDE is supposed to work, in a nutshell. The above explanation leaves out a number of steps, and there's definitely a lot of room for variation (and indeed, a lot of variations have been made) on the above scheme -- but the basic principles are all there.

Hope that helps!

[1] This isn't quite true, as a hash without salting is a bad idea -- but if you know enough to call me out on that simplification, you already knew that.

 

Okay, thank you very much. Basically then, the FDE drives are safe, only way to beat them is with a brute-force on generating K2.

 

Well really you can brute force either key, but since a completely random key will take you (roughly) from now until the earth crashes into the sun, you're probably better off attacking the one produced from the user's key, yes.

 

Do all Thinkpads have ATA user/master password options in the bios?

 

haha yes, I meant that