Android 8.0 (Oreo) is the second newest version of Google’s Android OS available, still making its way to many flagship handsets, and Google has put out a detailed blog post that goes over some of the new security measures in the OS, such as changes to Verified Boot and hardware-based security. Oreo boasts support for security features like an OEM Lock Hardware Abstraction Layer, which allows manufacturers to implement whatever level of protection over the core OS and kernel code in their devices that they want, along with a special process that sandboxes users’ in-browser web activity from the rest of the system by splitting off WebView into different processes with different privilege levels.
The changes to Verified Boot take heavy advantage of Project Treble, Google’s efforts to make a modular base for the Android system, and are extensive enough to warrant being called Android Verified Boot 2.0. The changes include common header and footer code across the board to make it easier to tell when something is amiss at boot, and a feature that blocks device boot if the firmware version has been downgraded. As far as hardware security, Oreo adds in support for a wide range of different types, and the Pixel 2 and Pixel 2 XL are the first consumer smartphones to use such technology. They have a specialized chipset on board that’s made to verify code in real time and resist both physical and remote data attacks and exploits. Google welcomes all manufacturers to take advantage of this new feature of Oreo and put their own hardware security into new handsets. Furthermore, all Google Mobile Services devices going forward must be equipped with Key Attestation, a technology that allows for the creation and use of complex encryption keys for various purposes both before and after boot.
The Android platform in general has had its security hardened in many ways with Oreo. For starters, Project Treble allows vendor HALs for individual device components to run sandboxed from the main core of the system, keeping the device safe from exploits that take advantage of that piece of hardware. Likewise, most aspects of how Android handles media have been retooled to lower privilege levels and sandbox media containers and protocols from the bulk of the system’s code. Unused system calls have been locked away from app and user access to prevent exploits, kernel and user layers have been separated completely, and changes to the way Android devices identify themselves have been made in order to prevent authentication spoofing.