Android Device Security Now Pretty Good

Ever since I read Apple’s iOS Security white paper, I’ve been thinking if I should, well, switch to the dark side. Alright, I didn’t seriously think that, but I was quite envious. Apple seems to have done a really good job, particularly with device encryption and integrated fingerprint security. Google needed to catch up, quick. I think they finally have.

Google’s latest Nexus smartphones, the 5X and 6P, come with fingerprint sensors. Fingerprint sensor support is now baked into Android itself, not slapped on by independent smartphone manufacturers. It’s one thing, of course, to have the hardware and software, but it also has got to be implemented properly and securely. See how, for example, HTC was caught doing stupid things, storing fingerprint image unencrypted and world-readable.

We could all assume Google would do a much better job. But I’m a techie. I need to know, not so much with absolute certainty, but at least know enough to be convinced that Google really did do things correctly. I wrote about Google’s Nexus Imprint Fingerprint Security last month, based on some information that Google did share. It was a good start.

Fingerprints aside, a bit part about smartphone security is with device storage encryption. The basic idea is that you want the device storage to be secure, so that even if the device is stolen, your data within is safe from prying eyes. It must be good enough to defeat bypassing of software locks. It must even thwart attempts to retrieve the data by booting an alternative operating system, or by physically transferring the memory storage to another hardware.

iOS got this part, the device storage encryption, sorted out quite a while ago, and it’s what originally got me envious of it. Android began introducing device storage encryption since Lollipop, but reversed its original intent to mandate its use. As a result, Android manufacturers didn’t turn encryption on by default.

Now in Android 6.0 Marshmallow, Google stipulates that if the device supports a secure lock screen, and is not a low memory device, then it must support full disk encryption of the application private data partition (/data) and application shared storage partition (/sdcard), assuming the latter is a permanent, non-removable part of the device. Furthermore, such devices if capable of AES crypto performance above 50 MiB/sec, then it must enable encryption by default at the time the user has completed the out-of-box setup experience.

There’s other language to deal with upgraded devices and other scenarios. I won’t go into them. The main takeaway is that new Android smartphones ought to have good device storage encryption.

How good is this encryption? It looks to be pretty sound, in principle. All your data is encrypted at the storage level. In other words, the entire storage device, or more accurately, the storage partition, is encrypted.

Next, so if it’s been encrypted, then encrypted with what key? Where is the key stored? Is the key stored? Many dumb encryption systems do a fine job encrypting data, but make the fatal mistake of storing the encryption key somewhere, sometimes even beside the encrypted data. Some systems claim that the key is encrypted before storage, but now that begs the next question, what is that key encrypted with?

The thing is that many encryption systems store their keys either in plaintext, or what we’d call plaintext-equivalent. Maybe the key has simply been encoded, instead of truly encrypted. Maybe if they are encrypted, the encryption key is actually known, like buried in the software, or computed based on some hardware parameters. None of them are actually secure at all.

In the case of Android’s full disk encryption, a read through the Google’s Full Disk Encryption write up tells me it’s been properly designed. The Disk Encryption Key (DEK) which is used to encrypt the storage is never stored in plaintext or plaintext-equivalent. The DEK is stored encrypted by a key, known as the Key Encryption Key (or KEK), which is derived from the user’s password (or PIN or pattern) and a hardware bound private key.

The simplified chart below demonstrates the concept. Please note that it isn’t meant to be technically accurate.

(Correction: The 2nd KDF in the above chart should instead by a symmetric cipher, AES_CBC.)

I need to explain about the Hardware Bound Key (HBK). This is a key that has been programmed into secure hardware, known generally as the Trusted Execution Environment. It cannot be extracted from the hardware. The concept with the HBK is that the secure hardware will be given some input, sign it with a hardware-bound private key stored within, to produce an output that goes towards deriving the KEK.

In other words, the KEK is derived from both the user’s password and the HBK. The HBK is fixed to the hardware. The KEK is only known when the user provides the right password, only on the same hardware. If you don’t have the user password, then there is no way to find the KEK. If you know the user’s password, but don’t have the right HBK, such as if you somehow copied the raw bits off the memory storage hardware, you still cannot find the KEK.

You will notice that a user password is required for full disk encryption. This is basically your screen lock password. PINs and patterns work too. They are simply transformed into a manner that can be used as the password. Obviously, PINs and patterns are a lot less secure than passwords. Patterns, especially. Best to use passwords, otherwise, at least a really good long PIN. With fingerprint unlock on new Nexus devices, you don’t often need to type that PIN or password, so you don’t need to worry about them being inconvenient to enter.

Is Full Disk Encryption still possible if you did not set a password or any screen lock method? Yup. There is a default. The default password is default_password, just so that encryption can still go on. It’s not useless, since the KEK still depends on the DEK. Of course, if someone has stolen your entire device, then they have your data, which is the same anyway if there were no encryption.

There are a couple of other good reads about Android’s full disk encryption. Apart from Google’s own documentation mentioned earlier, you can also read Nikolay Elenkov’s Revisiting Android disk encryption, and this other paper on Analysis of Secure Key Storage Solutions on Android.

Android’s full disk encryption addresses the security of data storage, but it is not used for the operating system storage itself. How can you be assured that the operating system has not been tampered with? This is tackled in a different manner, through a feature known as Verified Boot.

Verified Boot is similarly mandated in the same manner as Full Disk Encryption. Verified Boot was first introduced in Android 4.4 KitKat, and its purpose is to establish a chain of trust starting from an immutable hardware key that is the root of trust, verifying each stage of the boot, including the bootloader, up to the operating system boot image. Each stage of verification is responsible to check the integrity and authenticity of all bytes in the next stage before executing the code in the next stage.

Just a quick recap on Google’s Nexus Imprint fingerprint security. Capturing and recognising your fingerprint happens in the device’s Trusted Execution Environment. Fingerprint images are inaccessible outside of the sensor hardware or trusted memory. Only the encrypted form of fingerprint data is stored in the device storage, even if that storage is already itself encrypted. It’s pretty good.

Now, don’t get me wrong. There’s still malware, zero-day exploits, and other ways to break your phone. But I’m happy that Android is now provided with good security features. Verified Boot establishes the authenticity of system software. Full Disk Encryption protects your data. Nexus Imprint handles your fingerprint data securely.