Attestation compatibility guide

Apps using the Play Integrity API or obsolete SafetyNet Attestation API to check the authenticity/integrity of the OS can support GrapheneOS by using the standard Android hardware attestation API instead and permitting our official release signing keys. Android's hardware attestation API provides a much stronger form of attestation than the Play Integrity API with the ability to whitelist the keys of alternate operating systems. It also avoids an unnecessary dependency on Google Play services and Google's Play Integrity servers.

Devices have been required to ship with hardware attestation support since Android 8. You can use hardware attestation on devices running Android 8 or later when the ro.product.first_api_level system property isn't set to 25 or below, which indicates they launched with Android 8 or later with hardware attestation support as a mandatory feature. On older devices, you can continue using the Play Integrity API. Some low quality devices shipped broken implementations of hardware attestation despite the requirement to have it working for CDD/CTS certification and the Play Integrity API currently still passes on those devices wrongly claiming them to be CTS certified. If you don't want to fail on those devices, then you can start with hardware attestation and fall back to the Play Integrity API or do both and accept either passing as success.

Google provides a key attestation library with examples. Our MIT / Apache 2 licensed Auditor app can be used as a reference implementation for verifying hardware-based attestations. There are some subtleties in the verification process such as making sure only the 2nd certificate in the chain (the one signing the certificate for the key generated by your app) has an attestation extension to prevent making a fake attestation by extending the chain. You can reuse our code and simply omit support for an app generated attestation signing key (attest key) and the other pinning support.

After verifying the signature of the attestation certificate chain and extracting the attestation metadata, you can enforce that verifiedBootState is either Verified or SelfSigned. For the SelfSigned case, you can check that verifiedBootKey matches one of the official GrapheneOS verified boot keys. These are the base16-encoded verified boot key fingerprints for the official GrapheneOS releases:

The verifiedBootKey field is binary data so you either need to encode it as base16 to compare with these or convert these to binary. An easy approach is storing the permitted key fingerprints in a set and enforcing that the verified boot key is in the permitted set when verifiedBootState is SelfSigned.

GrapheneOS regularly adds support for new devices so you should have a process for regularly adding the new verified boot key fingerprints from this page.

The hardware attestation API also provides other useful information signed by the hardware including the OS patch level, in a way that even an attacker exploiting the OS after boot to gain root cannot trivially bypass. It's a better feature than the Play Integrity API which has to be designed for the lowest common denominator.

GrapheneOS users are strongly encouraged to share this documentation with app developers enforcing only being able to use the stock OS. Send an email to the developers and leave a review of the app with a link to this information. Share it with other users and create pressure to support GrapheneOS rather than locking users into the stock OS without a valid security reason. GrapheneOS not only upholds the app security model but substantially reinforces it, so it cannot be justified with reasoning based on security, anti-fraud, etc.