Upgrading Android Attestation: Remote Provisioning

Posted by Max Bires, Software Engineer

Attestation as a feature has been mandated since Android 8.0. As releases have come and gone, it has increasingly become more and more central to trust for a variety of features and services such as SafetyNet, Identity Credential, Digital Car Key, and a variety of third party libraries. In light of this, it is time we revisited our attestation infrastructure to tighten up the security of our trust chain and increase the recoverability of device trust in the event of known vulnerabilities.

Starting in Android 12.0, we will be providing an option to replace in-factory private key provisioning with a combination of in-factory public key extraction and over-the-air certificate provisioning with short-lived certificates. This scheme will be mandated in Android 13.0. We call this new scheme Remote Key Provisioning.

Who This Impacts?

OEMs/ODMs

Device manufacturers will no longer be provisioning attestation private keys directly to devices in the factory, removing the burden of having to manage secrets in the factory for attestation.

Relying Parties, Potentially

Described further down below, the format, algorithms, and length of the certificate chain in an attestation will be changing. If a relying party has set up their certificate validation code to very strictly fit the legacy certificate chain structure, then this code will need to be updated.

Why Change?

The two primary motivating factors for changing the way we provision attestation certificates to devices are to allow devices to be recovered post-compromise and to tighten up the attestation supply chain. In today’s attestation scheme, if a device model is found to be compromised in a way that affects the trust signal of an attestation, or if a key is leaked through some mechanism, the key must be revoked. Due to the increasing number of services that rely on the attestation key signal, this can have a large impact on the consumer whose device is affected.

This change allows us to stop provisioning to devices that are on known-compromised software, and remove the potential for unintentional key leakage. This will go a long way in reducing the potential for service disruption to the user.

How Does This Work?

A unique, static keypair is generated by each device, and the public portion of this keypair is extracted by the OEM in their factory. These public keys are then uploaded to Google servers, where they serve as the basis of trust for provisioning later. The private key never leaves the secure environment in which it is generated.

When a device is unboxed and connected to the internet, it will generate a certificate signing request for keys it has generated, signing it with the private key that corresponds to the public key collected in the factory. Backend servers will verify the authenticity of the request and then sign the public keys, returning the certificate chains. Keystore will then store these certificate chains, assigning them to apps whenever an attestation is requested.

This flow will happen regularly upon expiration of the certificates or exhaustion of the current key supply. The scheme is privacy preserving in that each application receives a different attestation key, and the keys themselves are rotated regularly. Additionally, Google backend servers are segmented such that the server which verifies the device’s public key does not see the attached attestation keys. This means it is not possible for Google to correlate attestation keys back to a particular device that requested them.

What is Changing from a Technical Standpoint?

End users won’t notice any changes. Developers that leverage attestation will want to watch out for the following changes:

• Certificate Chain Structure
  • Due to the nature of our new online provisioning infrastructure, the chain length is longer than it was previously, and is subject to change.
• Root of Trust
  • The root of trust will eventually be updated from the current RSA key to an ECDSA key.
• RSA Attestation Deprecation
  • All keys generated and attested by KeyMint will be signed with an ECDSA key and corresponding certificate chain. Previously, asymmetric keys were signed by their corresponding algorithm.
• Short-Lived Certificates and Attestation Keys
  • Certificates provisioned to devices will generally be valid for up to two months before they expire and are rotated.