const {P,H2,H3,Callout,Code,Ul,Related,PostHead}=window;
function Article(){
return <>
<PostHead cat="/ANDROID" date="2026-08-24" title="Keybox and attestation are not pinning" lede="A keybox is attestation key material. Play Integrity is a verdict about a device. Neither is SSL pinning. Leaked boxes are a provisioning theft problem. We do not traffic in them, and we do not write generators."/>
<P>People mash three words together: pinning, Play Integrity, keybox. They are not the same control. On an authorized Android review we name which one the app actually uses, where the check runs, and whether the server believes it.</P>
<Callout>We do not provide leaked keyboxes, import steps, Magisk modules, or “how to pass STRONG.” This note is what the words mean and what belongs in a report.</Callout>
<H2>Attestation, in one paragraph</H2>
<P>Android key attestation: a key in TEE or StrongBox, a certificate chain that should root at the vendor/Google provisioning CA, a blob the app can send to <em>its server</em>. The server is supposed to parse the chain, check revocation, and decide whether this device is the class of device you wanted. If only the app looks at the verdict and then sets a boolean, you have a client check. Client checks are not a control. We will say that. We will not demonstrate a bypass here.</P>
<H2>What “keybox” means in the wild</H2>
<P>In 2024–2026 slang, a keybox is the provisioned attestation key plus its certificate chain — the material a legitimate device uses to mint attestation. When that material is extracted from a device or a factory leak and reused elsewhere, software can pretend to be hardware it is not. That is stolen provisioning, not a clever RE trick.</P>
<P>For a product team: if your backend accepts an attestation chain without checking it against a current, vendor-published root and revocation set, you are trusting a PDF. If you do not check at all, you are trusting the APK. Stolen keyboxes are then your problem whether or not you ever heard the word.</P>
<H2>Play Integrity</H2>
<P>Google’s verdict API (the SafetyNet successor). The app asks Google; Google returns a token; <em>your server</em> is supposed to verify that token. MEETS_DEVICE_INTEGRITY vs MEETS_STRONG_INTEGRITY is a product choice. We write which one you requested, whether the nonce is bound to the session, and whether a failing verdict still gets a session cookie.</P>
<Ul items={[
'Verdict only in the client → not a control.',
'Verdict on the server, nonce reused → replay.',
'Verdict on the server, chain not checked → you accepted a story.',
'No Integrity at all → say so. Empty is allowed. Pretend is not.'
]}/>
<H2>Pinning vs keybox vs Integrity</H2>
<Code lang="map.txt">{`SSL pinning     client TLS peer check     (this binary, this list)
key attestation  hardware key + chain     (server must verify)
Play Integrity   Google verdict token     (server must verify)
keybox (slang)   leaked/provisioned keys  (theft / factory leak)

A pinned, attested, Integrity-checked app
can still be a bad product if the API
accepts an old debug build with none of those.`}</Code>
<H2>What we do on the desk</H2>
<P>jadx: Integrity API calls, nonce, where the token is sent. apktool: Play services version assumptions. Server questions go to the customer’s API owners — we do not scrape Google’s private roots out of a phone to “help.” Combination with <a href="post-android-pinning.html">pinning</a>: find both, confuse neither.</P>
<P>If the SOW is “does a modified lab install still get a production token,” that is a scoped server test. The answer is yes or no. The write-up is for the customer. This site does not carry the lab notes.</P>
<Related items={[
['post-android-pinning.html','SSL pinning is a client opinion'],
['post-android-desk.html','Android on the authorized desk'],
['post-four-gates.html','Four gates']
]}/>
</>;
}
window.Article=Article;
mountPost();