Researcher recovers signature public keys from US driver's licenses
Ryan Fahey decoded the proprietary cryptographic scheme used by New York and Virginia in their PDF417 barcodes and recovered the public keys via an ECDSA key-recovery attack, exposing a six-month window in which not even California itself documented how to verify its own signatures.

Every American carries a PDF417 barcode on the back of their driver's license, in the format standardized by the AAMVA (American Association of Motor Vehicle Administrators): three-letter fields in plain text, such as DCS for last name or DBB for date of birth. It's a public, documented format, with no cryptographic protection on the data itself. The problem is that nothing prevents someone from manufacturing one of these codes with fake data: any scanner that knows how to read the AAMVA standard also reads a perfect clone.
Researcher Ryan Fahey had already argued, in an earlier post (Insecure by Design), that the AAMVA should require cryptographic signatures on this barcode, along the lines of what already exists in passports and in the mDL (Mobile Driver's License), an open standard verifiable by anyone. He noted that two states, New York and Virginia, already signed their codes with something proprietary, but without public documentation on how to verify it. A month later, he found a way to break that secrecy, and in the process also revealed a six-month gap in California's own official, open implementation.
The right way: California's Verifiable Credential Barcode
In October 2025, California announced it would start digitally signing one of the two barcodes on its new driver's license, information confirmed in an official DMV release. The ZC subfield, reserved by the AAMVA for jurisdiction-specific use, holds inside it a full credential in the W3C Verifiable Credential Barcode standard: data compressed with CBOR-LD and signed with the ecdsa-xi-2023 cryptosuite.
The design is clean. A bitstring selects which AAMVA fields go into the signature, they're formatted as code-plus-value, ordered, concatenated with line breaks, and hashed. The credential points to did:web:credentials.dmv.ca.gov, which resolves to a public JSON document on the DMV's official domain, containing the P-256 public key labeled #vm-vcb-1. California went further and published an open-source verifier with real examples of valid and revoked barcodes, so any developer can run the verification on their own, without depending on any state API.
The curious detail: between the October announcement and the publication of the technical documentation ("Verifying Digital Signatures on California DL/ID Documents", with April 2026 metadata), about six months passed during which the signature existed on the card, was public, but no one outside the DMV knew how to check it. In practice, the same problem as New York and Virginia, just a temporary one.
The opaque scheme: Canadian Bank Note and the ZNB field
Canadian Bank Note (CBN) manufactures documents for five US states: New York, Virginia, North Carolina, South Carolina, and Wisconsin. Fahey discovered that all five carry a digital signature, not just the two he had already suspected. The specific field (ZNB in New York, ZVA in Virginia) holds a string encoded in Ascii85. Decoding that layer leaves a binary blob that is a DER structure: a SEQUENCE with two 256-bit INTEGER values, exactly the canonical encoding of an ECDSA signature over the P-256 curve (secp256r1).
The blob's size varies between 70, 71, and 72 bytes depending on the card, which is a telltale signature of ECDSA: since r and s are pseudorandom integers, DER adds or removes a padding byte depending on the most significant bit of each. A fixed-size hash or a counter wouldn't vary like this. Across three real New York cards and six Virginia ones, all the blobs followed this pattern.
How a public key is recovered from signatures
ECDSA has a mathematical property documented in Certicom's SEC1 standard (SEC 1: Elliptic Curve Cryptography, section 4.1.6): given a (message, signature) pair, it's possible to compute candidates for the public key that generated it. A single signature produces a small set of candidates; with several signatures from the same signer, the real key is the only candidate common to all of them.
The practical obstacle was figuring out the exact message that had been signed, something documented nowhere. Fahey tried hundreds of thousands of ordering and formatting combinations until he realized (with help from a language model) that, unlike California, the signature field itself is part of what gets signed: the encoder fills the field with zeros of the same length, signs the entire payload including that placeholder, and only afterward overwrites it with the real signature. To verify, the placeholder has to be reconstructed.
In New York's case, the payload is 484 bytes long and the ZNB field occupies bytes 393 through 483. The verification procedure is:
payload_para_hash = payload[:393] + b"0" * 90 + payload[483:]
digest = sha256(payload_para_hash)
ecdsa_verify_p256(digest, assinatura_der, chave_publica)With this reconstructed message, three New York cards converged on a single key, confirmed across all three possible pairs; six Virginia samples converged on another, confirmed across all fifteen pairs. The recovered keys, in compressed P-256 format, were published by Fahey:
- New York (IIN 636001, ZNB field):
02851d63a281796be0ca11189f03028abf80e032838f83215889b9e708eac16482 - Virginia (IIN 636000, ZVA field):
02d0f2823d63c854566c5da2cb07e114dbad16f874c2422f74806fe3e2f4775f1d
It's important to note what this is not: a public key doesn't allow forging a signature, only verifying one. Fahey built a browser-based verifier that decodes the PDF417, interprets the AAMVA format, and checks the signature for the three states that have one (California, New York, and Virginia). Tested against a forged New York card, the clone reproduces the payload, subfields, and padding faithfully, and even has a well-formed signature blob in the right field, but it fails verification instantly because it was signed with an arbitrary key, not the state's.
Why most states don't do this, even though the engineering is ready
The most relevant point of the investigation is about distribution, not cryptography. IDEMIA manufactures documents for 31 of the 51 US jurisdictions and was the company that implemented California's open, verifiable scheme, under a twelve-year contract signed in 2022. Of the other 30 jurisdictions the same company serves, none has public evidence of verifiable signatures. Texas rolled out a driver's license redesigned by IDEMIA in August 2025 with features such as a variable optical window and laser star for REAL ID compliance, but with no mention of a digital signature. The engineering is ready and running in production in the country's largest state, but it hasn't spread.
What this teaches those building digital identity in Brazil
Brazil is already going through a similar discussion with the CNH Digital (Brazil's digital driver's license app) and the identities issued via Gov.br, Brazil's unified government services platform, which rely on QR codes and signatures tied to ICP-Brasil, Brazil's public-key infrastructure. The direct technical lesson from the American case is that signing a document isn't enough: if the verification specification (which fields go into the hash, in what order, with what encoding, where the public key lives) isn't published, the signature exists only on paper. A document verification system is, by definition, a public system: the private key stays with the issuer, but the algorithm and the public key need to be documented and accessible, the way California did with its did:web and open-source verifier.
For those developing integrations with Brazilian digital documents (reading CNH Digital QR codes, validating credentials via Gov.br, or any in-house system for issuing a signed badge/credential), the case serves as a negative checklist: don't reinvent a signed-message format without documenting it, don't let the signature field be part of the signed payload without recording that explicitly, and treat the public key and verification scheme as part of the system's public API, not as an implementation detail. The ECDSA key recovery Fahey applied isn't a new vulnerability (it has been in the SEC1 standard since 2009), but it shows that a scheme that's "secure through obscurity" on paper only lasts until someone patient enough decides to test it.
Translated from the Brazilian Portuguese original · Read the original
Perplexity swaps DynamoDB for in-house database and cuts latency by 5x
The company behind the AI-powered search engine migrated its serving layer to CobbleDB, an internal database written in Rust, and cut batch read latency by up to 5x while saving at least 20% on storage.