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

  recovering the signing keys for US driver's license barcodes

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 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 just limits the forgeries to using identities of real people.

Compare to https://en.wikipedia.org/wiki/Biometric_passport that actually contains a digital photo, with a signature.

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.

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.

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.

Time for a federal law banning the DMVs from outsourcing this stuff (or selling the bulk data like they do to insurers).

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

..

When discussing asymmetric cryptography with less technical folk, a lock analogy breaks down quickly as locks are conceptualized as being symmetric. Hence, "key" is a poor word that came from symmetric cryptography; one really needs to discuss the signature or authentication code.

A better analogy may be a transparent display case, where only authorized people can put things into the case. To check a copy outside the case is true, one would want to go to the official display case and compare. This isn't a great analogy because there's no analog to the signature, but it gets the asymmetry across.

Perhaps we might do a bit better? Suppose your friend gave you a poster copy of a famous painting from the Metropolitan Museum. On the poster is the curatorial accession number. You could go to the MET and check if your poster matches the painting, which should have matching accession number on the label.

So far our analogy covers asymmetry but is still centralized. The museum also distributes a catalog of its posters/paintings. Catalog entries have a thumb print of the painting and its accession number. So, if you could find a trusted copy of that catalog, say at your local library, you might also use this to check the painting's authenticity without having to travel to the museum. Alas, this analogy fails since the whole catalog need not be shared (just the public key).

These analogies are still problematic. This is an involved and novel cryptographic process, and for the interested policy maker or their trusted advisors, it's probably much better if we teach the real process with worked examples.

I have to surrender my old license to the person in the room. How does that work if your license is mailed to you? Do you get to keep the old one?

(Delaware)

I can't imagine Illinois, where I live that I believe uses IDEMIA from what I know about the Apple Wallet rollout wouldn't want to add this.

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

dog signing out.

-dog22212