Documentation

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

Support status

Device Version End-of-life date
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

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 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[1]
Nexus 9 Partial n/a No Yes Yes Yes
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] 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.

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.

Memory

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.

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

Encryption

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