How secure is the ATA password?

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