One of the new features touted by ICS is full-disk encryption (actually it was first available in Android 3). The first look is promising. The android developers went with dm-crypt as the underlying transparent disk encryption subsystem, which is the de-facto way to perform full-disk-encryption in Linux nowadays. This ensures both portability of the encrypted file systems and tried-and-tested implementation. The cipher itself is 128-bit AES in a ESSIV mode, and the encryption key is derived from the password using PBKDF2 (actually it’s the key that encrypts the actual encryption key, allowing fast password changes). So where do I think it went wrong?
The first thing that is irritating is that you can’t use the pattern screen lock. You must use either a password or a PIN. This may look unrelated, but maybe it’s due to the weird requirement that the encryption password should be the same as your screen lock’s password or PIN. This has several drawbacks
- Both passwords and PIN are limited to 16 characters. This practically means that you can’t use a passphrase. As the encryption is only as strong as the key, and remembering a strong password is way more difficult than remembering a strong passphrase, this leads to effectively weak passwords.
- Having to type your encryption password every time you want to unlock the screen, makes users even less likely to choose a strong password. Who wants to wait to type a long password full of letters, numbers and special characters every time he wants to unlock the phone?
- There is an increased chance that someone shoulder surfing while you unlock your screen will be able to crack you encryption password as well.
The main argument I see for setting the screen lock’s password and the encryption password the same is that having one of them entails having access to the data. While it’s correct that both passwords protect your data, they do it in a completely different scenario. The screen lock’s password only has to stand an online attack (brute-force). Even a relatively weak password, can withstand it, as the phone offers a severe rate-limit in case of entering a wrong password/pattern. At the same time, the full-disk-encryption offers protection against offline attack (e.g. someone took your phone, dumps the filesystem and now tries to access the data) which is much more powerful and can be done using lots of computing power. This means the encryption password faces tougher challenges, hence has to be stronger than the screen lock’s. Even if my analysis is incorrect, why force the two passwords to be different? Even if you require having a password as a screen lock, it could be different from the encryption password nonetheless.
Another design choice that make me wonder is the decision to encrypt only the
/data filesystem. While this is where most-apps keep their data, there is plenty of other places where user data is kept (such as on the SD card). Encrypting everything (a real full-disk-encryption) doesn’t present a hassle either. As the developers chose to rely on dm-crypt and LUKS, means that the encrypted filesystems are portable and can be mounted on any operating system (yes even on Windows). And when accessing the files via the phone (when connected using a usb cable) this can be done completely transparent by the phone itself.
Encryption is the sort of things that should be easy to use, as it’s the only way it will be used by most people and protect them. SSL is a great example, many people may do just fine without SSL, but it helps them be much more protected at very small cost (in terms of usability, just like wearing protective gear when riding a motorcycle). Android’s encryption fails this, it’s design required the user either to cripple it with a simple, weak, password, or face a degraded usability experience when using his phone. This is just the sort of choices users should have to make.
It’s easy to cry conspiracy here, but I rather believe it’s plain design flaws. Implementing a cryptosystem is harder than just picking up the right parts out of Applied Cryptography.
If you’re interested to read more about the technical details of Android’s encryption, I suggest reading Notes on the implementation of encryption in Android 3.0