Google Taking Aim at Device Modders in Android 4.4 KitKat
Android 4.4 introduces a number of changes intended to reduce the risks of rootkits on the platform. In addition to SELinux, the dm-verity kernel feature is also used on boot. The dm-verity feature is used to verify the filesystem storage, and detect modifications to the device at block level (rather than file level). In essence, dm-verity aims to prevent root software from modifying the device file system. This is done by detecting the modifications made to the filesystem, which will no longer match the expected configuration.
In dm-verity, each block of the storage device has a SHA-256 hash associated with it. (For reference, a block is simply a unit of address for storage, typically around 4 KB on flash devices.) A tree of hashes is formed across pages, such that only the “top” hash in the tree (known as the root hash) needs to be trusted, in order for the entire filesystem to be trusted. If any block is modified, this will change the hash, breaking the chain.
The boot partition of the device will contain a public key, which the OEM is expected to externally verify (perhaps via the bootloader or low-level CPU features). This public key is used to ensure the signature of the hash on the file system is valid and unmodified.
In order to reduce the time taken to verify the filesystem, blocks are only verified when they are accessed, and are verified in parallel with the regular read operation (to essentially eliminate any latency with accessing the storage). If the verification changes (i.e. files have changed on the system partition), then a read error is generated. Depending on the application accessing the data, it may proceed if it’s not a critical action, but it is also possible for applications to decline to operate under these conditions.
While nobody can predict the future with 100% accuracy, I think it’s fair to say that “rooting” and modifying devices running Android 4.4 with locked bootloaders (i.e. where root exploits are required, as the OEM will not permit custom kernels) may well be considerably more difficult than in previous Android versions. It seems that Android 4.4 is taking a few leaves out of the Chrome OS book, as these changes essentially implement “verified boot,” as found on Chrome OS.
To re-iterate, if you are able to change the kernel your device uses, this feature will not be a concern. It’s possible to either disable dm-verity in the kernel, or to set it up to use your own keys to authenticate the system hash. For users who choose to buy carrier-branded devices and accept a locked bootloader, but find a way to root the device, take heed of this warning. It’s not at all unlikely (in my technical opinion) for this to happen on future devices. If you want the ability to modify the software on your phone, I’d avoid anything with a locked bootloader, and ensure you can modify the kernel (to disable or modify the dm-verity signatures).
Right now, little is known about what this will actually mean, but aside from greater security for users on stock ROMs, I suspect there will be some noticeable impact on casual users wishing to make small changes to Android. Until we see devices from other OEMs shipping with 4.4, it’s difficult to really assess how (or if) this will change things. But take note, and bear it in mind.