If you’ve been keeping up with Android developments, “Verified Boot” is a term that’s likely crossed your path frequently in recent years. Initially introduced by Google in Android 4.4 (Kitkat) as a subtle security measure, it has gradually gained prominence in subsequent iterations of the Android Operating System.
Recent reports have highlighted the inclusion of “Strictly Enforced Verified Boot” in Google’s latest version of the world’s most popular mobile OS, Android Nougat. This enhanced security feature implements more rigorous checks during device boot-up. While Verified Boot in Marshmallow merely issued a warning if any irregularities were detected in the system partition, Android Nougat takes a more assertive approach. With “Strictly Enforced Verified Boot,” the device will refuse to boot if anomalies are found in the partition, alterations are made to the bootloader, or if any “malicious” code is detected on the device.
This prompts the question: What implications does this have for users? Interestingly, the answer varies between casual users and power users, and we’ll explore both perspectives.
Strictly Enforced Verified Boot
First, background on Verified Boot: Android verifies partitions by dividing them into 4KiB blocks and checking against a signed table. If clean, the system proceeds. However, if blocks are tampered with or corrupt, Android alerts the user, leaving resolution to them.
Android Nougat introduces Strictly Enforced Verified Boot, marking a significant shift. In Enforced mode, Verified Boot doesn’t tolerate any faults in partitions. It blocks booting upon detecting issues and may offer safe-mode access for troubleshooting. Beyond data block checks, it can rectify errors with Forward Error Correcting codes. However, it’s not foolproof; failure leaves users stranded.
Exploring Strictly Enforced Verified Boot
1. The Upside
Enforcing Verified Boot on Android devices enhances security. If the device is infected by malware, Strictly Enforced Verified Boot detects it on the next boot and either fixes it or prompts action.
This feature also checks for data corruption and can correct errors using FEC codes. Google’s FEC codes can correct one unknown bit error in 255 bits. While this may seem small, consider its significance on a mobile device:
Note: Values below are from a blog post by Google Engineer Sami Tolvanen on Android Developers.
Google could’ve utilized RS(255,223) FEC codes, capable of correcting 16 unknown bit errors in 255 bits. However, the 32 bits of redundant data would’ve incurred an overhead of almost 15%, particularly burdensome on mobile devices, considering Android’s prevalence on budget smartphones with 4-8 GB memories.
Opting for RS(255,253) FEC codes, Google traded error correction capabilities for space efficiency. These codes can rectify only a single unknown error in 255 bits, but with a mere 0.8% space overhead.
Note: RS(255,N) denotes Reed-Solomon codes, a form of error-correcting codes.
2. The Downside
Ever heard of “There are two sides to a coin”? Of course you have. While Google’s intentions with Strictly Enforced Verified Boot were undoubtedly 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 components. This implies that Android Nougat may encounter issues with rooting and flashing Custom ROMs because Verified Boot cannot distinguish between malware code and the code that unlocked your bootloader. Consequently, if your device came with a locked bootloader and your OEM prohibits bootloader unlocking, you essentially can’t do it. Hopefully, someone will discover an exploit for this.
Fortunately, many device rooters opt for developer-friendly phones like the Nexus, preferring custom ROMs for extra features. There’s much to ponder on this topic, but it’s not the demise of custom ROMs, especially on devices with unlocked bootloaders. Yet, Samsung phones, which lack official bootloader unlocking, face obstacles. Unlocking the bootloader on these devices triggers issues with Verified Boot, rendering them unable to boot.
Strictly Enforced Verified Boot poses a problem that affects users regardless of their interest in root privileges or Custom ROMs. Over time, natural data corruption in device memory is inevitable. While not necessarily severe, this issue is exacerbated by Verified Boot. If corrupt data persists beyond boot, Strictly Enforced Verified Boot prevents device startup. This renders data corruption on the user partition a more significant concern.
3. The Ugly
Among the benefits of enforcing Verified Boot, and the potential issues, the most disturbing is that OEMs might misuse this to lock their devices, preventing users from fully utilizing Android’s open, developer-friendly, and customizable nature. Strictly Enforced Verified Boot empowers OEMs to restrict bootloader unlocking, hindering users from installing Custom ROMs and feature-enhancing tools such as Xposed Modules.
Is Android Nougat Revolutionizing the Android Experience?
While Google likely aimed to prevent issues for casual Android users who might struggle with malware or corrupted data blocks, it inadvertently empowered OEMs and manufacturers to restrict users to their provided options.
Undoubtedly, someone will discover an exploit or workaround, aligning with Android’s ethos. Yet, until then, our only recourse as users is to patronize developer-friendly manufacturers.
Pritam Chopra is a seasoned IT professional and a passionate blogger hailing from the dynamic realm of technology. With an insatiable curiosity for all things tech-related, Pritam has dedicated himself to exploring and unraveling the intricacies of the digital world.
