Keys Not Included: Recovering the Signing Keys for US Driver's License Barcodes

By Ryan Fahey

Introduction: The Illusion of Security

Most United States driver's licenses feature a dense, rectangular barcode on the reverse side. This is a PDF417 symbol, a standard adopted by the American Association of Motor Vehicle Administrators (AAMVA). While these barcodes are primarily used for quick data entry by law enforcement and DMV clerks, they are not merely plain text. To prevent fraudulent modification of the data, these barcodes are digitally signed.

The security premise is simple: only the issuing state possesses the private key required to sign the data, while anyone with the public key can verify that the license is authentic. However, as this research demonstrates, the implementation of this security model is often flawless deeply flawed.

---

The Technical Framework

How the Barcode Works

The PDF417 barcode encodes a string of data containing the driver's name, address, license number, and other PII (Personally Identifiable Information). To ensure this data hasn't been altered, a digital signature is appended to the data string.

The Signing Process

The general logic for the signature can be visualized as follows:

The Mathematics of Verification

In a standard RSA-based signing scheme, the signature $S$ is created using the private exponent $d$ and the modulus $n$:

$S = M^d \pmod{n}$

Where $M$ is the hashed message. To verify the signature, the validator uses the public exponent $e$:

$M = S^e \pmod{n}$

If the decrypted hash matches the hash of the data currently in the barcode, the license is considered authentic.

---

The Vulnerability: Key Recovery

The core of the problem is not the mathematics of RSA, but the management of the keys. If a private key is leaked, reused, or generated predictably, the entire security chain collapses.

Methodology for Recovery

The process of recovering these keys involved analyzing barcodes from various states to identify patterns. The goal was to find instances where the private keys were either publicly available or could be derived.

The Recovery Workflow:

• Collect a diverse sample of PDF417 barcodes from multiple jurisdictions.
• Extract the signature blocks and the associated public keys.
• Cross-reference public keys against known leaked databases.
• Test for "weak" keys (e.g., keys with small primes or common seeds).
• Attempt to forge a signature using recovered keys to verify success.

Findings and Analysis

The research revealed a startling lack of rigor. In several cases, the keys were not "secret" at all. Some were found in public repositories, while others were shared across different agencies, increasing the attack surface.

---

Implementation Example

To illustrate how a recovered key might be used to generate a fraudulent barcode, consider the following conceptual Python snippet:

from Crypto.PublicKey import RSA
from Crypto.Signature import pkcs1_15
from Crypto.Hash import SHA256

# Recovered Private Key (Example)
private_key_data = """-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA7... (recovered key) ...
-----END RSA PRIVATE KEY-----"""

key = RSA.import_key(private_key_data)
message = b"DL_DATA:NAME=JOHN_DOE;LIC=123456789;EXP=2030-01-01"
hash_obj = SHA256.new(message)

# Generate the forged signature
signature = pkcs1_15.new(key).sign(hash_obj)
print(f"Forged Signature: {signature.hex()}")

---

Implications and Conclusion

The ability to recover signing keys transforms a "secure" government ID into a simple piece of printed plastic. If an attacker can sign a barcode, they can change their date of birth, name, or expiration date, and the barcode will pass as authentic to any scanner using the official public key.

"The security of a system is only as strong as its weakest link. In the case of US driver's licenses, the link isn't the encryption—it's the key management."

Final Takeaways

1. Standardization $\neq$ Security: Following the AAMVA standard is useless if the keys are stored in plaintext on a public server.
2. Rotation is Mandatory: Keys should be rotated regularly to limit the window of opportunity for an attacker.
3. Hardware Security: Private keys should reside in Hardware Security Modules (HSMs) rather than software files.

By treating these keys as "included" in the public domain rather than "secret," issuing authorities have inadvertently provided the tools for their own subversion.