If you have been following the developments in Android, you must have heard the name “Verified Boot” quite a bit in the last couple of years. Google introduced the security feature in Android 4.4 (Kitkat), in a thoroughly non-intrusive way, and has slowly been increasing its visibility in the newer releases of its Android Operating System.
In the past couple of days, we have seen news about the presence of a “Strictly Enforced Verified Boot” in Google’s latest iteration of the world’s most used mobile OS. Android Nougat will use a higher level of security checking when your device boots up. While, on Marshmallow, Verified Boot only gave the user a warning, in case it detected something amiss with the system partition, Android Nougat will take it one step further, and use what Google is calling a “Strictly Enforced Verified Boot”, which will not allow the device to boot up at all, in case it detects anomalies in the partition, changes made to the bootloader, or the presence of “malicious” code in the device. This begs the question: “What exactly does this mean for the users?”, turns out, the answer differs for the two main categories of Android users (casual and power users), and we are going to provide the answer for both of them.
Strictly Enforced Verified Boot
First, a little background on Verified Boot: Typically, when Android runs a verification test on partitions, it does so by dividing the partitions into 4KiB blocks and checking them against a signed table. If everything checks out, it means that the system is completely clean. However, if some blocks come out to be tampered with, or corrupt, Android informs the user about the issues and leaves it up to the user to solve it (or not).
All that is about to change with Android Nougat, and Strictly Enforced Verified Boot. When Verified Boot runs in Enforced mode, it will not tolerate any faults in the partitions. If it does detect any issues, it will not allow the device to boot up, and might allow the user to boot into a safe-mode environment, to try and correct the issues. However, Strictly Enforced Verified Boot is not just a check against bad data blocks. It can usually correct errors in data blocks, as well. This is made possible by the presence of Forward Error Correcting codes, that can be used to correct errors in data blocks. However, this can’t always work, and in cases when it doesn’t, you’re pretty much dead in the water.
Strictly Enforced Verified Boot: The Good, The Bad and The Ugly
1. The Good
Enforcing Verified Boot on Android devices will enhance security on the devices. In case the device gets infected by malware, Strictly Enforced Verified Boot will detect it the next time you boot up your device, and either fix it, or quite possibly prompt you to do something about it.
This feature will also check for data corruption, and in most cases, it will be able to correct any errors introduced in the data, thanks to the FEC codes. Google uses FEC codes that can correct one unknown bit error in 255 bits. Sure, that seems like a pretty small number, but let’s put that in perspective, with regards to a mobile device:
Note: The values below are taken from the blog post by Google Engineer Sami Tolvanen on Android Developers.
Google could’ve used RS(255,223) FEC codes: these codes would’ve been able to correct 16 unknown bit errors in 255 bits, but the space overhead because of the 32 bits of redundant data, would’ve been almost 15%, and that is a lot, especially on mobile devices. Add that to the fact that Android is the predominant OS on budget smartphones that ship with 4-8 GB memories, and 15% extra space sure seems like a lot.
By sacrificing error correcting capabilities, in favour of saving space, Google decided to use RS(255,253) FEC codes. These codes can correct only a single unknown error in 255 bits, but the space overhead is only 0.8%.
Note: RS(255,N) is a representation of Reed-Solomon codes, which are a type of error correcting codes.
2. The Bad
Ever heard of “There are two sides to a coin”? Of-course you have. While Google’s intentions with Strictly Enforced Verified Boot were no doubt pure as a baby unicorn, they do come with their own set of problems.
When Strictly Enforced Verified Boot checks for malware, it also checks for illegal modifications to the kernel, the bootloader and other stuff that I will not bore you with, but, this means that Android Nougat will probably encounter a lot of issues with rooting, and flashing Custom ROMs, because Verified Boot can not distinguish between unwanted malware code, and the code that unlocked your bootloader. Which means, that if your device came with a locked bootloader, and your OEM does not allow bootloader unlocking, you pretty much can’t do it. Hopefully, some one will figure out an exploit for this.
Thankfully, most people who root their devices, and flash Custom ROMs for the added features and functionality, go with developer friendly phones, such as the Nexus. There’s a lot to consider, regarding this topic, and it’s definitely not the end of Custom ROMs, at least not on devices that come with an unlocked bootloader, or that allow unlocking the bootloader. However, devices like Samsung phones do not officially allow bootloader unlocking, and on these devices, unlocking your bootloader will most definitely be seen as “an issue” by Verified Boot, preventing the device from booting up.
Another problem that will arise with Strictly Enforced Verified Boot, is one that will affect even the users who don’t really care about getting root privileges, or installing Custom ROMs. Over time, as you use your device, there is bound to be natural data corruption in the memory; not due to the presence of a malware, but simply because it happens. This isn’t usually a problem, or at least not as severe a problem as Verified Boot will turn it into. If you have corrupt data that Strictly Enforced Verified Boot can’t fix on boot, it will not allow your device to boot up. In my opinion, that is a bigger, more visible issue, than some corrupt data on the user partition.
3. The Ugly
In all the benefits of enforcing Verified Boot, and all the potential issues, the most disturbing, probably, is the fact that OEMs might start misusing this to lock their devices such that people aren’t able to use Android for what it was meant to be: open, developer-friendly, and completely customisable. Strictly Enforced Verified Boot will put in the hands of OEMs, the power to ensure that people aren’t able to unlock the bootloaders on their devices, thereby prohibiting them from installing Custom ROMs and feature enhancing tools like Xposed Modules.
SEE ALSO: No Android N Custom ROM Available? We Have The Solution For You
Android Nougat: A Radical Change in the Way Android Works?
Although we’re sure Google’s intentions were simply to avoid potential problems to casual Android users, who wouldn’t know what to do in case their device was affected from a malware, or if their memory had corrupted data blocks, it may have handed OEMs and manufacturer’s the perfect tool to lock users into living with what they were offered, and nothing more.
Of-course someone will figure out an exploit, or a workaround for this situation, and we kinda hope they do, in the true spirit of Android. Until someone does figure out a solution, however, all that we, as users can do, is ensure we buy our devices from developer-friendly manufacturers.
Featured Image Courtesy: Flickr
