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

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 a link

2. The customer takes out their iPhone, opens whatever email/messaging software & taps the link

3. The link takes the customer to a specially crafted page owned by the bank that triggers a native OS process for opening Apple Wallet and gathering requested ID details with consent.

https://developer.apple.com/videos/play/wwdc2025/232 https://www.w3.org/TR/digital-credentials

This is potentially a superior arrangement because it could eventually establish a strong cryptographic chain of trust all the way to the issuer (e.g. the State of Alabama). Right now there are some gaps in that chain but I see no reason they couldn't be closed over time.

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 signed with somebody else's key.

Seems doubtful! I expect the forgers used a real signature from another card instead, so it has the right key but the wrong data. Reverse engineering the process as the author did and making up their own key wouldn't be of any value to the forgers.

> I built a little demo to check the signatures across California, New York, and Virginia: take a picture of the barcode and check it here.

This is not wrong, but should come with a little warning. A real verifier needs to additionally check the encoded data matches the human-readable data on the front of the card.

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 really.

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 leaked IDs without some false positives.

A fake photo plus a valid barcode will pass any current check right? Unless you still do a secondary proprietary photo lookup that I don’t think exists.

I had a fake ID, and it being scannable was a huge selling point. Convenience stores all scan, and don't seem to care if you look underage. I was only turned down two or three times, usually at bars and restaurants.

This is such a better design than whatever the UK is trying to do[1]. Why make a 3rd party app a requirement for this? I will never install such an app, especially one not made by the government itself.

[1]: https://www.dailystar.co.uk/news/latest-news/digital-id-upda...

Should credit the authors of the Verifiable Credential library. The vendor isnt the one to credit here.

Digital verification is going to matter a lot more for objects we own rather than the objects that proxy for that (currently the main function of an ID). Identity fraud is only problematic because ownership is tied to a loose record of SIN/DL.

Having a physical medium represent ownership just shifts the burden to the state and allows for social engineering and fraud to persist.

I come to HN to learn things I never realized I wanted to know.

Ryan: The style of your blog is easy to read except for the pixelated monospace font. Thanks for sharing this post!

At the time of this writing, the subtitle of the submission here on HN is

  recovering the signing keys for US driver's license barcodes

Notably, this subtitle doesn't appear on the blog post.

Anyway. I only see claims that the public key can be determined from license barcodes, not that a signing key can be determined. What am I missing or misunderstanding?

To head off one potential retort: While it's true that one can use a public key to encrypt data for the recipient that has the private half of that key or verify that data has been signed by the possessor of the private half of that key, I'm almost 100% certain that it's not possible to use that public key to sign data would validate to other folks as being signed by the private half of that key. It has been more than a decade since I've thought about any of this, but isn't the entire point of public-key cryptography that the public part can be distributed to your worst enemy without causing you any trouble at all?

That's really neat! Seems potentially adaptable to paper currency--a verifiable QR code digital signature of the bill's serial number creates a cryptographically hard obstacle to counterfeiting!

> Before signing, the encoder fills the field with a placeholder (0), repeated for the field's exact length - signs the entire payload including that placeholder, and then writes the real signature over the top of it. To verify, you put the placeholder back.

I hate shit like this. Do not let your crypto layer know about the structure of what it's signing. Keep security stupid.

this is cool

[dead]