top of page

7-9 OCT. 2026
BERLIN


( SPEAKER )
Arthur Bernier Jr.
DevRel Evangelist
Guardsquare
Arthur Bernier Jr. is a Developer Relations Engineer and Evangelist at Guardsquare, where he helps Android and iOS teams understand mobile app security and the attacks their apps actually face. Before Guardsquare he spent 15 years as a full-stack engineer, including as CTO of a VC-backed startup, and taught software engineering at General Assembly and Per Scholas. He is a U.S. Navy veteran and hosts the "It's Deeper Than Code" podcast, where he talks with engineers, founders and entrepreneurs about the parts of the job that don't show up in the codebase. Online he is known as Big Poppa Code.
Lightning talk
Android Hardware Attestation: How it Works and How it Fails
Your app asks the phone, "Are you a real, untampered device?" Android Key Attestation is part of how the phone answers: a signed statement, anchored to Google's attestation roots, about a newly generated key and selected device-state properties at the moment that key was created. When verified correctly on your server, it's one of the strongest device-trust signals you have on Android. It's also widely misunderstood, and attestation credentials can be compromised, revoked, or borrowed through a relay.
This talk covers attestation the way you'd actually deploy it as an engineer. First, we explain it: what the Android Keystore and Key Attestation are, how the TEE or StrongBox produces an attestation record and what its security level tells you, what Verified Boot adds, and what each field in that record proves and doesn't prove. Then we demonstrate it: generating a real hardware-backed key, pulling its certificate chain off the device, decoding the record, and verifying it on the server in the order Google recommends: chain, root, revocation, challenge, then your own policy. You'll see why client-side checks can't be trusted, watch a verifier reject replayed and mismatched challenges as well as untrusted chains, and see how to turn the result into a risk decision instead of a fragile pass or fail.
The second half is about how it fails. We'll go through the misconceptions that get teams burned: valid doesn't mean secure, failing doesn't mean malicious, and attestation is a snapshot, not the full picture of a device, session, or account. Then we look at attacks drawn from our team's research and incident work protecting production Android apps: compromised attestation credentials and the revocation race that follows, boot-chain weaknesses affecting particular device generations, and relay attacks that use a legitimate device as a remote attestation oracle. You'll leave with concrete guidance on how to make use of attestation, and recommendations for hardening your app to match the security model you actually need.
Every concept gets a plain-language explanation before we show it live, so you don't need a cryptography or Android internals background to follow along.
Key takeaways:
- What an attestation record actually proves, field by field, and what it doesn't.
- How to verify a chain on the server in the order Google recommends: chain, root, revocation, challenge, policy.
- Why a valid attestation can come from a compromised device (leaked credentials, boot-chain flaws, relays) and how to design around it.
- How to turn attestation into a risk score instead of a pass/fail gate.
bottom of page
