Attestation Object Explorer

Step 1 of 3

Load the revocation list

The revocation endpoint blocks cross-origin fetch(), so this has to be a manual hop:

Open android.googleapis.com/attestation/status in a new tab
Save the page — Cmd/Ctrl+S — as a .json file
Drop that file below

Drop status.json here

or click to browse

Step 2 of 3

Load the attestation dump

Run this Splunk query
Export the results as NDJSON
Drop that file below — big files stream in a background worker, the tab won't lock up

splunk query

index=identity_kubernetes_prod app=key-registry "event.request.path"="/attestation" "event.request.headers.user-agent"="*Titan*Mobile*"
| rex field=_raw "\"json_body\":\"(?<json_body_raw>.*?)(?<!\\\\)\""
| table _time json_body_raw

Drop dump.json here

or click to browse — NDJSON expected

Step 3 of 3

Chewing through the dump

0% 0 MB / 0 MB — rec/s ETA —

0lines seen

0pass

0fail

0skipped

0parse errors

Pass Criteria

Allow expired, not revoked (pre-RKP) Reject key stored in software (regardless of who signed the cert)

Revocation is checked across the whole chain (leaf, intermediates, root) and always fails, regardless of RKP status. RKP-expired always fails too — RKP certs are meant to be strictly time-checked.

A software-stored key is extractable on a rooted device no matter which hardware component signed its certificate, so this checks the key's own location only. Keys stored in software: 0

Trust Funnel

Issuance Volume Over Time

Pass vs Fail

RKP vs Pre-RKP vs Revoked

Root Trust Breakdown

Attestation Key Security Level

Where the key itself is stored. "Software" here is exactly what "Reject key stored in software" checks — the keymaster combo panel below is for reference only.

Attestation Key / Keymaster Combos

Shows who signed the cert alongside where the key lives. A hardware signer doesn't change whether a software-stored key gets rejected.