Encryption has been a rather topical subject over the course of the last 12 months. What started with the San Bernardino shooting in late 2015 and Apple’s refusal to help the FBI unlock an iPhone 5C recovered from one of the shooters turned into a fully blown debate on cryptography, user privacy, and the Fourth Amendment. Given Google’s support of Apple in this discussion, as well as the fact that a majority of Android users worldwide were still running an unencrypted version of Android at that time (and still are), the latest version of Google’s OS came under scrutiny from the cryptographic community the moment it became available in March.
Unlike its predecessor, Android 7.0 Nougat features support for file-based encryption (FBE). Remember when Marshmallow made disk encryption mandatory? That only pertained to full disk encryption (FDE). The difference between the two is relatively straightforward. A standard disk encryption system works in a manner which requires you to enter a password upon boot. This password is then processed by a key derivation function which comes up with a cryptographic key. For added safety, a physical co-processor may be able to base the key derivation function on some hardware-specific features, introducing an additional, local level of cryptographic security. As for the encryption itself, it can either be approached in a universal or a highly precise manner. The former results in full disk encryption while the latter pertains to file-based encryption. FDE encrypts disks at a disk sector level. Encrypting a drive in this way means you’re using a single key, so the entire process is fast and easy to implement. FBE encrypts disks at a file level. This approach encrypts disks with multiple keys and isn’t as quick or easy to execute. On the bright side, this accelerates decryption because FBE allows individual files with different keys to be unlocked separately.
As FDE is cheaper and quicker to accomplish, PC encryption software developers have historically gravitated towards it. In the context of personal computers, that approach made sense. If you have a laptop and it gets stolen, you don’t have to worry about your data because it’s encrypted. However, when it comes to phones, the issue is more complicated because users aren’t encouraged to ever power down their phones. In other words, no FDE encryption in the world will help you when you boot your device, fully decrypt it, and never power it down again. In theory, it’s possible to evict cryptographic keys from RAM every time a user locks their device, but that would de facto make the phone unresponsive, as explained by Matthew Green, a cryptographic expert and a professor at Johns Hopkins University. In other words, if your phone gets stolen while it still has some battery power left, the fact that it’s still sporting cryptographic keys in its RAM means encryption is likely a non-issue for your attacker.
To address these problems, Android has started adopting FBE which Apple has been using since iOS 4 as FBE allows fine-grained access control for accessing individual files. However, as Green points out, Android currently offers developers only two protection classes whereas Apple boasts four. The two missing classes are precisely the ones mentioned above, the ones that order your device to evict encryption keys from RAM. The so-called “complete” protection classes are of crucial importance when it comes to enabling a higher level of cryptographic security in Android smartphones, and due to a number of technical limitations in how Android currently works, Google is still nowhere near developing them. Consequently, Android developers cannot build apps which “understand” the idea of a locked device which evicts some or all of its cryptographic keys from RAM. To make matters even worse, as this problem hasn’t been addressed for years, even if Google somehow magically implements complete protection classes today, millions of existing apps using security measures Google is currently recommending will stop working as their attempts to access files will be returning errors.
While this is certainly bad, Green points out that Android is obviously moving in the right direction and it’s only a matter of time before it manages to implement the said lock screen security. Nonetheless, even the biggest Google supporters can’t deny the fact that after years of development, the Mountain View-based tech giant still hasn’t figured out a reliable and secure encryption method which doesn’t diminish the overall user experience. That’s the gist of it, but if you’re interested in all the technical details behind Android Nougat encryption limitations, check out Green’s latest piece by following the link below.