CopperheadOS device comparison
- Support status
- Bootloader firmware
- WiFi driver / firmware
- Trusted Execution Environment (TEE) firmware
- Kernel hardening
This is not a comparison of hardware specifications that are already available from Google.
The security properties of Pixel devices can be considered minimum requirements for any future devices. CopperheadOS won’t support another device without full verified boot, A/B update support, a 64-bit CPU, LPDDR4 with TRR, driver support for at least Linux 4.4 (2nd generation Pixels), etc.
Obsolete devices no longer supported by Android or CopperheadOS like the Nexus 5 are included to document historical progress.
Note that the end-of-life date is a minimum guarantee from the OEM and is subject to change. CopperheadOS can continue OS updates past end-of-life for a long time but full security updates require continued releases of the firmware for components like the baseband, WiFi, TrustZone, etc.
|Pixel XL||Nougat MR2 (current)||October 2019|
|Pixel||Nougat MR2 (current)||October 2019|
|Nexus 6P||Nougat MR2 (current)||September 2018|
|Nexus 5X||Nougat MR2 (current)||September 2018|
|Nexus 9||Nougat MR1 (maintenance only)||October 2017|
|Nexus 5||n/a||October 2016|
|Device||Verified boot||OS public key fingerprint display||A/B update support||Serial debugging while locked||OEM unlocking toggle||Anti-theft protection|
|Pixel XL||Full||Missing (spec violation acknowledged by Google)||Yes||Restricted||Yes||Yes|
|Pixel||Full||Missing (spec violation acknowledged by Google)||Yes||Restricted||Yes||Yes|
|Nexus 6P||Full||Weak (64-bit via 16 hex characters)||No||Yes (despite toggle)||Yes||Yes|
|Nexus 5X||Full||Weak (48-bit via 12 hex characters)||No||Yes||Yes||No|
A/B update support provides two sets of OS partitions (A and B slots) with support for safe atomic swaps between them. This requires a fair bit of firmware support and includes automatic rollbacks of updates after they’re installed if booting the OS fails multiple times. The freshly booted new OS version will verify the installation late in the booting process and will then mark the boot as successful, otherwise rollback will happen after multiple attempts without success.
CopperheadOS has a modern update client for A/B update devices implementing fully automatic updates with automatic resume after failure at any point in the download, verification, installation and post-installation verification process. Previously, CopperheadOS used a fork of the CyanogenMod / LineageOS CMUpdater app which is still the update client on CopperheadOS Nexus devices and it isn’t very friendly or robust and it isn’t able to resume downloads or attempt to perform installation again without deleting the download or starting over, unlike the new update system.
 Firmware support for CopperheadOS anti-theft protection works for the Nexus 9 and Nexus 6P, but when requiring the password / PIN on boot it can be bypassed.  CopperheadOS anti-theft protection doesn’t work for the Nexus 5X because it provides a non-standard download mode able to force a factory reset.
WiFi driver / firmware
|Device||Vendor||Robust scanning MAC randomization|
|Pixel XL||Qualcomm Atheros||Yes|
|Nexus 5X||Qualcomm Atheros||Yes|
See the Android blog post on Changes to Device Identifiers in Android O for an overview. Qualcomm Atheros WiFi on Nexus / Pixel devices has enhanced drivers / firmware providing more robust MAC randomization than can be accomplished by CopperheadOS via the usual device-agnostic kernel and userspace MAC randomization support.
CopperheadOS enables scanning MAC randomization on other devices at the wpa_supplicant layer but it isn’t comparable to full firmware support where packet sequence numbers are also randomized and other identifying information is removed.
Trusted Execution Environment (TEE) firmware
|Device||Key / verified boot attestation||Disk encryption keys|
|Pixel XL||Yes||Encrypted by TEE|
|Pixel||Yes||Encrypted by TEE|
|Nexus 6P||No||Encrypted by OS|
|Nexus 5X||No||Encrypted by OS|
|Nexus 9||No||Encrypted by OS|
|Nexus 5||No||Encrypted by OS|
Disk encryption keys
Disk encryption keys are randomly generated and stored encrypted via key encryption keys derived from user credentials and other inputs. On older devices, the TEE was used as part of the process of deriving the key encryption key with scrypt in the OS. On newer devices, the OS uses scrypt to perform similar key derivation with scrypt and passes the output to the TEE. This puts the TEE in a better position as it can perform hardware-bound key derivation via features like using Qualcomm Crypto Engine HMAC support for hardware-bound HKDF. Details on the current implementation are not currently made available but it’s at least as good as the old implementation and the TEE is no longer crippled by a lackluster API at the boundary with the OS.
|Device||Memory standard||TRR||ECC||Rowhammer susceptibility|
|Pixel XL||LPDDR4||Yes||No||Moderate (varies)|
|Nexus 6P||LPDDR4||Yes||No||Moderate (varies)|
|Nexus 5X||LPDDR3||No||No||Very high (varies)|
|Nexus 9||LPDDR3||No||No||Very high (varies)|
|Nexus 5||LPDDR3||No||No||Very high (varies)|
Features supported by every currently supported device like heap canaries are not listed. Unlike the tables above, this is software related so this table is specific to CopperheadOS and in theory these features could be backported further if we had more resources. However, the priority would be backporting more changes from mainline / linux-hardened to the latest devices.
|Device||LTS Branch||PXN||PAN||HARDENED_USERCOPY||FORTIFY_SOURCE||RO protection||SSP||ASLR|
|Pixel XL||3.18||Hardware||Software||Yes||Yes||Basic||Strong + zero byte||Hardened, 39-bit address space|
|Pixel||3.18||Hardware||Software||Yes||Yes||Basic||Strong + zero byte||Hardened, 39-bit address space|
|Nexus 6P||3.10||Hardware||No||No||No||Weak||Strong + zero byte||Basic, 39-bit address space|
|Nexus 5X||3.10||Hardware||No||No||No||Weak||Strong + zero byte||Basic, 39-bit address space|
|Nexus 9||3.10||Hardware||No||No||No||Terrible||Basic||Basic, 39-bit address space|
|Nexus 5||3.4||No||No||Yes||No||Terrible||Basic||Hardened, 32-bit address space|
See the relevant Android documentation for details. File-based encryption (FBE) has per-profile encryption keys and splits up storage into credential encrypted (default) and explicitly opt-in device encrypted storage available before the device is unlocked. For example, the modern CopperheadOS Updater app marks itself as Direct Boot aware and marks the update settings as device encrypted in order to perform updates before the device is unlocked. It enables fully automatic maintenance of an idle device. In the future, FBE will also enable authenticated encryption and storage classes for protecting data while locked by dropping a set of keys derived from the user credentials from memory when it locks. Devices are almost always turned on and keys can be physically extracted from a device that’s turned on so FBE is crucial for improving disk encryption to meet real world needs. It’s possible to protect data while locked today, but app developers are too lazy to do it via the keystore and need an easy mechanism via a new FBE storage class.
The drawback of FBE is that it can leak more metadata when comparing devices that are turned off. For example, even though file names are encrypted some information can be gained based on their size. CopperheadOS increases the padding of file names from the default 4 bytes to 32 bytes. The protection of other metadata will improve over time as part of Linux ext4 development. Device encrypted data is very explicitly opt-in and few apps take advantage of it so that isn’t a serious concern for apps, but it is one for the base system since it uses it a fair bit to implement a fully functional OS in early boot. Our view is that these issues are not major ones and can be worked through. The advantages of FBE will far outweigh the disadvantages in the future. It would be possible to layer FBE on top of FDE but there would need to be a boot password again for it to accomplish much and that would lose the usability advantages of Direct Boot along with truly fully automatic update support. It’s something we can consider for the future, but mitigating the side channel metadata leakage for devices that are turned off is far less important to us than advancing protection of data while the screen is locked by moving as much as possible to a new storage class.
File-based encryption requires firmware support to be fully implemented. There was an experimental version ported by Google to the Nexus 5X and 6P but it shouldn’t be used beyond testing and cannot be considered robust or secure. It isn’t quite the same as the real thing and the legacy update client on CopperheadOS Nexus devices cannot perform updates if it’s enabled.