Register & Validate Attestation Key Pairs

Registration

Let's start with the assumption, that we have a customer base identified with a high level of assurance.

Now the onboarding process has to make sure, that the asserted identities can be unambiguously linked to the newly generated attested key pairs under sole control of the user.

This registration process is critical. The overall level of assurance depends directly on this initial mapping.

In most cases we would start from an authenticate encrypted end-to-end channel (HTTPS) to the customer device. The communication over multiple independent channels can improve the level of assurance. Within this secure channel the user is asked to generate a high security hardware backed key pair. To prevent replay attacks, the server sends an attestation challenge along the key generation request. The APC app starts the key generation process with the attestation challenge according to the key requirement defined by the service. A successful key generation will provide:

• a hardware backed key pair
• an attestation certificate of the key pair containing:
• information about the key store
• information where the key was generated (tag origin)
• general X509v3 certificate information such as validity, issuer, key properties such as algorithm, key length, etc.
• information about the key properties, e.g. the property TrustedConfirmationRequired will enforce that the key can only be used for Trusted Confirmation.
• the attestation challenge of the service (preventing replay attacks)
• information about the key purpose such as signing, encrypting, wrapping, etc.
• information about the authentication required for accessing the key
• information about the application (with version number) which are able to use the key pair
• information about the hardware and software controlling the protected environment such as
• device information
• device lock state
• boot state
• OS version
• OS patch level
• vendor patch level
• boot patch level
• full attestation chain down to root certificate of the OEM (Original Equipment Manufacturer)

Note that there is a small gap between endpoint of the trusted channel and the key generation on the Secure Element, that offers a residual attack surface.

In case the customer is uncertain about his registered key, it would be valuable to have a function within the TEE (Trusted Execution Environment) allowing to display hashes of its managed key on the Trusted UI. This would allow an easy end-to-end verification of the key material. I.e. the customer could communicate this key information via telephone to the help desk, regardless of the state of his REE (Rich Execution Environment).

Verification At Key Registration

On the server site it is important to verify that the key presented by the user meets the high security requirements of an APC key. Verify that:

1. the presented X509 certificate is valid i.e.:
   • The format is valid and mandatory fields are present.
   • The signature can be validated.
   • The signature cryptographic constraints are met.
   • The current time is within the validity range of the certificate
   • The critical certificate extension keyUsage must be set to Digital Signature.
   • The certificate is unique.
2. the certificate has the certificates attestation extension tag attestation.
3. the key parameters such as key algorithm, key length meet your cryptographic constraints. See tags algorithm, keySize, digest, padding, ecCurve, rsaPublicExponent mgfDigest (mask generation function for PKCS#1).
4. the certificate chain can be validated down to any of the trusted OEM attestation root certificates.
5. all certificates along the chain are valid and none of the certificates has been revoked.
6. the key is stored on the required hardware trust store such as Secure Element if you need a certified HSM (Hardware Storage Module). See tags attestationSecurityLevel and keyMintSecurityLevel.
7. the key was generated on the trust key store. The tag origin should be set to generated (0).
8. the key can only be accessed by the expected application (package name and version). The tag applicationId reflects the Android platform's belief as to which apps are allowed to use the secret key material under attestation. The tag applicationId takes an array of the sub tags packageInfo and Version.
9. the "attestation challenge" (tag attestationChallenge) in the certificate matches the challenge you sent to the client.
10. the key has the trustedConfirmationRequired tag set.
11. the key has the unlockedDeviceRequired tag set. (Note this is not mandatory. However, normally you do not want to allow key usage on a locked device.)
12. the key purpose (tag purpose) has only sign (2) set.
13. the key creation time (tag creationDateTime) is in the range of your expectation.
14. the device status locked (sub tag deviceLocked of tag rootOfTrust) is set to true. The tag deviceLocked reflects if the device bootloader is locked. A locked device has Android Verified Boot (AVB) enabled. AVB provides a cryptographically verifying chain of trusted bootloaders, which prevents an unsigned device image from being flashed onto the device. For more information about this feature, see Verifying Boot documentation.
15. the verified boot state (sub tag verifiedBootState of tag rootOfTrust) is set to VERIFIED (0).
16. the device type matches your expectations. See tags attestationIdBrand, attestationIdDevice, attestationIdProduct, attestationIdManufacturer, attestationIdModel, attestationIdSerial, etc. Note, that not all hardware identifiers predefined in the attestation extensions are actually set. Furthermore, if the device does not support ID attestation or destroyAttestationIds() was previously called the device can no longer attest its IDs.
17. the OS version matches your expectations (tag osVersion).
18. the OS patch level matches your expectations (tag osPatchLevel).
19. the vendor patch level matches your expectations (tag vendorPatchLevel).
20. the boot patch level matches your expectations (tag bootPatchLevel).
21. the biometric authentication is activated if required (tag userAuthType).

A good general description on how to verifying hardware-backed key pairs with Key Attestation can be found on the Android developer web site.

On Pixel 7 devices, the intermediate certificates of level 3 and level 4 have lifetime of 3 months (see Certificate Hierarchy). Therefore, the attestation certificate chain will vary over the lifetime of the APC key pair. However, this is only relevant for a revalidation of the key pair.

• [1] REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL