Get the two builds
Both APKs contain the same application code, built from the same commit against the same server URL and the same certificate pins. The only difference is which key signed them. That single difference is what the server detects — and it is the whole claim this POC exists to demonstrate.
Installing them
Download both from the release, then on a phone with USB debugging on:
What to expect
Open Attest POC on the phone and tap the steps in order. With the genuine build you get a credential and an accepted transaction. With the repackaged build, step 2 fails with APP_SIGNATURE_MISMATCH — even though the phone produced a perfectly valid StrongBox attestation chain. Watch it land under Live data.
Process flow
Pick any step to see what it does, what it rejects, and the actual source that implements it. Highlighted lines are the ones that matter.
Key custody
Three different keys are involved and they are easy to conflate. The server holds a private key for none of them. Everything below is read live from the running server.
The app signing key — how the server recognises a genuine build
Registered device keys — what the server stored
Pinned Google trust anchors
Devices & approval
Attestation proves a genuine app on genuine hardware. It cannot prove the device is one
you want — no attested device identity exists on any of the three platforms.
That judgement is made here, and until it is made the device cannot transact.
Approval matters most for Web credentials: a browser cannot attest the
code that asked for the key, so the assurance badge is the only thing standing in for
the signing-digest check the two native clients get.
Combined log
Server lines as they happen, interleaved with lines the phones report about their own side of each step. Device lines are self-reported and unverified — they are shown so the two halves of a flow can be read together, not as evidence of anything.
Live data
Registrations and transactions recorded by the running server.