Introduction to Android Key Attestation

Android’s hardware-backed key attestation is a cornerstone of its security model, providing a cryptographic guarantee about the integrity and origin of cryptographic keys. In a world where device tampering and software exploits are increasingly sophisticated, applications rely on attestation to verify that a key was indeed generated and operates within a trusted execution environment (TEE) or StrongBox, and that the device’s software and hardware state are as expected. This mechanism allows services to establish trust with client devices, mitigating risks like rooted devices, compromised bootloaders, or modified system images.

This article dives deep into the structure of Android attestation reports, guiding you through the process of reverse engineering their intricate trust chains and certificates. We’ll explore the critical components, including the attestation extension and its authorization lists, and demonstrate practical steps to dissect these reports to understand their assertions about device security.

How Android Key Attestation Works

At its core, Android Key Attestation leverages a chain of digital certificates. When an application requests a hardware-backed key, the Keymaster HAL (Hardware Abstraction Layer) within the device’s TEE or StrongBox generates the key and then issues an attestation certificate for it. This certificate doesn’t just prove the key’s existence; it embeds a wealth of information about the key’s properties, its security level, and the state of the device at the time of key generation. This information is cryptographically signed by an attestation key residing securely within the TEE or StrongBox itself. This attestation key is, in turn, certified by an attestation root key, typically burned into the device’s hardware by the manufacturer, forming a robust chain of trust.

The Attestation Trust Chain

An Android attestation report is essentially a standard X.509 certificate with a special extension. The chain of trust typically looks like this:

1. Root Certificate: A manufacturer-specific certificate, often self-signed or signed by a global attestation root. This root is implicitly trusted.
2. Intermediate Certificates: One or more certificates issued by the manufacturer, chaining up to the root. These might be specific to device models or production batches.
3. Attestation Certificate: The certificate issued for the specific hardware-backed key, signed by an intermediate certificate in the chain. This certificate contains the actual attestation data.

Anatomy of an Attestation Report Certificate

The real magic happens within the attestation certificate itself. While it’s a standard X.509 certificate, it contains a critical custom extension that carries the attestation data. This extension is identified by the OID 1.3.6.1.4.1.11129.2.1.17.

Dissecting the Attestation Extension (OID 1.3.6.1.4.1.11129.2.1.17)

The attestation extension is an ASN.1 encoded structure named AttestationRecord. It’s composed of several crucial fields:

• attestationVersion: The version of the attestation format (e.g., 1, 2, 3).
• securityLevel: Indicates where the key was generated and resides.
  • STRONGBOX (3): Highest security, dedicated hardware.
  • TRUSTED_ENVIRONMENT (2): Generated and resides in the TEE.
  • SOFTWARE (1): Generated and resides in software (less secure, not hardware-backed).
• keyMintVersion: Version of the KeyMint (or Keymaster) HAL.
• bootloaderVersion: Version of the bootloader.
• osVersion: Android OS version.
• osPatchLevel: Android security patch level.
• vendorPatchLevel: Patch level for vendor-specific components.
• bootState: The verified boot state of the device.
  • VERIFIED (0): Device is running the original OS.
  • UNVERIFIED (1): Device state is unknown or tampered.
  • SELF_SIGNED (2): Device is running a custom ROM.
  • UNVERIFIED_ROOT_OF_TRUST (3): Root of trust is not verified.
• verifiedBootKey: Hash of the verified boot public key (APK Digest).
• deviceLocked: Boolean indicating if the device is locked (true) or unlocked (false).
• individualAttestation: Present if the device supports individual attestation, providing a unique ID.

Crucially, the AttestationRecord also contains two authorization lists:

1. softwareEnforced: Key properties enforced by software (Keymaster in Android OS).
2. hardwareEnforced: Key properties enforced by hardware (TEE/StrongBox).

These lists contain details about the key’s usage, purpose, algorithms, validity periods, and other constraints. For a truly secure key, the most critical properties (e.g., specific usage, non-exportability, user authentication requirements) should appear in the hardwareEnforced list.

Practical Reverse Engineering Steps

To reverse engineer an attestation report, you typically need the full certificate chain. Let’s assume you’ve obtained the X.509 certificate bytes, perhaps from a client application that requests and receives attestation data.

Step 1: Obtain the Attestation Certificate Chain

In a real-world scenario, a secure application would request an attestation certificate from the Android Keystore system. For reverse engineering, you might intercept this communication or extract the certificate from an APK if it’s bundled for testing purposes. If you have a client application that performs attestation, you might use network proxies (like Burp Suite or mitmproxy) to capture the raw certificate data during its transmission to a server.

Step 2: Inspecting the Certificates with OpenSSL

Once you have the certificate (e.g., in PEM or DER format), OpenSSL is your primary tool. If it’s in DER format, first convert it to PEM:

openssl x509 -inform DER -in attestation_cert.der -outform PEM -out attestation_cert.pem

Now, inspect its contents:

openssl x509 -in attestation_cert.pem -text -noout

This command will display all standard X.509 fields (Subject, Issuer, Validity, Public Key Info). Scroll down to the