Android disk encryption implementation
Android 3.0 introduced disk encryption along with device administrator policies that can enforce it, and advertised it as one of several 'enhancements for the enterprise'. Of course Honeycomb tablets never really took off, let alone in the enterprise. Disk encryption however persevered and has been available in all subsequent versions. Now that ICS is on about 16% of all Android devices and Jelly Bean's share will start to increase as well in the coming months, disk encryption might finally see wider adoption.Unlike most internal Android features, disk encryption has actually been publicly documented quite extensively, so if you are interested in the details, do read the implementation notes. We'll only give a short overview here, focusing on key and password management.
Android's disk encryption makes use of dm-crypt, which is now the standard disk encryption sybsystem in the Linux kernel.
dm-crypt maps an encrypted physical block device to a logical plain text one and all reads and writes to it are decrypted/encrypted transparently. The encryption mechanism used for the filesystem in Android is 128 AES with CBC and ESSIV:SHA256. The master key is encrypted with another 128 bit AES key, derived from a user-supplied password using 2000 rounds of PBKDF2 with a 128 bit random salt. The resulting encrypted master key and the salt used in the derivation process are stored, along with other metadata, in a footer structure at the end of the encrypted partition (last 16 Kbytes). This allows for changing the decryption password quickly, since the only thing that needs to be re-encrypted with the newly derived key is the master key (16 bytes).The user-mode part of disk encryption is implemented in the
cryptfs module of Android's volume daemon (vold). crypfs has commands for both creating and mounting an encrypted partition, as well as for verifying and changing the master key encryption password. Android system services communicate with cryptfs by sending commands to vold through a local socket, and it in turn sets system properties that describe the current state of the encryption or mount process. This results in a fairly complex boot procedure, described in detail in the implementation notes. We are however, more interested in how the encryption password is set and managed.Disk encryption password
When you first encrypt the device, you are asked to either confirm your device unlock PIN/password or set one if you haven't already, or are using the pattern screen lock. This password or PIN is then used to derive the master key encryption key, and you are required to enter it each time you boot the device, then once more to unlock the screen after it starts. As you can see from the screenshot below, Android doesn't have a dedicated setting to manage the encryption password once the device is encrypted: changing the screen lock password/PIN will also silently change the device encryption password.
This is most probably a usability-driven decision: most users would be confused by having to remember and enter two different passwords, at different times, and would probably quickly forget the less often used one (for disk encryption). While this design is good for usability, it effectively forces you to use a simple disk encryption password, since you have to enter it each time you unlock the device, usually dozens of times a day. No one would enter a complex password that many times, and thus most users opt for a simple numeric PIN. Additionally, passwords are limited to 16 characters, so using a passphrase is not an option.
So what's the problem with this? After all, to get to the data on the phone you need to guess the screen unlock password anyway, so why bother with a separate one for disk encryption? Because the two passwords protect your phone against two different types of attack. Most screen lock attacks would be online, brute force ones: essentially someone trying out different passwords on a running device after they get brief access to it. After a few unsuccessful attempts, Android will lock the screen for a few minutes (rate-limiting), then if more failed unlock attempts ensue, completely lock (requiring Google account authentication to unlock) or even wipe the device. Thus even a relatively short screen lock PIN offers adequate protection in most cases. Of course, if someone has physical access to the device or a disk image of it, they can extract password hashes and crack them offline without worrying about rate-limiting or device wiping. This in fact, is the scenario that full disk encryption is designed to protect from: once a device is stolen or confiscated for some reason, the attacker can either brute force the actual device, or copy its data and analyze it even after the device is returned or disposed of. As we mentioned in the previous section, the encrypted master key is stored on disk, and if the password used to derive its encryption key is based on a short numeric PIN, it can be brute forced in seconds, or at worst, minutes. This presentation by viaForensics details one such attack (slides 25-27) and shows that this is far from theoretical and can be achieved with readily available tools. A remote wipe solution could prevent this attack by deleting the master key, which only takes a second and renders the device useless, but this is often not an option, since the device might be offline or turned off.
Hopefully we've established that having a strong disk encryption password is a good idea, but how can we set one without making screen unlocking unusable?
Changing the disk encryption password
As we mentioned in the first section, Android services communicate with the
cryptfs module by sending it commands through a local socket. This is of course limited to system applications, but Android comes with a small utility command that can directly communicate with vold and can be used from a root shell. So as long as your phone is rooted, i.e., you have a SUID su binary installed, you can send the following cryptfs command to change the disk encryption password:$ su -c vdc cryptfs changepw newpass
su -c vdc cryptfs changepw newpass
200 0 0
This doesn't affect the screen unlock password/PIN in any way, and doesn't impose any limits on password length, so you are free to set a complex password or passphrase. The downside is that if you change the screen unlock password, the device encryption one will be automatically changed as well and you will need to repeat the procedure. This is not terribly difficult, but can be cumbersome, especially if you are on the go. You should definitely start this Android issue to have it integrated in Android's system UI (which will probably require extending the device policy as well), but in the meantime you can use my Cryptfs Password tool to easily change the device encryption password.
The app tries to make the process relatively foolproof by first checking your current password and then displaying the new one in a dialog if the change succeeds. However, you will only be required to use the new password at the next boot, so it is important not to forget it until then, and take a full backup just in case. Short of brute-forcing, the only way to recover from a forgotten encryption password is to factory reset the device, deleting all user data in the process, so proceed with caution. The app will verify that you have root access by checking if you have one of the more popular 'superuser' apps (Superuser or SuperSU) installed, and trying to execute a dummy command with
su at startup. If your device is not encrypted, it will refuse to start.The implementation is quite straightforward: it simply invokes the
verifypw and changepw cryptfs command using the passwords you provided. If you are interested in the details, or simply won't let a random app mess with your device encryption password, clone the code and build it yourself. If you are the more trusting kind, you can install via Google Play.Summary
While Android's disk encryption is a useful security feature without any (currently) know flaws, its biggest weakness is that it requires you to use the device unlock PIN or password to protect the disk encryption key. Since those are usually rather short, this opens to door to practical brute force attacks against encrypted volumes. Setting a separate, more complex disk encryption password using the provided tool (or the directly with the
vdc command) makes those attacks far less effective. This does currently require root access however, so you also need to make sure that your device is otherwise secured as well, mainly by relocking the bootloader, as described in this article.
Post a Comment