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
I am in complete agreement with you. What’s more irritating is that unlock patterns rest on a 3×3 grid just like the rows of a numpad ( without the * 0 # keys ).
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.
“This is just the sort of choices users should have to make.”
…users should NOT have to make 🙂
Thanks for the read, it’s disapointing to see Android messing up somewhat something as important as full-disk encryption…
Also, your biking example is interesting but:
http://tech.slashdot.org/story/12/10/02/0111200/to-encourage-biking-lose-the-helmets
They really screwed this one up. Like one summer intern wrote it without much real-world testing.
The 16 character limit. Stupid.
Requires you to enter key twice upon cold boot. Stupid.
Same key for disk and lock. Extremely stupid.
Only encrypting /data. Well… not sure, yet.
And last a 70-90% disk r/w performance loss. Unacceptable.
4.2 Nexus 7 16 GB…
Yes it sounds really ridiculous. But I saw a app which changes the encryption password whit out the lock screen password (works only on rooted phones).
Is there a way to use the same encryption on the SD card as well? This data is vulnerable in my case…
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.
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.
You said:
Does it means that all my photos, evernote cache, dropbox folder and other file in /storage/sdcard0/* are unencrypted?
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.
Unfortunately my Galaxy Nexus hasn’t SD card.
What is the difference fast encryption and Full?
What about users Certs? where are they stored? and do they get 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.
Available on the market at
https://play.google.com/store/apps/details?id=com.kibab.android.EncPassChanger
Or direct from the developer at http://forum.xda-developers.com/showpost.php?p=27895353
Source at https://github.com/kibab/encpasschanger
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.
https://play.google.com/store/apps/details?id=org.nick.cryptfs.passwdmanager
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:
#!/system/bin/sh
sync;
setprop lk.filesystem.ready 1;
mount -o rw,remount auto /
mkdir /mnt/sd-ext
echo ChangeMe | lm.cryptsetup luksOpen /dev/block/mmcblk1p2 sd-ext
mount -o rw,nosuid,nodev,noatime,nodiratime -t ext4 /dev/mapper/sd-ext /mnt/sd-ext/
ln -s /mnt/sd-ext /sd-ext
mount -o ro,remount auto /
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.
Lastly, on cyanogen mod 9.1, /data encryption does require a hack, see comment 21: http://code.google.com/p/cyanogenmod/issues/detail?id=5678
Android Full Disk Encryption
Apparently it’s really much worse than that…the password is stored on the disk… read:
https://hashcat.net/forum/thread-2270.html
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.
TWRP recovery can mount (dm-)encrypted partitions. try to find a release for your device.
the encrytion Mode is aes-cbc-essiv:sha256 and enforced with 128-bit keys[1], anyone thinks thats still enough with all the NSA revelations? :/
[1] http://www1.informatik.uni-erlangen.de/filepool/projects/armored/armored.slides.pdf page 5
It doesn’t have to be that hard. if you use Swipe and add your pasword: upper- and lowercase, numbers and some simbols can all be joined into one single swipe, like a kind of signature.
I can see one reason for having the same password for decryption and unlocking the device. It’s too make sure the you don’t forget the password you enter at boot.
The risk is otherwise that months go by and when the device for some reason reboots, you have forgotten it.
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.