Android 7.0 to Strictly Enforce Verified Boot

Google is planning new security features for the upcoming Android 7.0, including verified boot, which will prevent devices with a corrupt or modified boot image from booting.

Android already has verified boot for cryptographic integrity checking to detect modifications to the operating system, but Android 7.0 will now require the feature to be strictly enforced, Sami Tolvanen, Software Engineer at Google, says. Thus, the device won’t boot if the boot image or verified partition is corrupt, or will boot with limited capacity with user consent, Tolvanen says.

“Such strict checking, though, means that non-malicious data corruption, which previously would be less visible, could now start affecting process functionality more,” the engineer explains.

Android uses the dm-verity kernel driver to verify large partitions and does so by dividing the partition into 4 KiB blocks, which are checked against a signed hash tree. Should a single byte be corrupted, the entire block becomes inaccessible when dm-verity is in enforcing mode, and the kernel returns EIO errors to userspace on verified partition data access.

Android 7.0, however, comes with improved dm-verity robustness, courtesy of forward error correction (FEC), and is also more resistant to data corruption. FEC allows for the detection and correction of errors in source data, Google’s engineer explains. In the upcoming Android release, dm-verity uses interleaving to recover from a loss of several 4 KiB source blocks, Tolvanen says.  

Combined with the integrity verification performed by dm-verity, interleaving makes it possible to detect exactly where the errors are in each code. Thus, since each byte of the code covers a different source block, the integrity of each block can be verified using the existing dm-verity metadata, revealing which of the bytes contain errors.

The downside of interleaving is that the decoding is slower, mainly because it isn’t used for reading a single block, but multiple blocks spread across the partition. However, Tolvanen notes that this is not an issue when dm-verity and solid-state storage are considered, because the system only needs to decode if a block is actually corrupted, which rarely happens.

“Strictly enforced verified boot improves security, but can also reduce reliability by increasing the impact of disk corruption that may occur on devices due to software bugs or hardware issues,” Google’s engineer notes.

Courtesy of this new error correction feature for dm-verity, however, devices should be able to recover from the loss of up to 16-24 MiB of consecutive blocks anywhere on a typical 2-3 GiB system partition, Tolvanen says. The recovery needs only 0.8% space overhead and has no impact on performance, unless corruption is detected.

 While the security enhancement is meant for all devices running Android 7.0, the overwhelming majority of devices don’t have the latest security patches installed. Running over 400 million Android security scans daily, Google last month announced that it would pay up to $50,000 in bug bounties to researchers who discover vulnerabilities in TrustZone or Verified Boot.

Last year, Google requested manufacturers to enable full-disk encryption out-of-the-box for new Android 6.0 devices.