What is a keybox.xml? Android key attestation explained

The short version

A keybox is the bundle of attestation credentials an Android device uses to prove, cryptographically, that it is a real device with hardware-backed security. In the rooting community the word almost always means keybox.xml: an XML file containing a private key and the X.509 certificate chain that connects that key to Google's attestation root. Modules such as TrickyStore load this file so that a rooted or bootloader-unlocked phone can still answer attestation challenges the way an untouched phone would, which is what makes the STRONG Play Integrity verdict possible.

Because a keybox is only useful while Google trusts it, the interesting part is not the file format but the trust model around it. That is what this article covers.

What key attestation actually does

Android has had hardware-backed key attestation since Android 7 (Keymaster 2), and it is the mechanism behind every "is this device genuine?" check. The flow looks like this:

1. An app asks the Android Keystore to generate a key pair and to attest it, passing a random challenge.
2. The Keystore forwards the request to KeyMint, the hardware abstraction layer that talks to the Trusted Execution Environment (TEE) or a StrongBox secure element.
3. The secure hardware generates the app's key and signs an X.509 certificate for it using a separate attestation key that was provisioned into the device at the factory.
4. The certificate carries an attestation extension with facts the hardware vouches for: the challenge, the verified-boot state, whether the bootloader is locked, the OS version and security patch level, and how the key is protected.
5. The app sends the chain to its server. The server verifies each signature up to Google's published root certificate, checks that no certificate in the chain is revoked, and reads the extension.

The key point is that the app's key and the attestation credential are two different things. The attestation credential is what a keybox contains. If you control it, you control what the certificate chain says about the device.

What is inside a keybox.xml

A keybox file is small, usually 10 to 20 KB, and has a fixed shape. A simplified example:

<?xml version="1.0"?>
<AndroidAttestation>
  <NumberOfKeyboxes>1</NumberOfKeyboxes>
  <Keybox DeviceID="...">
    <Key algorithm="ecdsa">
      <PrivateKey format="pem">
-----BEGIN EC PRIVATE KEY-----
...
-----END EC PRIVATE KEY-----
      </PrivateKey>
      <CertificateChain>
        <NumberOfCertificates>3</NumberOfCertificates>
        <Certificate format="pem">...</Certificate>   <!-- leaf / attestation cert -->
        <Certificate format="pem">...</Certificate>   <!-- intermediate -->
        <Certificate format="pem">...</Certificate>   <!-- Google root -->
      </CertificateChain>
    </Key>
    <Key algorithm="rsa">...</Key>
  </Keybox>
</AndroidAttestation>

• PrivateKey is the sensitive part. Whoever holds it can sign attestation certificates that the rest of the chain vouches for. Most keyboxes ship both an ECDSA (P-256) and an RSA key.
• CertificateChain goes from the attestation certificate up to Google's root. Chains are commonly three certificates long, but that is convention, not a rule; verifiers walk whatever chain they are given.
• DeviceID is a free-form label. Some channels replace it with a watermark; it has no cryptographic meaning.

Two details are worth knowing when you inspect files. Watermark comments (<!-- ... -->) spliced into the PEM bodies are harmless; parsers strip them. And the certificate serial numbers are what Google's revocation list refers to, which is why the repository page extracts them client-side to show live status.

Where keyboxes come from

Factory provisioning is the origin of every classic keybox. Before a phone leaves the manufacturer, an attestation key and chain are generated on provisioning infrastructure and injected into the device's secure hardware. That means, for a moment, the private key exists outside the hardware it is meant to protect. Provisioning servers, repair depots, contract manufacturers and firmware images have all leaked keyboxes over the years. Some OEMs also provisioned one keybox per batch or per SKU rather than per device, so a single leak covers thousands of phones.

Once a keybox is public it is copied everywhere: Telegram channels, GitHub gists, forum threads. Every copy signs chains that claim to be the same device, and that anomaly is one of the signals Google uses to revoke it. The next article goes into the revocation process in detail.

How TrickyStore uses a keybox

TrickyStore is a Zygisk module that hooks the keystore path on the device. When a target app requests an attested key, TrickyStore either rewrites the leaf certificate or generates a fresh chain, signed with the private key from /data/adb/tricky_store/keybox.xml, and fills the attestation extension with the values a locked, up-to-date device would report. The app's server verifies the chain, finds it rooted at Google, checks that nothing is revoked, and returns a STRONG verdict.

Without a keybox, TrickyStore falls back to a built-in software keybox that is not hardware-trusted, which is enough for DEVICE integrity on many setups but never STRONG. That is the whole reason valid keyboxes are in demand and why a repository that tracks revocation live saves people time.

Remote Key Provisioning and the future

Google's structural answer to leaked factory keys is Remote Key Provisioning (RKP), available since Android 12 and required on newer devices. With RKP the attestation key is generated inside the secure hardware and never leaves it. The device sends a certificate signing request to Google's provisioning service, and Google returns short-lived attestation certificates, tying them to firmware measurements through DICE. There is no long-lived factory secret to leak, and a compromised device gets its certificates rotated instead of a permanent key.

RKP does not retire the existing keyboxes overnight. Devices provisioned the old way keep working, and Google's root still signs both models. But it explains the trend: fewer new factory keyboxes appear, the ones that do get revoked faster, and long-term the community's spoofing approach will have to change.

Sources and further reading