11. Dezember 2023 | 13:05 Uhr

Weshalb GrapheneOS aktuell nur Google Pixel-Geräte unterstützt

Für einen Artikel über GrapheneOS habe ich Daniel Micay gefragt, warum derzeit nur Google Pixel Geräte unterstützt werden. Seine Antwort im Original:

Non-exhaustive list of requirements for future devices, which are standards met or exceeded by current Pixel devices:

Support for using alternate operating systems including full hardware security functionality

Complete monthly Android Security Bulletin patches without any regular delays longer than a week

At least 4 years of updates from launch (Pixels now have 7)

Vendor code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they’re released)

Linux 5.15 or Linux 6.1 Generic Kernel Image (GKI) support

Hardware memory tagging (ARM MTE or equivalent)

BTI/PAC, CET or equivalent

PXN, SMEP or equivalent

PAN, SMAP or equivalent

Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode / decode, image processor and other components

Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more times

Verified boot with rollback protection for firmware

Verified boot with rollback protection for the OS (Android Verified Boot)

Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)

StrongBox keystore provided by secure element

Hardware key attestation support for the StrongBox keystore

Attest key support for hardware key attestation to provide pinning support

Weaver disk encryption key derivation throttling provided by secure element

Inline disk encryption acceleration with wrapped key support

64-bit-only device support code

Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers

Pixels are currently the only Android devices providing both strong security and proper alternate OS support. There are currently no other devices meeting even the most basic security requirements while running an alternate OS. GrapheneOS is very interested in supporting a non-Pixel brand, but the vast majority of Android OEMs do not take security seriously. Samsung takes security almost as seriously as Google, but they deliberately cripple their devices when you unlock them to install another OS and don’t allow an alternate OS to use important security features. If Samsung permitted GrapheneOS to support their devices properly, many of their phones would be the closest to meeting our requirements. They’re currently missing the very important hardware memory tagging feature, but only because it’s such a new feature, and we’re optimistic that the next generation Snapdragon and Exynos SoC platforms will support it.

Android Security Bulletins (ASBs) list the Critical/High severity vulnerabilities backported to older releases which currently includes Android 11, 12, 13 and 14. These include many hardware-related vulnerabilities and cannot be provided for a device not receiving vendor support. Most alternate operating systems set an inaccurate Android security patch level by misrepresenting it as being provided via Android Open Source Project updates. They downplay the equally important patches that are not included either because the device is end-of-life, has late security patches or the alternate OS is behind the OS release used by the device such as LineageOS on Pixels so they’re unable to provide half of the important security patches. Most of the Moderate/Low severity patches are not backported and usually no longer receive CVE assignments. Most privacy patches are Moderate or lower severity. Pixels are nearly the only devices providing the monthly and quarterly releases of Android rather than only the yearly releases with the Android Security Bulletin backports applied. An alternate OS can largely address the missing recommended patches, unlike the baseline ASB patches, but some will be missing for the hardware-related code. Pixels always receive both the mandatory ASB patches and recommended patches in the month they’re released, but we’re willing to tolerate a longer delay for the recommended patches in order to expand device support.

Pixel 2 added a secure element with Weaver and insider attack resistance. It also began providing hardware attestation support, used by our Auditor app. Samsung started providing it a couple years ago. Other vendors are finally catching up but it’s far from a standard feature and is usually skipped unless the SoC vendor provides it out-of-the-box via a secure element embedded on the SoC. Pixel 3 and later provide the StrongBox keystore ever since they moved to the Titan M. Pixel 6 moved to a new RISC-V secure element with much lower attack surface than the previous ARM Cortex based secure element. It also began providing official pinning support for hardware attestation, which was a feature requested by GrapheneOS for Auditor and essentially not used by anyone else which was confirmed by us finding multiple non-security bugs with it which they resolved. Most Android devices are still missing all of these features.

Hardware memory tagging is a game changer for protecting against exploitation. Pixel 8 and Pixel 8 Pro are the first devices with working hardware support for it along with a developer options toggle to enable it for the OS and apps for finding and resolving bugs with it. However, many apps are incompatible and they provide no way to work around it for them. GrapheneOS is the first platform using ARM hardware memory tagging by default. We have a stronger implementation as part of our hardened_malloc providing more deterministic guarantees, covering more allocations and reinforced through the other security features. We use it by default for the base OS and apps known to be compatible with it. There’s a toggle in security settings for enabling it for all user installed apps which can then be disabled on a case-by-case basis with our per-app toggle. We provide very notifications for crashes caused by memory tagging referring to it and referring to the per-app toggle. Based on the notification, users can report the bugs to app developers with the crash log and disable it if needed.

GrapheneOS will support more than Pixels in the future when there are other devices meeting basic security requirements. We’re willing to make some sacrifices to do it such as accepting 4 years of proper support rather than 7 years. We aren’t willing to give up extremely important security features such as the recently launched hardware memory tagging. The hardware, firmware and hardware-related software is a major part of providing a secure device. Privacy and security are a moving target, so our requirements are expanded over time as the industry standards for security improve. Pixels are a mainstream device, not a niche security product, and expecting another device to provide these standard security features is very reasonable.