The Missing Key in a Driver's License Barcode

The back of a U.S. driver's license looks like a dense black rectangle. Scan it and you get labels such as DAQ and DBA, followed by values that look more like a form than a security system. Yet tucked into the state-specific part of that same driver's license barcode can be a cryptographic signature: a compact mathematical seal over the data.

How can a verifier check a driver's license barcode when the issuer never publishes its public key? The answer is a small tour through the PDF417 format, a useful property of ECDSA, and one surprisingly literal placeholder character. It also leads to a broader lesson: a signature only becomes useful when other people know what it covers and where to find the key.

A familiar barcode with a private corner

Most U.S. state licenses use PDF417, a stacked two-dimensional barcode made from rows of small bars. Its contents follow a format maintained by the American Association of Motor Vehicle Administrators, usually shortened to AAMVA. Much of the payload is readable text: three-letter field codes identify names, dates, license numbers, document identifiers, and other details.

An issuer identification number, or IIN, tells a scanner which jurisdiction produced the document. A generic reader can process the fields it understands and ignore the rest. That flexibility comes from state-specific subfiles, sections whose names begin with Z followed by a state or vendor letter. Virginia, New York, and California use different versions of this reserved space for extra information, including digital security features.

This is a sensible extension point. The barcode remains compatible with ordinary AAMVA software, while a state can add data that only a specialized verifier knows how to interpret.

When barcode garbage resolves into a signature

In several licenses produced with Canadian Bank Note security features, the interesting field first appears as a printable string. It is encoded with Ascii85, a way to represent arbitrary binary bytes using ordinary characters. Ascii85 is not encryption; it is packaging. Remove that layer and the bytes form a DER structure.

DER, short for Distinguished Encoding Rules, is a strict binary encoding used to represent structured data. Here, the structure is a SEQUENCE containing two integers named r and s. That pair is the standard wire form of an ECDSA signature.

ECDSA means Elliptic Curve Digital Signature Algorithm. It is a public-key signature system built from elliptic-curve mathematics, and these licenses use the P-256 curve, also known as secp256r1. A P-256 signature contains two values that are each roughly 256 bits wide. DER may add a leading byte when an integer would otherwise look negative, so the complete signature can occupy 70, 71, or 72 bytes. That changing length is a useful clue that the blob is a signature rather than a counter or fixed hash.

The missing ingredient is not the private key. It is the public key. The private key must remain secret because it creates new signatures. The public key is meant to be distributed so anyone can check existing signatures.

The message was hiding in plain sight

A less familiar property of ECDSA makes this investigation possible. Given an exact message and a valid signature, a verifier can mathematically recover a small set of candidate public keys. This operation is called public-key recovery. One signature may leave several possibilities, but several signatures made by the same issuer usually leave one candidate that works every time.

The difficult part is knowing the exact message. ECDSA signs bytes, not the meaning a human assigns to those bytes. A different newline, field order, character encoding, or padding byte produces a different hash. SHA-256, the cryptographic hash function used in this construction, behaves like a fingerprint: change one input byte and the digest changes completely.

The crucial discovery was that the signature field was included in the signed payload. Before signing, the encoder filled that field with the character 0, repeated for the exact length reserved for the signature. It then signed the whole payload and overwrote the placeholder with the real signature. Verification restores the placeholder before hashing again.

The reconstruction looks like this in illustrative pseudocode:

# The offsets depend on the state and barcode implementation.
signing_bytes = payload[:start] + b'0' * signature_length + payload[end:]
digest = sha256(signing_bytes).digest

candidates = recover_public_keys(signature, digest, curve='P-256')
valid_keys = [key for key in candidates
 if verify(key, signature, digest)]

The offsets are not universal. They belong to a particular state's layout and vendor implementation. But once the signed bytes are reconstructed, each sample can produce candidate keys, and samples from the same jurisdiction can be compared. Recovering the public key does not let anyone forge a license. It only makes independent verification possible.

California publishes the missing instructions

California took a more transparent route with its redesigned cards. The Department of Motor Vehicles announced the design on October 1, 2025, including a digital security signature in one of the barcodes. Instead of hiding a proprietary signature in an undocumented field, California uses a Verifiable Credential Barcode.

A Verifiable Credential is a digitally signed claim whose structure and issuer can be checked by software. California compresses that credential with CBOR-LD, a compact binary form of Linked Data designed for environments where space matters. The proof uses ecdsa-xi-2023, a named cryptosuite, meaning a defined collection of rules for transforming, hashing, and verifying the credential. Its extra input binds selected data from the surrounding optical barcode to the credential itself.

A California verifier therefore has a documented sequence of work:

1. Extract the credential payload from the PDF417 barcode.
2. Decode the CBOR-LD bytes into the credential structure.
3. Reconstruct the protected barcode data.
4. Verify the ECDSA proof and its issuer.
5. Check a status list to see whether the credential has been revoked.

The issuer is identified with a did:web identifier. A DID, or decentralized identifier, is a standardized name for an entity and its verification material. In this case, did:web means the identifier resolves through a normal web domain and a well-known JSON document. No blockchain is required; the important detail is that the DMV publishes the public key and gives verifiers a defined place to retrieve it.

California also provides a public verifier and an open-source software development kit. The result is more than a signature embedded in plastic. It is a complete verification story: format, covered fields, key location, cryptographic procedure, test data, and revocation behavior.

What the recovered key proves

A successful signature check establishes that the barcode data matches what the issuer signed and that the signature corresponds to the issuer's public key. Change one byte in a surname, date, or license number and the check fails. That is strong protection for the machine-readable data.

It is not a substitute for every other inspection. California's own guidance distinguishes the barcode from the printed text and photograph; the digital signature does not automatically protect those physical features. A careful verifier still compares the card's visible details and checks current status where revocation matters.

The deeper lesson is not that ECDSA failed. The curve behaved as designed. The problem was an incomplete interface: a signature existed, but the public verification material and signing rules were missing. Publishing the public key, the exact canonicalization process, the protected fields, test vectors, and key-rotation policy should happen at launch.

A driver's license barcode can be a plain text record, a cryptographic document, or both at once. The difference is not the darkness of the printed bars. It is whether the people holding the scanner have enough information to verify what those bars claim.