Recent updates to Google’s SafetyNet Attestation API have resulted in a rather loud community backlash. In turn, the rampant speculation regarding the viability of custom Android OS development has been overwhelmingly grim.
Let’s begin by clearing up some of these misconceptions that have been spotted in the wild. With SafetyNet now relying on hardware attestation to check the integrity of Android devices, it will legitimately be quite difficult to rely on insecure configurations like Rooting and leaving the bootloader unlocked. For security-minded developers, this is in fact good news. Relying on Verified Boot and hardware attestation to assure that an Android device is not “rooted” or that its bootloader is unlocked increases the difficulty of falsifying these results. While some feel that this inability to hack their device is a loss of freedom, the gain for device integrity is measurable. More and more people rely on their mobile device for much more than just making calls- today’s mobile device is as much personal planner and assistant as it is wallet, watch and perhaps even your house key. These expansive uses require a secure environment, and for good reason. You really don’t want your banking and personal information to be vulnerable for the sake of convenience.
While Android users are going to have to say goodbye to the wild west days of unlocked bootloaders and rooted systems, they can certainly look forward to more secure transactions and a safer place to store their personal information.
The major misconception that we would like to address here, however, is the viability of CopperheadOS' development in light of these changes.
Android Verified Boot and a Locked Bootloader are important security features that CopperheadOS is designed to support.
As a product designed for security and privacy, CopperheadOS has always concentrated on supporting Google’s hardware to ensure that our devices can be OEM unlocked and relocked. The Google Pixel series of mobile phones allow for a developer to lock and unlock the bootloader without having to rely on any software or hardware vulnerability. This allows CopperheadOS to be securely and safely installed on any Google Pixel series device without compromising the security and privacy of our users.
Currently, the only way for SafetyNet to interact with Android Apps installed on a device is over Google’s Play Services SafetyNet Attestation APIs. For CopperheadOS, this means that Apps designed to rely on SafetyNet attestation will not work. Certainly, with Google’s changes and push to have SafetyNet used in more Android Apps to increase application security this will mean that fewer and fewer of those Apps will be compatible with CopperheadOS.
Luckily, these changes will take time for App developers to include in their Apps. In turn, this gives Copperhead the opportunity to increase our compatibility at the same time.
The open Android ecosystem allows for innovation from companies small and large who then push changes and bring innovation back to the ecosystem as a whole. The Android Security team who helps protect this ecosystem has, for years, been tightly knit with the Android OS building community. Google promotes the growth of the Android ecosystem to include more companies, and more Android users and thus to continue to support unlockable bootloaders and verified boot on the most secure Android phones.
Misconceptions about Google’s alignment with companies such as Copperhead should be dispelled knowing that Google benefits from our hard work, as we do with theirs. In synchronicity, we all win.
With the changes to the SafetyNet Attestation API comes a huge battery of changes to the Compatibility Test Suite. These changes to the CTS are intended to smooth the process of determining Android compatibility. For this reason, Copperhead is devoting significant resources to ensure that we pass CTS at every stage of our build process. This will be the first step that Android ROM developers are all going to have to take to stay in the game, and ensure the security and compatibility of their work with the Android platform.
We thank Google, the Android Security team and Shawn Willden for this opportunity to increase our compatibility, and to work closely in bringing greater security and privacy to the Android ecosystem.