Why keyboxes get revoked, and how to check yours

If you have used a keybox for more than a few weeks you have seen the pattern: STRONG on Monday, DEVICE on Thursday, nothing changed on your side. The key was revoked. This article explains what that means mechanically, why it happens so quickly for public keys, and how to check any keybox in under a minute.

What "revoked" means

Google publishes a machine-readable list of attestation certificates it no longer trusts at android.googleapis.com/attestation/status. It is plain JSON: an entries object keyed by certificate serial number, each with a status (REVOKED or SUSPENDED) and a reason such as KEY_COMPROMISE, CA_COMPROMISE, SUPERSEDED or SOFTWARE_FLAW.

{
  "entries": {
    "6681152659205225093": { "status": "REVOKED", "reason": "KEY_COMPROMISE" },
    "8350192447815228107": { "status": "REVOKED", "reason": "SOFTWARE_FLAW" }
  }
}

Any verifier that follows Google's guidance, and Play Integrity certainly does, downloads this list and rejects a chain if any certificate in it appears there. The chain still verifies cryptographically; the signatures are fine and the dates are fine. Trust was simply withdrawn. For a rooted device this shows up as the verdict dropping from STRONG to DEVICE or BASIC, depending on what else the setup spoofs.

Revocation is per certificate, not per file. A keybox usually contains an ECDSA chain and an RSA chain; if the intermediate they share is revoked, both are gone at once. If only a leaf is listed, a different keybox from the same batch may survive a bit longer.

Why leaked keyboxes die so fast

A factory attestation key is meant to live inside one device, or at worst one production batch. The moment it is posted to a Telegram channel that assumption collapses, and several things start working against it:

• Volume. One credential suddenly attests thousands of "devices" with different models, regions and fingerprints. That is trivial to flag server-side.
• Checker spam. Every user runs Play Integrity checkers repeatedly to admire the green STRONG row. Each check is another attestation on the same key, from another IP, often against an app that only exists to test integrity.
• Automated harvesting. Public channels and repositories are easy to crawl. A keybox that is posted openly can be on the list before most people have downloaded it.
• Batch revocation. When Google identifies the source of a leak it often revokes the whole intermediate, which takes out every keybox from that OEM batch, including ones that were never shared.

The practical result is a lifetime measured in days to a few weeks for anything public, which is why the repository keeps an archive: you can see how long previous keys lasted, and you always have the newest one at the top.

How to check a keybox

On the device: Key Attestation

Install vvb2060's Key Attestation, add its package name (io.github.vvb2060.keyattestation) to TrickyStore's target.txt, and open it. The app requests an attested key, shows the chain, and reports whether the certificates are trusted and whether any are on the status list. A revoked keybox shows a clear "revoked" line. This is the most direct test because it inspects exactly what Play Integrity would see.

On the device: Play Integrity checker

Apps such as Play Integrity API Checker call the real Play Integrity API. If a keybox you believe is valid only yields MEETS_DEVICE_INTEGRITY, the keybox is revoked or was never read; see the troubleshooting section of the setup guide. Do not run this every hour; see the next section.

Anywhere: compare serial numbers

Every certificate in the XML has a serial number. Extract them and look them up in Google's list. On a computer:

# serials of every cert in keybox.xml
grep -A200 "BEGIN CERTIFICATE" keybox.xml | \
  awk '/BEGIN CERTIFICATE/{c=""} {c=c"\n"$0} /END CERTIFICATE/{print c | "openssl x509 -noout -serial"}'

# is any of them revoked?
curl -s https://android.googleapis.com/attestation/status | grep -i "<serial>"

The repository page does exactly this in the browser for every archived keybox, on every page load, so the "Revoked" label there is never more than one refresh old.

Revoked is not expired

Two different things get called "invalid":

A keybox showing "valid until 2045" in a certificate viewer tells you nothing about whether it works today. Only the status list does.

Making a keybox last longer

You cannot prevent revocation of a key that is already public, but you can avoid accelerating it, and you can avoid being the reason a private key becomes public:

• Limit targets. Only list the apps that actually need attestation in target.txt. Every extra app that attests is another signal.
• Stop re-checking. Verify once after setup, then leave the checkers alone. Your bank checks when you open the app; it does not need a warm-up.
• Keep the spoofed patch level plausible. A key that reports a security patch from 2022 on a device claiming to be current is inconsistent. Use security_patch.txt sensibly.
• Do not republish. If you obtain a keybox that is not yet public, posting it "to help" is what gets it revoked.
• Prefer per-device keys when you can. A keybox that only you use has the lowest exposure. Batch keys shared by a whole channel are convenient but short-lived.

When yours is revoked

Download the newest keybox marked Strong from the repository, replace /data/adb/tricky_store/keybox.xml, and you are done; TrickyStore picks up the new file without a reboot. If you would rather not do this by hand each time, the AlwaysStrong module fetches the current keybox from this repository with one tap of its action button.

Sources and further reading