What does the root certificate check mean?

A real keybox chains to one of Google's attestation roots: the classic hardware root with subject serialNumber f92009e853b6b045, or the newer Remote Key Provisioning root, Key Attestation CA1. If the chain ends at the AOSP software attestation root, or at anything else, the keybox can never reach STRONG integrity.

What happens to a keybox I submit?

It is verified again on the server, stripped of comments and watermarks, re-written into a canonical form and published under community/ with a content-addressed filename. Duplicates are refused: the same key cannot be published twice, however it is packaged.

Can this tool tell me if a keybox is soft-banned?

No, and no checker can. Google's revocation list only names keys that have been formally revoked. A soft ban is a server-side decision at attestation time that leaves no public trace, so it can only be found by testing the key on a device.

Check a keybox

Q: Is my keybox uploaded anywhere?

No. Checking is entirely local: the file is read with FileReader and every certificate is parsed and verified with WebCrypto on your device. The only request the page makes on its own is for Google's public revocation list, which carries nothing of yours.

Drop one keybox.xml or a whole folder of them. You get the root certificate it chains to, every signature in the chain verified, whether the private key really belongs to its certificate, when it expires and whether Google has revoked it. Nothing is uploaded — this page has no upload endpoint at all. If you want to publish a keybox, that is what Add a keybox is for.

Drop keybox files here or click to choose — several at once is fine, only .xml is accepted

loading Google’s revocation list…

What gets checked

Is it a keybox?	The file must be `.xml`, valid XML, rooted at `<AndroidAttestation>` and contain at least one `<Keybox>` with a `<Key>` and a `<CertificateChain>`. Anything else is refused outright rather than half-graded.
Root certificate	The chain is followed to its root and the root’s public key is fingerprinted. Two roots count as genuine: the classic Google Hardware Attestation Root (subject `serialNumber=f92009e853b6b045`, RSA-4096) and the newer Key Attestation CA1 RKP root (ECDSA P-384, issued 2025-07-17). The AOSP software attestation root is recognised and rejected — it is public, so it can never pass hardware attestation.
Chain signatures	Every certificate is verified against the issuer shipped in the same file, using WebCrypto (RSA PKCS#1 v1.5 and ECDSA P-256/P-384). A single edited byte anywhere shows up as a broken link.
Private key	The private key is matched against the public key in its own leaf certificate. A keybox with a stripped or swapped key looks perfect everywhere else and signs nothing; this is the check that catches it.
Validity window	The earliest `notAfter` in the whole chain is the date the keybox stops working. RKP keyboxes routinely have two weeks left, which is normal but worth knowing before you install one.
Revocation	Every certificate serial is compared with Google’s attestation revocation list, fetched live through this site. One listed serial kills the whole keybox.

What no checker can tell you

A soft ban leaves no public trace. Google’s list only names keys that were formally revoked; a key that quietly stopped returning MEETS_STRONG_INTEGRITY looks perfectly clean here. The only way to find that out is to install the key and run a Play Integrity check — which is why the repository carries the maintainer’s own test grade next to Google’s verdict.

Questions

Is my keybox uploaded anywhere?

No. The file is read with FileReader and parsed in JavaScript on your device; signatures are verified with the browser’s built-in WebCrypto. The only request this page makes is a GET for Google’s public revocation list, which carries no part of your file. You can confirm all of it in the network tab, or read the checker source.

Why does it say my keybox expires in days, not years?

Because it is an RKP keybox. Remote Key Provisioning leaf certificates are issued for about two weeks at a time, so the file has a short shelf life by design. A classic hardware keybox from a real device usually has years on the clock.

The chain has a broken link — what does that mean?

One certificate’s signature does not verify against the issuer bundled in the same file. That is almost always an edited or hand-assembled keybox: someone spliced certificates from different chains together, or a byte got mangled while copying. Such a keybox fails attestation immediately.

It says “not revoked” but the key still fails. Why?

Revocation is only one of the ways a key dies. It may be soft-banned, the device fingerprint in your TrickyStore setup may not match, or the key may simply be too widely shared. Start with a freshly published key from the repository and see why keyboxes get revoked.