Understanding Disk Encryption on Android and iOS

Introduction

Mobile devices these days handle lots of sensitive information – messages, photos, contacts and more. The question about how this data is stored on the device will obviously arise, especially since mobile devices are more prone to theft. In this article, we will explore why data on a device needs to be encrypted and how it is done with respect to different platforms such as Android and iOS.

Screen lock is never a savior!

Never assume that the screen lock you configured on your phone is going to prevent an attacker from getting access to the data present on the device. Screen lock can be seen as a lock on a door - without the key, people cannot normally come in and access the 'belongings' (data in this case). But if a thief somehow comes in, he can happily access all the belongings, for example by reading the data directly off the memory chip. So the simple point is that even with screen lock turned ON, a skillful hacker can still get access to data sitting on the device. This is where encryption comes into picture. Encryption makes the information unreadable even if an attacker somehow manages to access the data.

Please note that disk encryption only protects your phone when it is turned off (i.e., it protects data at rest). Once the device is turned on, data will obviously be decrypted, as it needs to be used.

How to turn it on

Android's encryption feature is disabled by default. Google does not allow pattern-locks and face recognition in combination with disk encryption. After ensuring that the device has a PIN or password, navigate to 'Settings' > 'Security' > 'Encrypt phone'.

A warning message is displayed, and then it will take at least an hour to complete.

How Android encryption works

In Android, full disk encryption was introduced in the Honeycomb version and didn't change much until recent Kit Kat version. Although it is named FDE (full disk encryption), Android encrypts only user partitions, not the full disk. Any encryption scheme has two important items – algorithm & key. Now let us see some of the important points about how Android 3.0 encrypts its data on the device.

• We know that Android is built with a Linux kernel and so it rightly uses dm-crypt to implement disk encryption for the userdata (present under /data partition). dm-crypt supports different ciphers.
• Based on the user entered PIN/Passcode, AES-128 Key Encryption Key (KEK) is calculated. This KEK is again used to encrypt the Disk Encryption Key (DEK) ('master key'). Thus there are two encryption keys which are mainly dependent on the user entered PIN/Passcode.
• So when the device is booted, this is what happens: Android takes the passphrase the user has entered, runs it through PBKDF2, decrypts the 'master key' (DEK) and passes it to dm-crypt in order to mount the encrypted userdata partition.
• Encryption parameters are stored in something called 'crypto footer'. This is located in the metadata in most of the devices.

Practically speaking, the security of this entire story depends on the passphrase the user sets. If it is very long, it makes brute forcing difficult. But most people would set a 4 digit PIN, because who would want to enter a 16 digit password with alphabets and special characters every time you want to make a call or send a message? This actually makes brute forcing it very easy. Brute forcing on the device is impractical, as there a time limiting factor upon unsuccessful attempts. Hence to brute force, we will have to obtain a copy of the 'crypto footer' and the encrypted userdata partition. After this, the passphrase can be guessed offline by brute forcing. Of course, this involves advanced stuff such as booting a recovery image, etc., because obtaining a raw copy is not directly possible. A 4 digit PIN can be cracked using normal tools and a CPU in a few minutes. Hence it's important to have a pretty strong password if you really do not want your disk encryption to be cracked.

Whatever we have seen above, it's with respect to Android 3.0. Coming to Android 4.4, there is one big improvement - replacing the PBKDF2 key derivation function (discussed above) with 'scrypt'. Scrypt is hard to crack and is very much slower compared to PBKDF2. It's not impossible to crack, but it is certainly slow compared to the previous Android 3.0 case.

How is it going to change in Android L?

Android L is the next coming version of Android. Here are some of the key points.

1. Full disk encryption is enabled by default!
2. Encrypting a device no longer requires setting a lock screen PIN or password, which suggests that the KEK is no longer directly derived from the lock screen password.
3. At the time of writing, no announcement was made regarding the hardware encryption keys, but it is expected that this version would have hardware protection for encryption keys.

If the encryption is enabled by default, it would prevent both hackers and law enforcement agencies from accessing the information on the device. Now this is something similar to the way iPhone handles disk encryption.

How Apple's encryption works on mobile iOS

Apple was a front runner in implementing some sort of encryption long before others even thought about it. Apple uses a 256-bit device-unique secret key (UID) stored in the phone's hardware, where it's hard to extract from. Apple says this UID is unique to the device and it doesn't store these values. It also says that no software or hardware can read this key. This UID is mixed with the passcode to generate a new key (passcode key) to secure data on the device. Unlike Android, this UID key can't be extracted from the device, so all the brute forcing attempts have to be done on the device itself.

As per Apple, the content of a file is encrypted with a per-file key, which is wrapped with a class key and stored in a file's metadata, which is in turn encrypted with the file system key. The class key is protected with the hardware UID and, for some classes, the user's passcode. Here is a screenshot of the whole process. The new iOS 8 has only extended this feature to more items which are previously not encrypted – messages, pictures, etc.

Both the new improvement in Android and iOS disk encryption will result in making life tough not only for hackers but also for law enforcement agencies. While some argue that users holding keys to their information is absolutely a good move, others say this would prevent government agencies with legal warrants from doing their job.