With each new Android release, Google adds more security features to harden Android. Two security features in Android 4.4 KitKat are particularly notable because they are Linux kernel developments. Security-enhanced Linux (SELinux) policies are fully enabled in KitKat, and dm-verity was added. Both features improve the integrity and trust of the Android operating system.
This builds on Google's earlier work to tighten Android’s defenses against attackers, such as full-disk encryption (dm-crypt) added to Android 3.x and Address Space Layout Randomization added in Android 4.1.
SELinux policies that were first tested in Jelly Bean are fully enabled in KitKat. A policy limits a program’s use of files, privileges, resources and interaction with other apps and libraries. Consider, for example, an exploit that inserts malicious code into one of Android’s system functions that is designed to misappropriate user data and send it via the internet to the perpetrator. If the system function’s use of the internet is not configured as an SELinux policy, the exploit might run, but it will fail without internet access.
Dm-verity is an important feature because, if implemented by the OEM, it will verify the integrity of the Android operating system that was loaded. This verified boot is a concatenated chain of trust that begins with the bootloader. The bootloader is secured to the device with a read-only public key burned into the device by the OEM. Using this key, a ROM-based function also supplied by the OEM will check the digital signature of the bootloader to confirm its integrity from changes or updates by an unauthorized source. The bootloader initiates the Android kernel and an OEM-provided function verifies the integrity of the kernel by comparing the read-only key to the kernel digital signature. The next link in the chain, the root file system, is loaded and its integrity checked by dm-verity, which then checks each Android system component loaded against a set of hashes to verify them. Instead of using one hash for all the system files, a set of generated hashes are used to check them individually in 4K increments to improve performance. If an exception is not encountered, the Android boot is verified. The process is like a trusted friend introducing two other trusted friends in a network of trusted friends until all the friends have been introduced by a trusted friend.
The chain of trust created in each step of the verified boot is not magic. This trust is dependent on people, hardware and software. An enterprise choosing to trust the verified boot has to trust that the OEM’s method for generating and burning the device key is secure, that it has not been divulged to a third party, and that the OEM-supplied methods for checking the integrity of the bootloader and kernel have been implemented properly. Finally, the enterprise needs to trust dm-verify, which is much less of a risk than trusting the integrity check of the boot process up to the point of the kernel load. The kernel that includes dm-verify can be trusted because the source code is published.
To put this in context: last month, Android security chief Adrian Ludwig presented a paper at the Virus Bulletin Conference in Berlin that reported that, in a study of 1.5 billion app installs, malware causes harm or evades runtime defenses in less than 0.001% cases. These are pretty good odds for the average consumer. But when an enterprise’s mobile devices are high-value targets of nation-state espionage or criminal exploits, 0.001% will be too great a risk. KitKat running on an appropriately designed device could be a solution.
The most likely early adopters of the new Android security features are OEMs that build mobile devices for governments and enterprises. The end customers that face significant security risks will pay the added cost to create the chain of trust between manufacturer and end users.
This technology doesn’t make Google a pioneer. Millions of SELinux computers in security-sensitive situations have demonstrated that Google’s approach is feasible. Google is a pioneer, however, in implementing this at the larger scale of mobile devices. The challenge for the enterprise at this early stage will be to identify a hardware OEM that can be trusted end-to-end to design, manufacture and deliver mobile devices without negligently or willfully introducing a broken link in the chain of trust. U.S.-based, Google-owned Motorola would be a good candidate if it chose to supply this type of device.