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 (ADLR) and Data Execution Protection (DEP) 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.
Sign up for CIO Asia eNewsletters.