The keys to every US driver's license barcode were sitting in the DMV lobby

5 min read 1 source clear_take
├── "The root cause is a category error: AAMVA treats signing keys like guarded code-signing keys, but they're distributed on sample cards handed out freely"
│  └── Ryan Chapman (ryan.science) → read

Chapman argues the vulnerability isn't a cryptographic flaw in ECDSA itself, but a fundamental misunderstanding of the operational threat model. States produce sample licenses for training and reference materials that carry signatures from the real production key rather than test keys, exposing what should be a tightly-guarded secret through routine DMV outreach.

└── "Physical driver's license forgery is now trivially possible for anyone with sample cards and patience"
  ├── Ryan Chapman (ryan.science) → read

Chapman demonstrates the attack requires only a camera and enough sample barcodes to exploit ECDSA nonce weaknesses — no data breach, insider, or side channel needed. He published proof-of-concept forgeries with arbitrary identity data that verify cleanly against states' published public keys, meaning TSA, retailers, and bars have no cryptographic way to distinguish forged barcodes from real ones.

  └── @Ryan5453 (Hacker News, 256 pts) → view

By submitting the walkthrough to Hacker News where it received 256 points and 130 comments, the submitter amplified the argument that this is a practical, reproducible attack rather than a theoretical concern. The strong engagement signals community agreement that the demonstrated forgery capability represents a real-world break of the AAMVA trust model.

What happened

Ryan Chapman, writing on ryan.science, published a walkthrough of how he recovered the ECDSA private keys that several US states use to sign the PDF417 barcode on the back of every driver's license. The attack didn't require a data breach, an insider, or a side channel — it required a camera and patience.

US driver's licenses follow the AAMVA (American Association of Motor Vehicle Administrators) DL/ID Card Design Standard. On the back of the card, a PDF417 2D barcode encodes the cardholder's data — name, DOB, address, license number, class — along with a digital signature over that data. The signature is an ECDSA signature using a per-state private key; the corresponding public keys are distributed to relying parties (TSA, retailers, bars, financial institutions) so they can verify the barcode wasn't tampered with. That's the whole trust model: states hold the private key, everyone else verifies.

The problem is that states also produce *sample* licenses — the ones on DMV posters, in employee training decks, on the AAMVA's own reference materials, and printed as demonstration cards handed out to law-enforcement trainees. Chapman found that in multiple states, the sample license carries a valid signature produced by the *real* production key, not a throwaway test key. Given enough sample barcodes signed by the same key, and given the ECDSA math (which leaks the private key spectacularly if nonces are reused or if you have enough signatures and any weakness in nonce generation), the key falls out.

He published proof-of-concept forgeries: valid-signing barcodes for arbitrary identity data, verifying cleanly against the state's published public key.

Why it matters

The naive read is "driver's license fraud got easier," but the real story is a category error that shows up over and over in identity systems. AAMVA's design treats the signing key like a code-signing key — something a small number of trusted operators guard carefully — but states treat sample IDs like marketing collateral, printed on posters and photographed thousands of times. Those two mental models never met, and the gap between them is the whole vulnerability.

The underlying crypto is fine. ECDSA over P-256 is not broken. What's broken is that the same key material is being used to sign both "this is a real Jane Smith" and "this is our poster demo," and the poster demo is a public artifact. There is no version of secret-key hygiene that survives "we printed a signed message from the key on a 4-foot vinyl banner in the DMV lobby."

Compare this to how the web PKI handles the same problem. When Let's Encrypt or DigiCert issues a test certificate, it's issued from a test intermediate that chains to a test root that no browser trusts. The production hierarchy and the demo hierarchy are cryptographically separated at the root. AAMVA has no equivalent separation — there's one key per state, and it signs everything. A test-key hierarchy would have cost nothing to design and would have made this class of attack impossible.

The blast radius is uncomfortable. Any system that treats a valid barcode signature as strong evidence of authenticity — retailers doing age verification, bars doing ID checks with scanner apps, banks doing KYC at account opening, cannabis dispensaries, online age-gated services that require ID upload, and, per Chapman, TSA's own barcode readers — is now trusting a signature that a determined amateur can produce. Physical ID inspection still catches most fakes because the holograms, microprinting, and UV features are hard to reproduce. But a growing share of ID checks are barcode-scan-only, especially in unattended kiosks and app-based flows, and those checks now have a much weaker floor than their operators believe.

What this means for your stack

If you're building anything that ingests a driver's license — KYC onboarding, age gating, identity proofing, fraud scoring — the practitioner takeaway is blunt: treat the AAMVA barcode signature as a weak signal, not a strong one. It was never designed to be the last line of defense, but a lot of production systems have quietly promoted it to that role because it's cheap, offline-verifiable, and doesn't require a call to a state DMV API.

Concretely: barcode signature validity should be one input among several, not a gate. Pair it with a document scan (front + back) that runs template matching for state-specific security features, a liveness check against the cardholder, and cross-reference against an out-of-band data source (credit-header data, phone-carrier records, or a state DMV lookup where available). Vendors like Persona, Onfido, Socure, and Jumio already do most of this — if your integration is only checking the barcode CRC and the signature, you're using ~10% of what those platforms offer. If you rolled your own "we just parse the PDF417 and check the signature" flow to save money, you now have a fraud surface with a documented, published exploit.

There's also a disclosure and remediation angle. Rotating a state's driver's license signing key is not like rotating a TLS cert. Every scanner in the field — TSA lanes, bars, retail POS, government terminals — holds a copy of the public key, often burned into firmware or shipped in an infrequently-updated app. A key rotation means every existing valid license needs to be re-signed or reissued, or verifiers need to accept both keys during a long transition. States will almost certainly punt on this and hope nobody notices, which means the exploit is likely to remain viable for years.

Looking ahead

The mobile driver's license (mDL) standard, ISO/IEC 18013-5, is the intended successor and it does separate demo and production credentials properly, uses selective disclosure, and supports online revocation. But mDL adoption is a decade-long project, and in the meantime a hundred million plastic cards are in wallets with signatures that no longer mean what verifiers think they mean. The lesson for anyone designing an identity system is older than PKI: if your threat model assumes a key is secret, don't print signed messages from that key onto posters. Sample data is production data the moment it's signed with a production key. Chapman's writeup is the kind of thing that should be required reading for anyone building offline-verifiable credentials, because the failure mode isn't in the algorithm — it's in the operational seam between "crypto" and "marketing."

Hacker News 270 pts 137 comments

Keys Not Included: recovering the signing keys for US driver's license barcodes

→ read on Hacker News
yencabulator · Hacker News

> how to use the DMV's public key to check whether a California ID is real.That's not what the signature guarantees, though. It says the combination of textual information on the card is *someone's* valid driver's license. The signature doesn't even cover the photo! It ju

bzmrgonz · Hacker News

It baffles that people think it's a bad thing to disclose a public key. That's their purpose actually. Sure we now have the post quantum computer threat, and some state actors are harvesting keys, but quantum computer is going to disrupt so much, that Id verification won't even matter

dmurray · Hacker News

This is a great investigation but I have two small nits:> the ZNB field is not empty and not garbage: it contains a well-formed 71-byte DER ECDSA signature, correctly Ascii85-encoded, with the right prefix and a plausible length. But it fails the cryptographic check instantly, because it was sign

KingMachiavelli · Hacker News

All of this is nearly pointless unless the photo itself is in the barcode and also signed. You only need a leak of a few hundred real IDs to cover all of the identifiable characteristics (hair, eye, skin color, approx height and weight). Leak a few hundred thousand a year and now you can’t even flag

bob1029 · Hacker News

I think mDL is going to be a pretty big deal in some industries (e.g. banking). Apple announced an ecosystem around this at WWDC25. Very soon we are going to be in a world where you walk into a bank to open/maintain an account and the following occurs:1. The bank emails/SMSes the customer

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.