<- Back to documentation

CopperheadOS device comparison

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 Treble, 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.

HiKey is a supported device but isn’t compared here because it’s only a development platform and it wouldn’t make sense to compare the (lack of) security properties.

The Samsung Galaxy S4 International LTE variant (jfltexx) used to be supported by CopperheadOS Alpha but we see that as a distinct operating system from CopperheadOS Beta and later where it became directly based on the Android Open Source Project and moved to fully signed production builds.

Support status

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.

Device Branch End-of-life date
Pixel XL Oreo R3 (current) October 2019
Pixel Oreo R3 (current) October 2019
Nexus 6P Oreo R6 (current) November 2018
Nexus 5X Oreo R4 (current) November 2018
Nexus 9 Nougat MR1 (maintenance only) October 2017
Nexus 5 n/a October 2016

Driver model

Device Treble
Pixel XL Yes
Pixel Yes
Nexus 6P No
Nexus 5X No
Nexus 9 No
Nexus 5 No

In addition to making future updates substantially easier and improving testing / verification, Treble substantially improves security by splitting up the HAL implementation into many isolated processes and reducing kernel attack surface.

Bootloader firmware

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 Strong implementation in progress Yes Restricted Yes Yes
Pixel Full Strong implementation in progress Yes Restricted Yes Yes
Nexus 6P Full Weak (64-bit via 16 hex characters) No Yes (despite toggle) Yes Yes[1]
Nexus 5X Full Weak (48-bit via 12 hex characters) No Yes Yes No[1][2]
Nexus 9 Partial n/a No Yes Yes Yes[1]
Nexus 5 Partial n/a No Yes No 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.

[1] 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.

[2] 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 Robust associated MAC randomization
Pixel XL Qualcomm Atheros Yes Yes (CopperheadOS only)
Pixel Qualcomm Atheros Yes Yes (CopperheadOS only)
Nexus 6P Broadcom Partial (only rotated random MAC) No[1]
Nexus 5X Qualcomm Atheros Yes No
Nexus 9 Broadcom Partial (only rotated random MAC) Partial (CopperheadOS only)
Nexus 5 Broadcom Partial (only rotated random MAC) Partial (CopperheadOS only)

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.

Associated MAC randomization similarly requires cooperation from the firmware and drivers to avoid leaking other identifiers or the radio broadcasting before the MAC is randomized. On Pixel phones, CopperheadOS uses a custom implementation for Qualcomm Atheros after determining that there was no way to achieve the desired results via the standard MAC changing API.

[1] CopperheadOS did implement MAC randomization for the Nexus 6P but at some point it stopped working properly and has been removed for the time being.

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)
Pixel 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)

Kernel hardening

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.

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.

Device Mode
Pixel XL FBE
Pixel FBE
Nexus 6P FDE
Nexus 5X FDE
Nexus 9 FDE
Nexus 5 FDE