A look at password security, Part V: File and Disk Encryption

Posted by ekr on 05 Sep 2020

This post originally appeared on the Mozilla Blog

The previous posts ( I, II, III, IV) focused primarily on remote login, either to multiuser systems or Web sites (though the same principles also apply to other networked services like e-mail). However, another common case where users encounter passwords is for login to devices such as laptops, tablets, and phones. This post addresses that topic.

Threat Model #

We need to start by talking about the threat model. As a general matter, the assumption here is that the attacker has some physical access to your device. While some devices do have password-controlled remote access, that's not the focus here.

Generally, we can think of two kinds of attacker access.

Non-invasive: The attacker isn't willing to take the device apart, perhaps because they only have the device temporarily and don't want to leave traces of tampering that would alert you.

Invasive: The attacker is willing to take the device apart. Within invasive, there's a broad range of how invasive the attacker is willing to be, starting with "open the device and take out the hard drive" and ending with "strip the packaging off all the chips and examine them with an electron microscope".

How concerned you should be depends on who you are, the value of your data, and the kinds of attackers you face. If you're an ordinary person and your laptop gets stolen out of your car, then attacks are probably going to be fairly primitive, maybe removing the hard disk but probably not using an electron microscope. On the other hand, if you have high value data and the attacker targets you specifically, then you should assume a fairly high degree of capability. And of course people in the computer security field routinely worry about attackers with nation state capabilities.

It's the data that matters #

It's natural to think of passwords as a measure that protects access to the computer, but in most cases it's really a matter of access to the data on your computer. If you make a copy of someone's disk and put it in another computer that will be a pretty close clone of the original (that's what a backup is, after all) and the attacker will be able to read all your sensitive data off the disk.

This implies two very easy attacks:

• Bypass the operating system on the computer and access the disk directly. For instance, on a Mac you can boot into recovery mode and just examine the disk. Many UNIX machines have something called single-user mode which boots up with administrative access.

• Remove the disk and mount it in another computer as an external disk. This is trivial on most desktop computers, requiring only a screwdriver (if that) and on many laptops as well; if you have a Mac or a mobile device, the disk may be a soldered in Flash drive, which makes things harder but still doable.

The key thing to realize is that nearly all of the access controls on the computer are just implemented by the operating system software. If you can bypass that software by booting into an administrative mode or by using another computer, then you can get past all of them and just access the data directly.^[1]

If you're thinking that this is bad, you're right. And the solution to this is to encrypt your disk. If you don't do that, then basically your data will not be secure against any kind of dedicated attacker who has physical access to your device.

Password-Based Key Derivation #

The good news is that basically all operating systems support disk encryption. The bad news is that the details of how it's implemented vary dramatically in some security critical ways. I'm not talking here about the specific details about cryptographic algorithms and how each individual disk block is encrypted. That's a fascinating topic (see here), but most operating systems do something mostly adequate. The most interesting question for users is how the disk encryption keys are handled and how the the password is used to gate access to those keys.

The obvious way to do this -- and the way things used to work pretty much everywhere -- is to generate the encryption key directly from the password. [Technical Note: You probably really want generate a random key and encrypt it with a key derived from the password. This way you can change your password without re-encrypting the whole disk. But from a security perspective these are fairly equivalent.] The technical term for this is a password-based key derivation function, which just means that it takes a password and outputs a key. For our purposes, this is the same as a password hashing function and it has the same problem: given an encrypted disk I can attempt to brute force the password by trying a large number of candidate passwords. The result is that you need to have a super-long password (or often a passphrase) in order to prevent this kind of attack. While it's possible to memorize a long enough password, it's no fun, as well as being a real pain to type in whenever you want to log in to your computer, let alone on your smartphone or tablet. As a result, most people use much shorter passwords, which of course weakens the security of disk encryption.

Hardware Security Modules #

As we've seen before, the problem here is that the attacker gets to try candidate passwords very fast and the only real fix is to limit the rate at which they can try. This is what many modern devices do. Instead of deriving the encryption key from the password, they generate a random encryption key inside of a piece of hardware security module (HSM).^[2] What "secure" means varies but ideally it's something like:

1. It can do encryption and decryption internally without ever exposing the keys.^[3]
2. It resists physical attacks to recover the keys. For instance it might erase them if you try to remove the casing from the HSM.

In order to actually encrypt or decrypt, you first unlock the HSM with the password, but that doesn't give you the keys, but just lets you use the HSM to do encryption and decryption. However, until you enter the password, it won't do anything.

The main function of the HSM is to limit the rate at which you can try passwords. This might happen by simply having a flat limit of X tries per second, or maybe it exponentially backs off the more passwords you try, or maybe it will only allow some small number of failures (10 is common) before it erases itself. If you've ever pulled your iPhone out of your pocket only to see "iPhone is disabled, try again in 5 minutes", that's the rate limiting mechanism in action. Whatever the technique, the idea is the same: prevent the attacker from quickly trying a large number of candidate passwords. With a properly designed rate limiting mechanism, you can get away with a much much shorter passwords. For instance, if you can only have 10 tries before the phone erases itself, then the attacker only has a 1/1000 chance of breaking a 4 digit PIN, let alone a 16 character password. Some HSMs can also do biometric authentication to unlock the encryption key, which is how features like TouchID and FaceID work.

So, having the encryption keys in an HSM is a big improvement to security and it doesn't require any change in the user interface -- you just type in your password -- which is great. What's not so great is that it's not always clear whether your device has a TPM or not. As a practical matter, new Apple devices do, as does the Google Pixel. The situation on Windows 10 is maybe but many modern devices will.

It needs to be said that an HSM isn't magic: iPhones store their keys in HSMs and it certainly makes it much harder to decrypt them, but there are also companies who sell technology for breaking into HSM-protected devices like iPhones (Cellebrite being probably the best known), but you're far better off with a device like this than you are without. And of course all bets are off if someone takes your device when it's unlocked. This is why it's a good idea to have your screen set to lock automatically after a fairly short time; obviously that's a lot more convenient if you have fingerprint or face ID.^[4]

Summary #

OK, so this has been a pretty long series, but I hope it's given you an appreciation for all the different settings in which passwords are used and where they are safe(r) versus unsafe.

As always, I can be reached at ekr-blog@mozilla.com if you have questions or comments.