While the phone was once used only to make and receive calls, it has now become a central part of the daily activities of all users who use it to surf the Internet, chat and even to pay, or at least, to make online transactions. Matthew Green, a cryptographer and professor at Johns Hopkins University, outlined the general characteristics of encryption and analyzed the protection systems adopted by iOS and Android. And Google came out with broken bones. Nougat, the latest version of Mountain View's system, has improved in this respect, but there is still a lot of work to be done.
The basics of encryption
Hard disk encryption is, of course, much "older" than smartphone encryption and can - currently - be done in two different ways:
- Full Disk Encryption (FDE) is a system - like Truecrypt, BitLocker and FileVault - that encrypts disks at the sector level. It's an all-or-nothing approach, since the encryption drivers don't necessarily have any idea what files are contained in the various sectors. FDE, by the way, is widely used mainly precisely because it is extremely easy to implement.
- File-based Encryption (FBE), on the other hand, is a system - like EncFS and eCryptFS - that encrypts files individually. It's a more complicated approach because it requires you to make changes to the filesystem, but one that offers more versatile access control in which multiple files of different natures are encrypted using different keys.
It goes without saying that Full Disk Encryption, precisely because it's simpler to implement, is currently the most widely used solution in the hard disk industry.
What does all this have to do with Android?
Simple, because Android's first attempts to add encryption to its smartphones followed the technology behind Full Disk Encryption (FDE). Android systems - starting with Android 4.4 (KitKat) and ending with Android 6.0 (Marshmallow) - leveraged a solution based on a kernel - called dm-crypt - designed to encrypt disks at the sector level. It was a simple - and especially quick - attempt to solve the problem, convinced that smartphones were, in the end, miniature computers. Nothing could be further from the truth, explains Matthew Green: the problem is that smartphones are not computers!
The main difference is that cell phone users are encouraged to keep their device switched on all the time. This means that - by entering a password once after logging in - people spend the entire day with all the encryption keys stored in the smartphone's RAM. And since batteries last for the whole day, sometimes even longer, encryption does not - in this way - offer effective protection against possible attacks if some malicious person - with the right skills - manages to get his hands on it in that time frame. It is true that many users are in the habit of locking their smartphones. A good solution if implemented could, in principle, delete the most important encryption keys when the phone is locked, and then restore them when you log in again. Android, unfortunately, does not do this because Android users want the phone to work without interruption and without the encryption keys in the RAM memory, the FDE (Full Disk Encryption) system would prevent access to all data stored on the disk making it unusable. Once you boot an Android phone with FDE technology, for this very reason, it will never erase its encryption keys from RAM. And, according to the cryptographer, that's not a good solution.
What's the alternative? Apple!
Android isn't the only "player" when it comes to smartphone encryption. There's also Apple. The Cupertino-based giant has also thought long and hard about this thorny issue, arriving at a slightly different solution. To a different approach. Apple - starting with iOS 4 - introduced a data protection feature that encrypts all content on the device. Apple didn't go with the option of encrypting the entire sector disk (FDE), but instead turned to encrypting individual files (FBE). The iOS system encrypts the content of each individual file with a single key and each key is, in turn, encrypted with one of several "class keys" generated from the password used by the user and some hardware "tools" in the processor. The main advantage of the approach chosen by Apple is that, instead of using a single password (FDE) that manages everything, the Cupertino company provides developers with APIs (Application Programming Interfaces) - i.e. a set of procedures to perform a certain operation within a specific application - that allows them to specify the type of key class to be used for a given file. Apple provides the following "protection classes":
Full protection: files encrypted with this key class are accessible only when the device is turned on and unlocked. The key class is removed from RAM, but only for a few seconds after the device is locked.
Protection until first user authentication: files encrypted with this key class are protected until the first user login - and after a reboot - and then remain in memory.
No protection: these files are accessible even when the device has been restarted, and the user has not yet logged in.
Apple, by providing programmers with the ability to protect individual files, has made it possible to develop applications that can run even when the device is locked while providing protection to files that contain sensitive data. The Cupertino giant, moreover, has also provided a fourth option for apps that simply need to create new encrypted files when the keys are removed from RAM. It's a class, in short, that has the sole task of providing new keys: this is why, for example, in iOS you can take a photo even when the device is locked. Even Apple's approach is not perfect, however, it is clear that it is the result of a long and thoughtful study. The question is why hasn't Android also followed the same approach?
Android looking for a solution
Google, in fact, is looking for a solution to provide greater security for its devices, but it started late and on the wrong "foot", and is scrambling to catch up. Android - starting with Nougat version 7.0 - has abandoned full disk encryption as its primary mechanism for protecting data "at rest." Android N systems, if you set a login password on the device, can be configured to support an approach much more similar to Apple's that uses file-level encryption. And so far, so good. The new system - called Direct Boot - thus replaces the FDE used until previous releases. The main advantage of this "change of course" allows smartphones to access certain data even before entering a password. This has been made possible by providing developers with two different "encryption contexts":
Encrypted Credential Storage: files in this area are encrypted using the password entered by the user and will not be available until this is done, at least once.
Encrypted Device Storage: files are not encrypted using the user's password, although they could be encrypted using hardware-level tools. The data is, thus, available after boot, even before the user types in a password.
Direct Boot, in short, provides two separate options for different phone users although, cryptographer Matthew Green again explains, the reason for this is unclear. But, he says, "why not?"
If Android is "catching up," what's the problem?"
If you've followed the big picture so far, you may have noticed one detail: Apple offers four categories of protection, while Android Nougat offers only two. And the problem is precisely these two missing categories that allow users to lock their devices after the first authentication and delete keys from memory. It's important to point out that the real problem with Android is not so much encryption, but rather that Google doesn't offer developers proper guidelines, leaving the issue of securing their devices half-baked. Android, without a solution that defines a "complete" protection class, does not allow programmers to properly develop applications so that devices can really be - at the same time - locked and working. All of this talk leads to the classic "bottom line": Apple, even with an improvable system, is six years ahead of Android in the area of encryption.