Keeping track of what I do

Some Thoughts About Android’s Full Disk Encryption

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?

Enabling the full disk encryption.

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 full disk encryption can’t be set with a pattern lock-screen.

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.

You’re right, it even gets more ridiculous as you consider bigger and bigger screen sizes for phones or even tablets. Why should the pattern on a Galaxy Note be limited in the same way as in some 3 inch entry-level phone?

It’s looks like it’s all part of providing security as an afterthought and not as a main goal.

Every point you make is completely justified and your arguments are invalid. If you used a pattern someone can just as easily shoulder suff that instead of a password and its actually simpler to do so. If you didn’t use a password to unlock the screen whats the point in encrypting it in the first place since they would have access to all your information if they can unlock the screen,that is the point!

The only valid point you make here is the 16 char limit and that using a phrase is more secure then a password. However a 16 bit password is pretty secure and extremely difficult for someone to guess or try and hack out with existing hardware.

If you used a pattern someone can just as easily shoulder suff that instead of a password and its actually simpler to do… If you didn’t use a password to unlock the screen whats the point in encrypting it in the first place

I didn’t suggest using no password/pattern for the unlock screen. What I do suggest is using a different one. One has to remember that the unlock screen and the encryption keys face different threats and usage patterns. While the former is used much more often, it faces only a online-attack scenario, which your phone makes almost impossible to do even for comparatively weak passwords .The latter on the other hand, faces an offline attack, which is much stronger and faster, hence it really requires strong keys with enough entropy, but those keys only have to be entered upon boot.

Ergo, as I explained the the post, there is no real reason to require both keys to be the same. It forces users to use weak keys for the encryption or face considerable annoyance when unlocking the phone.

I do agree with you that having no unlock password/pattern is stupid.

You are right that 16 byte password can be strong enough. Ultimately it would have 128 bits of entropy.

But taking into account that the password needs to be used for every unlock, it extremely inconvenient to use any char not directly on the keyboard (requires long-presses etc, not mentioning unprintable ones). Typing into a password field 16 for every unlock, is tedious and most likely if you actually use your phone, you would not have such a long password, resoting to something around 10 chars max, yielding 60 bit password.

While 60 bit password is still strong for an online attack on the phone, it’s feasible for a determined attacker performing an offline attack.

Good security walks the fine line between usability and actual security. Separating the keys would have resulted in fair usability and strong security. Requiring them to be the same resulted in either strong security and almost zero usability or fair usability and weak security. How did the separation of offline and online attacks threats was missed by the engineer who designed this system puzzles me.

As I understand it, the specification only calls for encrypting /data. Encrypting other parts of the filesystem will require different mechanisms, as external storage can be swapped hence you can’t rely on it having the same encryption key as the internal storage.

You can easily check whether the SD card is encrypted by trying to access it directly via a PC or another device. My guess you’ll succeed, ergo the SD card isn’t encrypted.

I use EncPassChanger which allows you to change the disk encryption password independently of any screen unlock password. It requires root as far as I’m aware, and calls functions from the Android Volume Manager to reset the password.

Regarding screenlock PIN/Password being the same as cryptfs /data: There’s an app to allow changing the password for /data. Useful if you want say a 4 digit pin for easy unlock of screen, but a more robust, and different password for /data.

I am also quite dismayed with Android’s decision to only encrypt the /data partition.

For those who are adventurous, the SD Card (or partition on) can be encrypted in full, though some familiarity with LUKS is highly advisable. I used Clockwork Recovery to create three partitions on my SD Card: Fat32, Ext4, Swap. For the moment, I left Fat32 unencrypted, to allow that remaining accessible via USB. The Ext4 partition, I accessed under Fedora, via gnome-disk-utility, deleting the partition, and recreating at encrypted.

Remounting this now encrypted partition under Android did present a bit of a challenge. I had to install LUKS Mananger, which provides lm.cryptsetup. Disregard the rest of LUKS Manager for the moment, as though useful for virtual folders, it doesn’t address a full partition.

I then created the following script at /system/etc/init.d/99sd-extLUKSinit:

The script automounts the second partition on my SD Card at /mnt/sd-ext, with a sym link at /sd-ext. My SD location may differ, so try “cat /sys/block/mmcblk1-9/device/type” until you get a return of SD.

Actually it’s not as bad as you’re making it. You’re password encrypts (using a key derived from it) the header which contains the encryption key for the entire disk (this isn’t directly the encryption key, but you use it to derive sector keys, but I don’t won’t to dive into full-disk-encryption theory).

A malicious user can’t just read the encryption key from the disk, as he needs to decrypt it first using you’re password. This also allows you to change your password without re-encrypting the entire disk which would take a long time, as only the header needs to be re-encrypted.

This is a very solid design, which is part LUKS, and similar usage of encryption key inside the encrypted header can also be found in TrueCrypt and any other decent full disk encryption software.

I think a full disk encryption would make it harder to make a system update. Because you need to have write access to the system partitions at boot time and with most recovery systems you do not have dm-crypt support.

Which leads my to my question. I use Cyanogendmod and would like to encrypt my device. But I want to be able to make system backups in the future. The recovery tool that comes with Cyanogendmod is Clockworkmod and it does not support encryption. This means Clockworkmod cannot make a full backup of encrypted devices.

I know, you could use Titanium backup and stuff, but, to restore a backup made with these tools necessitates a running system. But this is exactly what you do not have after you bricked your phone.

Whereas Clockworkmod makes perfect system backups of un-encrypted devices, you can easily restore your full system after a crash and no need to install a new system before restoring your data.

After all, it is a big mess for people using device encryption to get a nice, clean full system backup that is easy to restore after a crash.

In my oppinion, using dm-crypt was a mistake. They should have chosen EncFS, that would have made system backups of encrypted devices much easier.

It seems Fast encryption will only be used to encrypt the memory space used in the device which might mean that if you delete something, those part of memory are unencrypted, and can be recovered using advance tools.