Deconstructing the Android Keybox: A Deep Dive into Attestation, TEE Vulnerabilities, and the RKP Revolution

Android attestation is one of those systems that many people interact with without ever seeing what is happening underneath. Banking apps, payment services, DRM systems, enterprise software, and security sensitive applications may all rely on some form of device integrity signal.

One of the most discussed pieces of this system is the Keybox. The term is often used loosely, especially in the Android modding community, but it normally refers to factory provisioned attestation credentials and, in community tooling, to XML files containing an attestation private key and its certificate chain.

For years, factory provisioned attestation keys played an important role in Android hardware-backed key attestation. They also became the center of a long-running security problem: once valid attestation credentials escaped the provisioning environment, the same trust could potentially be reproduced outside the hardware they were originally intended for.

That is one of the reasons Android has been moving toward Remote Key Provisioning, or RKP. Instead of depending indefinitely on long-lived factory attestation credentials, RKP allows devices to obtain shorter lived attestation certificates for keys generated inside secure hardware.

In this article I want to explain what a Keybox actually is, what it is not, how Android Key Attestation works, where TEE and StrongBox fit into the picture, why leaked factory credentials became a problem, and why RKP changes the model so significantly.

Chapter 1: What Is Android Attestation?

Before talking about Keyboxes, it is important to separate a few concepts that are often mixed together.

Android Key Attestation allows a remote verifier to inspect cryptographic evidence about a key generated or protected by Android's secure hardware. That evidence can include information such as the security level of the key, verified boot state, OS version, security patch level, and other authorization properties.

A simplified Key Attestation flow looks like this:

Application
    |
    | requests an attested key
    v
Android Keystore / Keystore2
    |
    v
KeyMint
    |
    v
TEE or StrongBox
    |
    | generates or protects the key
    | creates attestation evidence
    v
X.509 certificate chain
    |
    v
Remote verifier

The important point is that the application key and the attestation signing credential are not the same thing.

The application may ask the secure hardware to generate a new private key that never leaves the TEE or StrongBox. The attestation system then signs information about that key using an attestation credential trusted by the verifier.

That distinction matters because the term "Keybox" usually refers to the attestation credential, not to every private key created by Android Keystore.

What About SafetyNet and Play Integrity?

SafetyNet Attestation historically provided a higher-level device integrity verdict and exposed results such as ctsProfileMatch. SafetyNet Attestation has since been retired and replaced by the Play Integrity API.

Play Integrity should not be treated as another name for Android Key Attestation. They are related parts of the Android trust ecosystem, but they are different systems.

Android Key Attestation exposes a certificate chain that a verifier can inspect directly. Play Integrity gives an application a server-backed integrity verdict produced by Google's infrastructure.

Android Key Attestation:

App
 |
 v
Keystore / KeyMint
 |
 v
Attestation certificate chain
 |
 v
App developer's verifier


Play Integrity:

App
 |
 v
Play Integrity API
 |
 v
Google infrastructure
 |
 v
Integrity verdict
 |
 v
App developer's backend

This distinction becomes increasingly important as Android moves toward RKP.

Chapter 2: Understanding the keybox.xml Format

The name keybox.xml is commonly used for an XML representation of attestation provisioning material. A file in this format may contain a private attestation key and the certificates associated with it.

A simplified example looks like this:

<Keybox>
    <Key algorithm="ecdsa">

        <PrivateKey format="pem">
            -----BEGIN EC PRIVATE KEY-----
            [PRIVATE KEY DATA]
            -----END EC PRIVATE KEY-----
        </PrivateKey>

        <CertificateChain>

            <Certificate>
                -----BEGIN CERTIFICATE-----
                [ATTESTATION CERTIFICATE]
                -----END CERTIFICATE-----
            </Certificate>

            <Certificate>
                -----BEGIN CERTIFICATE-----
                [INTERMEDIATE CERTIFICATE]
                -----END CERTIFICATE-----
            </Certificate>

            <Certificate>
                -----BEGIN CERTIFICATE-----
                [ROOT OR ADDITIONAL CHAIN CERTIFICATE]
                -----END CERTIFICATE-----
            </Certificate>

        </CertificateChain>

    </Key>
</Keybox>

If you possess an XML file containing a PEM private key, then that copy of the private key is obviously exportable. Anyone who obtains the file can obtain the key material stored inside it.

However, there is an important correction to a common misconception:

A production Android phone should not be assumed to keep its factory attestation private key sitting in plaintext as a keybox.xml file on the normal Android filesystem.

Factory attestation credentials are provisioned into the device's secure KeyMint environment. Depending on the implementation, that may be a TEE-backed KeyMint instance or a StrongBox implementation.

The XML representation is useful as a provisioning format and is also widely used by Android community tools, but that does not mean the production device continuously reads a plaintext XML file from /data every time it performs attestation.

The Private Key

The private key is the sensitive part of the credential. In the legitimate provisioning model, the goal is for the attestation private key to be available to secure hardware without exposing the raw key to normal Android applications or the Android kernel.

The Certificate Chain

The certificate chain connects an attestation signing key to a root that the verifier trusts.

A simplified chain might look like this:

Attestation certificate
        |
        v
Intermediate CA
        |
        v
Trusted attestation root

But certificate chains should not be judged purely by counting certificates.

There is no universal rule that says every legitimate Android attestation chain must contain exactly three certificates. Different provisioning generations, certificate hierarchies, and root transitions can result in different chain structures.

A verifier should instead validate things such as:

• Certificate signatures
• Certificate validity periods
• The relationship between each issuer and subject
• The trusted root
• The Android Key Attestation extension
• The expected security level
• Revocation status where applicable

This has become especially relevant in 2026 because Google's Android Key Attestation infrastructure is going through a root certificate transition. Verifiers should not hard-code assumptions based on one historical root or one fixed chain length.

Chapter 3: TEE, StrongBox, and Hardware-Backed Keys

Modern Android devices rely heavily on isolated execution environments for cryptographic operations.

The most common one is the Trusted Execution Environment, or TEE.

The TEE runs separately from the normal Android operating system and is protected by hardware-enforced isolation. On many devices it hosts KeyMint, which is responsible for creating and using hardware-backed cryptographic keys.

This does not mean a TEE is magically invulnerable. TEE implementations are software and firmware, and vulnerabilities have existed in secure-world components before. The important property is that compromise of normal Android should not automatically expose secrets held by the TEE.

StrongBox

StrongBox provides an even more isolated implementation of Android's hardware-backed keystore requirements.

StrongBox is normally implemented using dedicated secure hardware with its own protected execution environment, cryptographic capabilities, secure storage, random number generation, and resistance to certain physical attacks.

On supported devices, Android applications can specifically request StrongBox-backed keys.

The practical difference is simple:

Software key
    |
    v
Android process memory


TEE-backed key
    |
    v
Secure world KeyMint


StrongBox-backed key
    |
    v
Dedicated secure hardware

In the latter two cases, the private application key can remain non-exportable even if Android itself is compromised.

Chapter 4: Where the Legacy Provisioning Model Went Wrong

If production attestation keys were protected by secure hardware, how did leaked Keyboxes become such a large problem?

The important answer is that the weakness was not simply "root can copy keybox.xml from every phone."

The real issue was broader: factory provisioning required sensitive attestation credentials to exist somewhere before they reached secure hardware.

A simplified factory provisioning process looks like this:

Attestation credential infrastructure
        |
        v
OEM or manufacturing provisioning system
        |
        v
Factory provisioning process
        |
        v
Device secure hardware
        |
        v
KeyMint / StrongBox

Once the credential has been correctly installed into secure hardware, extracting it from a properly implemented device should be difficult.

But before and during provisioning, credentials may pass through manufacturing infrastructure, provisioning servers, factory systems, internal tooling, test environments, or other privileged components.

If valid provisioning material leaks anywhere in that chain, the attacker may no longer need to defeat the secure hardware of an individual phone.

That is a fundamentally different problem from extracting a private key directly from a TEE.

Shared Attestation Keys

There is another historical factor that made leaks especially damaging.

Android's privacy requirements discouraged manufacturers from giving every device a permanently unique attestation signing identity that could easily be used for tracking.

Factory attestation keys could therefore be shared across large groups of devices or a device SKU.

This improved privacy, but it also increased the blast radius of a credential leak.

One credential
      |
      +---- Device 1
      |
      +---- Device 2
      |
      +---- Device 3
      |
      +---- ...
      |
      +---- Large device population

If the shared credential escaped the legitimate provisioning system, revoking it could potentially affect many real devices.

This is one of the problems Remote Key Provisioning was designed to address.

Chapter 5: Leaked Keyboxes and the Resale Market

Once factory attestation credentials began appearing outside legitimate provisioning environments, a resale ecosystem formed around them.

This market is difficult to evaluate because two XML files can look almost identical while having very different histories.

A Keybox may be:

• A duplicate of a publicly circulated credential
• A credential that has already been revoked
• An expired credential
• A malformed certificate chain
• A certificate paired with the wrong private key
• A credential copied from another source and resold repeatedly
• Material originating from a provisioning environment rather than an end-user device

The XML format alone cannot tell you the complete history of the credential.

This is why claims such as "private," "fresh," "unused," or "unique" should not be accepted purely because a seller says so.

File Reselling vs. Provisioning Access

There is also an important conceptual difference between someone possessing one credential and someone having access to a provisioning source.

Leaked credential:

one private key
+
one certificate chain


Provisioning capability:

provisioning infrastructure
+
credential issuance material
+
device or product configuration

The second represents a much more serious security problem because it may allow multiple apparently independent credentials to originate from the same compromised source.

This is also why revocation systems and server-side abuse detection matter. A certificate may be cryptographically valid while still being considered untrustworthy by the service evaluating it.

Chapter 6: Verifying a Keybox Properly

If you are researching Android attestation credentials, validation should go further than checking whether an XML file parses successfully.

I built the Keybox Checker to make this kind of inspection easier. The analysis is performed locally in the browser so the private key does not need to be uploaded for basic certificate inspection.

A useful Keybox analysis should include at least the following checks:

• Private Key Match: Verify that the private key corresponds to the public key in the expected certificate.
• Certificate Signatures: Verify every certificate relationship in the chain rather than assuming the chain is valid because the PEM blocks look correct.
• Validity Period: Check the notBefore and notAfter dates.
• Attestation Extension: Parse the Android Key Attestation extension where present.
• Security Level: Inspect whether the attestation reports software, TEE, or StrongBox security levels.
• Root Trust: Determine whether the chain terminates at an expected Android attestation trust anchor.
• Revocation Information: Check known revocation information where available.
• Duplicate Detection: Compare certificate or public-key fingerprints against previously observed credentials.
• Chain Structure: Report the complete chain without treating a specific certificate count as automatic proof of authenticity or fraud.

Why Certificate Count Alone Is Not Enough

An older rule of thumb was that a legitimate Keybox should contain a fixed number of certificates. That is too simplistic.

The important question is not:

Does this chain contain exactly three certificates?

The important questions are:

Does every signature verify?

Does the private key match the certificate?

Is the attestation extension valid?

Does the chain terminate at an expected trust anchor?

Is the credential expired or revoked?

Does the reported security level make sense?

This matters even more now because Android's attestation certificate infrastructure evolves over time.

For example, Google introduced a new Android Key Attestation root that began signing attestation certificate chains on February 1, 2026. Verification software needs to account for legitimate root transitions rather than assuming one historical chain will exist forever.

Never trust a Keybox based on appearance alone. Parse it, verify it cryptographically, and treat server-side acceptance as a separate question from certificate validity.

Chapter 7: Remote Key Provisioning and DICE

Remote Key Provisioning is Android's answer to many of the weaknesses of long-lived factory attestation credentials.

RKP first appeared in Android 12. Android 14 moved major parts of remote provisioning into an updateable Mainline module, and Android 15 requires devices to implement Remote Key Provisioning.

The central idea is straightforward:

Instead of relying indefinitely on a long-lived factory attestation certificate, generate keys in secure hardware and provision shorter-lived attestation certificates remotely.

A simplified RKP architecture looks like this:

TEE / StrongBox
      |
      | generates secure key material
      v
KeyMint / IRPC
      |
      | creates certificate request
      v
Remote provisioning service
      |
      v
Provisioning backend
      |
      | validates device evidence
      v
Attestation certificate
      |
      v
Device secure environment

No Exportable Factory Key Required for Normal RKP Operation

The important improvement is not simply that an XML file disappeared.

The more important change is that the attestation private keys used by RKP are generated within secure hardware and are designed to remain there.

The remote side provides certification for those keys instead of requiring the same long-lived factory credential to be used indefinitely.

Shorter-Lived Certificates

RKP provides per-app ECDSA P-256 attestation certificates that are shorter-lived than traditional factory-provisioned attestation certificates.

This changes the economics of credential compromise.

With a long-lived leaked credential, an attacker may potentially retain value until that credential is explicitly revoked.

With remotely provisioned credentials, the platform can rotate certificates and update provisioning policy without physically recalling devices.

DICE

Modern RKP can also use DICE, the Device Identifier Composition Engine, to establish a stronger hardware-rooted identity.

DICE starts much earlier than Android userspace.

A simplified chain looks like this:

Chip ROM
   |
   | device secret
   | firmware measurement
   v
Boot stage identity
   |
   | next firmware measurement
   v
Next boot stage identity
   |
   v
TEE identity
   |
   v
KeyMint identity

The initial secret, known as the UDS, is tied to the hardware. Each boot stage derives a new Compound Device Identifier, or CDI, using measurements and configuration from the next stage.

This allows the resulting DICE chain to describe how the device reached its current trusted software state.

On modern Android implementations, the secure-world DICE chain exposed through IRemotelyProvisionedComponent can include stages corresponding to the bootloader, TEE, and KeyMint trusted application.

This is much stronger than simply asking Android userspace to report whether the device is secure.

RKP Does Not Make Attestation Invulnerable

It is tempting to describe RKP as the final solution to attestation attacks, but that would be overstating it.

No security system should be described as impossible to compromise.

RKP significantly reduces the value of stealing static factory attestation credentials and moves more of the trust decision toward hardware-rooted identity, remotely managed provisioning, shorter credential lifetimes, and server-side policy.

That raises the difficulty of persistent compromise considerably.

Chapter 8: Play Integrity and Key Attestation Are Not the Same Thing

This is probably the most important distinction to understand in 2026.

A valid Android attestation certificate chain does not automatically mean a device will receive MEETS_STRONG_INTEGRITY.

Play Integrity is a Google-operated service that combines hardware-backed security information with additional platform and server-side signals.

On Android 13 and newer, MEETS_DEVICE_INTEGRITY requires hardware-backed evidence that the device is genuine and certified, the bootloader is locked, and the loaded Android operating system is a certified manufacturer image.

MEETS_STRONG_INTEGRITY goes further.

On Android 13 and newer, Strong requires:

• MEETS_DEVICE_INTEGRITY
• A recent Android OS security update
• A recent vendor security update
• The required device partitions to have security updates within the last year

On Android 12 and older, the Strong definition is different and primarily depends on hardware-backed boot integrity rather than the same recent-update requirement.

This means the modern trust decision cannot accurately be reduced to:

Valid Keybox = Strong Integrity

The actual system is closer to:

Hardware-backed evidence
        +
Certified device state
        +
Verified boot state
        +
Security patch state
        +
Google server-side evaluation
        |
        v
Play Integrity verdict

This is also why Android Key Attestation research and Play Integrity research should be discussed separately even though the underlying security technologies overlap.

Conclusion: The Attestation Model Is Changing

The Keybox story is an important part of Android security history, but the common explanation of that story is often oversimplified.

The weakness was not that every Android phone stored a plaintext keybox.xml file that could be copied with root.

The deeper problem was the dependency on long-lived factory provisioning credentials and the consequences when those credentials escaped the environments that were supposed to protect them.

Secure hardware such as TEE and StrongBox still matters enormously. Hardware-backed application private keys can remain protected even when Android itself is compromised. The challenge with legacy attestation credentials was what happened before those credentials reached secure hardware and what happened if the provisioning source itself was compromised.

Remote Key Provisioning changes that model.

RKP moves toward hardware-generated attestation keys, shorter-lived remotely provisioned certificates, server-managed credential rotation, and stronger hardware identity through technologies such as DICE.

That does not make Android attestation impossible to attack. It does mean that attacks based purely on copying and endlessly reusing static attestation credentials become much less sustainable.

For researchers and Android enthusiasts, the interesting part of the next generation is no longer just the contents of a keybox.xml file. The real questions are now deeper:

• How does KeyMint establish hardware-backed trust?
• How is verified boot state represented in attestation?
• How does RKP authenticate a real device?
• How does DICE bind firmware measurements to device identity?
• How does Google combine these signals when producing Play Integrity verdicts?

Those are the areas where Android attestation is heading.

For inspecting legacy attestation material, my Keybox Checker remains available, and the Keybox Hub can be used as a reference for community research.

The important thing is to understand what a certificate proves, what it does not prove, and how quickly the Android trust model is evolving beyond the old factory Keybox era.