Upgrading Android Authentication: Remote Configuration

Author/Software Engineer Max Bires

Authentication has been a must-have feature since Android 8.0. As each version changes, authentication is increasingly becoming the core of trust for various functions and services, such as SafetyNet, Identity Credential, Digital Car Key, and various third-party libraries. Therefore, now we need to revisit the authentication infrastructure, strengthen the security of the trust chain, and improve the recoverability of device trust in the event of known vulnerabilities.

As of Android 12.0, we will provide an option to replace the in-factory private key configuration with an in-factory public key extraction plus an OTA (over-the-air) certificate configuration with a short-lived certificate. This scheme will be enforced in Android 13.0. We call this Remote Key Provisioning.

Which groups will be affected by this approach?

Original Equipment Manufacturer (OEM) / Original Design Manufacturer (ODM)

Device manufacturers will no longer provide authentication private keys directly to devices in the factory, removing the burden of having to manage authentication keys in the factory.

potential relying party

We explain further below the changes that will occur to the format, algorithm, and length of the certificate chain in authentication. This code needs to be updated if the relying party sets its certificate verification code so that the code must closely match the old certificate chain structure.

Why change?

There are two main motivations for our change in the way we provide authentication credentials to devices: allowing devices to recover after an attack, and tightening the authentication supply chain. In today's authentication schemes, a key must be revoked if an attack on a device model is found to affect the authentication's trust signal, or if the key is compromised by some mechanism. The move could have a huge impact on consumers whose devices are affected as more and more services rely on authentication key signals.

If the device is already running compromised software, this measure allows us to stop keying the device and eliminate the possibility of accidental key disclosure. This will greatly reduce the possibility of service interruption to users.

How does it work?

Each device generates a unique static key pair, the public part of which is extracted by the OEM in its factory. These public keys will then be uploaded to Google servers and used as the basis of trust for subsequent configurations. The private key never leaves the secure environment in which it was generated.

When the device is enabled and connected to the internet, it generates a certificate signing request for the key it has generated and signs it with the private key corresponding to the public key collected in the factory. The backend server will verify the authenticity of the request, then sign the public key, returning the certificate chain. The keystore then stores these certificate chains and distributes them to applications whenever authentication is requested.

This process will be performed periodically when the certificate expires or when the current key supply is exhausted. This scheme supports privacy protection, each application will receive a different authentication key, and the key itself will be rotated periodically. Additionally, Google's backend servers are segmented so that servers that validate the device's public key don't see the additional authentication key. This means that Google cannot associate authentication keys back to the specific device that requested them.

From a technical point of view, what has changed?

End users won't notice any changes. Developers using certification need to be aware of the following changes:

• certificate chain structure

  • Given the nature of the new online provisioning infrastructure, chain lengths are longer than before and are subject to change.

• root of trust

  • The root of trust will eventually be updated from the current RSA key to an ECDSA key.

• Deprecate RSA authentication

  • All keys generated and certified by KeyMint will be signed with an ECDSA key and corresponding certificate chain. In the past, asymmetric keys were signed by their respective algorithms.

• Short-lived certificates and authentication keys

  • A certificate configured for a device typically has a validity period of up to two months before it expires and is rotated.

You are welcome to click here to submit feedback to us, or to share what you like and problems you find. Your feedback is very important to us, thank you for your support!