Hardware-backed attestation chains — Keystore, Knox, StrongBox, Secure Enclave

1. The X.509 chain

A hardware-backed attestation, on every major platform, takes the same shape: an X.509 certificate chain that the relying party verifies offline against a published vendor root [1, 5]. The links of the chain are roughly:

• Vendor root CA. Long-lived, published by Google, Apple, or the device vendor. The relying party pins this root.
• Batch or intermediate CA. Scoped to a manufacturing batch, device model family, or OEM-specific provisioning regime.
• Device key. Unique per device. In the legacy Android model (and on Apple), this key is factory-provisioned by the OEM inside the hardware element with a vendor-issued attestation certificate. Remote Key Provisioning (RKP) introduces an alternative path: the framework appeared with KeyMint 1.0 in Android 12 (available), and is mandatory on devices launching with Android 14 (enforced). RKP replaces the long-lived factory-provisioned attestation key with short-lived attestation keys issued on-demand from Google’s RKP servers, rooted in a per-device long-lived identity. Either way the key is hardware-resident and its certificate is signed by the intermediate; “first boot” key generation is not the model on either platform.
• App-bound key. Generated by an application calling the platform key-generation API with attestation parameters. Its certificate is signed by the device key. The certificate’s extensions describe the protections in force on the key (the hardware level, the user-authentication requirements, the bound-to-app identity).

Each step in the chain is a signed assertion the relying party verifies. When the chain validates, the relying party knows the attested public key was generated by a specific application on a specific device, inside a specific class of hardware element.

2. Android Keystore + StrongBox

Android Keystore exposes hardware-backed key generation through the KeyGenParameterSpec builder, with setAttestationChallenge() producing the chain [1]. The key is generated inside the device’s Trusted Execution Environment by default, or — if the application requests it and the device supports it — inside StrongBox [2], a tamper-resistant secure element distinct from the main TEE.

The certificate’s KeyDescription extension — encoded as ASN.1 inside the cert — declares:

• the hardware level (SOFTWARE, TRUSTED_ENVIRONMENT, STRONGBOX),
• the algorithms and parameters the key supports,
• the user-authentication requirements (none, device unlock, biometric),
• the bound-to-app identity in AttestationApplicationId (the calling app’s package and signature),
• and the bound-to-device identity in RootOfTrust — verifiedBootKey, deviceLocked, verifiedBootState (Verified | SelfSigned | Unverified | Failed), and verifiedBootHash. App identity and device identity are separate ASN.1 sequences in the KeyDescription; the relying party reads them independently.

A relying party that verifies the chain and parses the KeyDescription gets a precise statement about the key’s provenance and its operating constraints.

3. Samsung Knox

Samsung Knox layers a separate attestation chain on top of the Android Keystore stack [3]. A Knox attestation certificate is issued by Samsung’s Knox Attestation service and binds the device to its Samsung-provisioned identity. Knox attestation can attest to:

• The device is a genuine Samsung device with Knox enabled.
• The device has not been root-detected by Samsung’s Knox Warranty bit (a one-way fuse that flips on detected bootloader unlock or compromise).
• The device’s provisioning state matches Samsung’s records.

The Knox chain is independent of the Google-rooted Keystore chain. Operators that need both the platform-level guarantee and the Samsung-specific guarantee can verify the two chains in parallel.

4. Apple Secure Enclave + App Attest

Apple’s Secure Enclave is the hardware element that holds keys on iOS and macOS devices [4]. App Attest [5] — covered in detail in app-attest-and-device-check — is the application-facing API for hardware attestation: generate a key in the Enclave, attest it to bind the key to a genuine app on a genuine device, then sign challenges with the attested key.

The cryptographic structure is similar to Keystore attestation — a chain rooted in a vendor CA, a key whose private half never leaves the hardware, a per-call signature — but the wire format is CBOR rather than ASN.1, and the chain terminates at Apple’s App Attest Root CA rather than Google’s Keystore root.

5. What the chain proves and where it stops, by design

What the chain proves, on every platform:

• Provenance — the key was generated in the named hardware element, on a device that passed factory provisioning.
• Uniqueness — the key is bound to a specific app on a specific device.
• Operational constraints — the key cannot be exported, cannot be used without the declared authentication, and is bound to the verified-boot state.

What the chain does not prove:

• Runtime use. The chain is a statement about the key’s origin and constraints. It does not say what the runtime did with the key on a given call. A signature produced by the attested key at runtime is a separate event; the chain authorises that signature, but the call itself is not part of what the chain attests.
• Continuous presence. The chain is durable across calls — once verified, the relying party trusts the key until invalidated — but it does not continuously re-verify the device’s runtime state.

For an operator, the right way to consume hardware attestation is as a stable trust basis: the chain establishes that the key the operator is talking to is hardware-backed; subsequent runtime events bound to that key (signed by it, observable through Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments) are how the operator gets a continuous account of what the runtime actually did.

6. Cross-references

• Sibling articles in this theme: play-integrity, app-attest-and-device-check, fido2-and-passkeys
• Architecture: /architecture/runtime-coherence, /architecture/zero-trust-bootstrap
• Glossary: /glossary — Trusted Runtime Primitive, Zero Trust Bootstrap Protocol

7. External references

[1] AOSP. Verifying hardware-backed key pairs with Key Attestation. developer.android.com/privacy-and-security/security-key-attestation. Cited 2025-12-08.

[2] AOSP. Hardware-backed Keystore (StrongBox). source.android.com/docs/security/features/keystore. Cited 2025-12-08.

[3] Samsung Knox. Knox Attestation. docs.samsungknox.com/dev/knox-attestation/. Cited 2025-12-08.

[4] Apple. Apple Platform Security — Secure Enclave. support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web. Cited 2025-12-08.

[5] Apple. Establishing your app’s integrity (App Attest). developer.apple.com/documentation/devicecheck/establishing_your_app_s_integrity. Cited 2025-12-08.