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.
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.
> 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.
This was just bad wording. I meant to say "someone else's key" in the context that it was a key generated by the forgers rather than the state DMV, will update to make it more clear!
> 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.
Correct, but simply checking that it matches the front is likely not enough to deter fraud. You could extract the barcode data from a real ID and put it on a physically different (fake) ID with a different photo and it would still return as valid. To detect this you generally would need a higher end solution (IDScan.net/VeriScan's ID authentication solution (yes... the one that just leaked everyone's data), TokenWorks' IdentiFake, IDScience, amongst others) that does the same high resolution UV/IR checks TSA does. But the forgers are good enough now to be able to sometimes pass those scanners too.
> A real verifier needs to additionally check the encoded data matches the human-readable data on the front of the card.
I mean, not really? Only the machine-readable part is signed, so it should be treated as the sole source of truth. Besides, only an idiot forger would put different data in the human-readable part - it would be the easiest way to get caught!
But if the forger claims his name is John Smith (or his date of birth is xx/xx/2004) he will edit the human-readable part.
If he pairs the edited human-readable part with a real barcode copied from a real license in someone else's name, then anyone inspecting the license will see the documentation matches his claim, and if they also use this site to check for fake barcodes it will confirm the barcode was really issued by the California DMV.
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.
Think about it, the key analogy is just terrible. In the origin domain, losing a key is always bad, and making a key available to all is a non sequitur.
It's not like non-technical people understand asymmetric cryptography. Or even technical people, for that matter.
Maybe we should refer to the public key as an address, and the private key is just a password again. You can send stuff, securely, to an address. And you can verify the sender when you have their address (ie check the signature).
The key analogy is perfect for the private key and for symmetric keys. Publishing those is always bad and means you need to rekey immediately just like losing a traditional physical key to a secure building would.
The public counterpart is tricky to name but I think attaching "public" to it makes the intended usage plenty clear. There isn't really a physical counterpart unless you consider maybe those machines that check for counterfeit cash but even that's not a great fit because the pubkey is simultaneously analogous to a lock box.
Yeah, that always bothered me about the terminology. My fix would be to call it a lock -- everyone understands that you can share those and it doesn't make them any easier to open.
Or how about we call it the lock. There's the (private) key, and it fits the lock (public key). You can pass the lock around, but you need the (private) key to be useful.
I dunno if that works or is any less confusing, to be honest.
I don’t think there’s any process or entity in the physical world that is reasonably familiar to most people that is even remotely suitable as an analogy to public key cryptography.
That implies they chose not to. More likely the other states simply didn’t realize the value derived from paying a vendor to enable a ‘feature’, not realizing both the necessity of such signatures and that the cost to the vendor and mechanism of delivery is precisely the same regardless. One might consider what sort of pressures a citizen could apply to compel those states to act more to their own benefit, but I have no specific ideas to suggest at this time.
I think it depends on the context? It's in an ID card's design goals to be provably valid, so it's pointless to not publish its public keys, but something like SSH pubkeys, uhh, should I really be so eager to just publicly dump all of mine…?
The only downside I see with publishing ssh public keys is:
- If you install such keys to a host, and an attacker (with access to said host) has catalogued your ssh keys, they can see that you have access to said host (if they can correlate your method of publishing the keys to your identity)
On the other hand, if you go to the other extreme (?), you can have a different public ssh key per host. This way the server owner/attacker is not able to correlate that ssh key with other keys to recover your identity. (You need to take care that ssh won't offer too many public keys in that case.) Example case of a service that might get offered many ssh keys: github.
Personally I don't bother. But I wouldn't be too bothered about just putting my public keys to some "secret" URL in the internet either, so I can easily enable myself ssh access to a host with a single curl.. Maybe I should indeed do that.
TFA is a bit obtuse about it, and assumes you've read their previous article on the topic, but from what I gathered, it's about whether the AAMVA would standardize cryptographically signing the barcodes of driver licenses to mitigate creating fakes in the US/CA. Cali showed it's entirely possible, but there's still no pressure for the standard to change across the board.
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.
And it's a classic case of Not Invented Here as well: this problem was solved decades ago and the solution is widely-deployed in passports and most European identity documents - just use NFC!
Cryptographic NFC chips are basically free these days, and any modern smartphone can read them. The photo issue is solved by having the chip contain a copy of the photo, as a few extra kilobytes of data isn't an issue when you aren't using barcodes. The copy issue is solved by having the chip sign a verifier-provided nonce together with the data, and having the government sign the chip's public key instead.
You can only store ~1100 bytes in a PDF417 barcode so storing the image itself it unfeasible. And storing a signature of an image you don't have access to is useless. Passports are able to do this because the smartcard chips they use can store at least 32 KB of data (usually more).
The Austrian ID card does that. It’s a really blurry black-and-white photo only, but it’s still recognizable and I find it quite impressive that any type of photo (in addition to its public key signature) can fit into a QR code at all.
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.
The first thing I do with a real ID is widen the reference bars on the sides so the checkout scanner can't read it. If they want my birthday they can type it in manually, I don't need all my info in some store database.
The flex of the plastic is always a good way to check. Although I've held a fake NY ID and a legit one at the same time and could not tell any difference. Even did a double blind test.
Weirdly when I first got my California DL I thought it felt fake compared to my home state because it was so much thinner. Maybe it’s better for the environment.
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.
Yeah it's tragic. Short sighted and less secure. I don't think the politicians understand the risks involved of normalising uploading your ID to 3rd parties. I've tried emailing my MP but it falls on deaf ears.
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.
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?
Yup. The person who submitted this to HN is probably way less knowledgeable on this topic than the writer of the article. The article clearly labels the recovered keys as “recovered public keys” at the top.
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.
As far as compact encodings go, this kind of patch-and-fill technique isn't particularly egregious. The alternative mentioned (where the verifier has to be aware of a bitfield that defines the to-be-signed elements) is much easier to mess up!
Counterpoint - every real world crypto algo needs to do somewhat content aware padding or the crypto is much easier to break. Either that, or go so overboard on randomness that it adds a lot of overhead.
When you look at the details underneath more crypto, there is a lot of ah hah - and ‘doh’ - moments due to implementation realities.
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.
> 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.
This was just bad wording. I meant to say "someone else's key" in the context that it was a key generated by the forgers rather than the state DMV, will update to make it more clear!
> 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.
Correct, but simply checking that it matches the front is likely not enough to deter fraud. You could extract the barcode data from a real ID and put it on a physically different (fake) ID with a different photo and it would still return as valid. To detect this you generally would need a higher end solution (IDScan.net/VeriScan's ID authentication solution (yes... the one that just leaked everyone's data), TokenWorks' IdentiFake, IDScience, amongst others) that does the same high resolution UV/IR checks TSA does. But the forgers are good enough now to be able to sometimes pass those scanners too.
> A real verifier needs to additionally check the encoded data matches the human-readable data on the front of the card.
I mean, not really? Only the machine-readable part is signed, so it should be treated as the sole source of truth. Besides, only an idiot forger would put different data in the human-readable part - it would be the easiest way to get caught!
But if the forger claims his name is John Smith (or his date of birth is xx/xx/2004) he will edit the human-readable part.
If he pairs the edited human-readable part with a real barcode copied from a real license in someone else's name, then anyone inspecting the license will see the documentation matches his claim, and if they also use this site to check for fake barcodes it will confirm the barcode was really issued by the California DMV.
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.
Think about it, the key analogy is just terrible. In the origin domain, losing a key is always bad, and making a key available to all is a non sequitur.
It's not like non-technical people understand asymmetric cryptography. Or even technical people, for that matter.
Maybe we should refer to the public key as an address, and the private key is just a password again. You can send stuff, securely, to an address. And you can verify the sender when you have their address (ie check the signature).
The key analogy is perfect for the private key and for symmetric keys. Publishing those is always bad and means you need to rekey immediately just like losing a traditional physical key to a secure building would.
The public counterpart is tricky to name but I think attaching "public" to it makes the intended usage plenty clear. There isn't really a physical counterpart unless you consider maybe those machines that check for counterfeit cash but even that's not a great fit because the pubkey is simultaneously analogous to a lock box.
Yeah, that always bothered me about the terminology. My fix would be to call it a lock -- everyone understands that you can share those and it doesn't make them any easier to open.
That analogy works for encryption but doesn't really work for signature verification
Or how about we call it the lock. There's the (private) key, and it fits the lock (public key). You can pass the lock around, but you need the (private) key to be useful.
I dunno if that works or is any less confusing, to be honest.
I don’t think there’s any process or entity in the physical world that is reasonably familiar to most people that is even remotely suitable as an analogy to public key cryptography.
That implies they chose not to. More likely the other states simply didn’t realize the value derived from paying a vendor to enable a ‘feature’, not realizing both the necessity of such signatures and that the cost to the vendor and mechanism of delivery is precisely the same regardless. One might consider what sort of pressures a citizen could apply to compel those states to act more to their own benefit, but I have no specific ideas to suggest at this time.
I think it depends on the context? It's in an ID card's design goals to be provably valid, so it's pointless to not publish its public keys, but something like SSH pubkeys, uhh, should I really be so eager to just publicly dump all of mine…?
The only downside I see with publishing ssh public keys is:
- If you install such keys to a host, and an attacker (with access to said host) has catalogued your ssh keys, they can see that you have access to said host (if they can correlate your method of publishing the keys to your identity)
On the other hand, if you go to the other extreme (?), you can have a different public ssh key per host. This way the server owner/attacker is not able to correlate that ssh key with other keys to recover your identity. (You need to take care that ssh won't offer too many public keys in that case.) Example case of a service that might get offered many ssh keys: github.
Personally I don't bother. But I wouldn't be too bothered about just putting my public keys to some "secret" URL in the internet either, so I can easily enable myself ssh access to a host with a single curl.. Maybe I should indeed do that.
Where did you get the impression the author thinks it’s a bad thing? From the article:
> These are public keys, which are meant to be published - recovering one lets anyone check a signature, not forge one.
I think GP and TFA mean that some of the states are afraid of public-key disclosure.
TFA is a bit obtuse about it, and assumes you've read their previous article on the topic, but from what I gathered, it's about whether the AAMVA would standardize cryptographically signing the barcodes of driver licenses to mitigate creating fakes in the US/CA. Cali showed it's entirely possible, but there's still no pressure for the standard to change across the board.
its even called "public" lol
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.
And it's a classic case of Not Invented Here as well: this problem was solved decades ago and the solution is widely-deployed in passports and most European identity documents - just use NFC!
Cryptographic NFC chips are basically free these days, and any modern smartphone can read them. The photo issue is solved by having the chip contain a copy of the photo, as a few extra kilobytes of data isn't an issue when you aren't using barcodes. The copy issue is solved by having the chip sign a verifier-provided nonce together with the data, and having the government sign the chip's public key instead.
Biometric passports, including US ones, have supported the same protocol for decades at this point.
You can only store ~1100 bytes in a PDF417 barcode so storing the image itself it unfeasible. And storing a signature of an image you don't have access to is useless. Passports are able to do this because the smartcard chips they use can store at least 32 KB of data (usually more).
The Austrian ID card does that. It’s a really blurry black-and-white photo only, but it’s still recognizable and I find it quite impressive that any type of photo (in addition to its public key signature) can fit into a QR code at all.
I wonder if we might have the equivalent of Certificate Revocation List for IDs leaked this way.
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.
The first thing I do with a real ID is widen the reference bars on the sides so the checkout scanner can't read it. If they want my birthday they can type it in manually, I don't need all my info in some store database.
Defacing a photo Id(driver's license or passport) is technically a crime.
The optimal level of crime is not zero.
While true, this is not the context that idea applies to.
The other thing I remember was California fakes folding in half and not breaking
The flex of the plastic is always a good way to check. Although I've held a fake NY ID and a legit one at the same time and could not tell any difference. Even did a double blind test.
Weirdly when I first got my California DL I thought it felt fake compared to my home state because it was so much thinner. Maybe it’s better for the environment.
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...
Looks like the criteria were 1. No cost to the government/taxpayer. 2. Minimal work for the civil service.
Yeah it's tragic. Short sighted and less secure. I don't think the politicians understand the risks involved of normalising uploading your ID to 3rd parties. I've tried emailing my MP but it falls on deaf ears.
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!
Thank you! Just updated it to use the the browser default monospace for inline text.
https://web.archive.org/web/20260917035309/https://ryan.scie...
At the time of this writing, the subtitle of the submission here on HN is
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?
Yes. The subtitle is wrong. He recovers the public key, due to the way EDCSA signing works.
Yup. The person who submitted this to HN is probably way less knowledgeable on this topic than the writer of the article. The article clearly labels the recovered keys as “recovered public keys” at the top.
Given the poster's nickname, the person who posted it and the author may be one and the same.
I think the author is Claude.
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!
Copy known good serial number + signature.
combine with a central authority server network and make it blind signatures and you have untraceable e-cash.
Blind signatures don’t work like that. Once you unblind them, they are very traceable. Chaumian e-cash can only be spent once for that reason.
No government wants untraceable e-cash. They want it fully traceable.
It’s a bunch of static signed data, which is hard to modify but trivial to copy. Not exactly what you’d want for bank notes.
NFC and a challenge-response protocol could work, though, like e.g. the one used in biometric passports.
> 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.
As far as compact encodings go, this kind of patch-and-fill technique isn't particularly egregious. The alternative mentioned (where the verifier has to be aware of a bitfield that defines the to-be-signed elements) is much easier to mess up!
Counterpoint - every real world crypto algo needs to do somewhat content aware padding or the crypto is much easier to break. Either that, or go so overboard on randomness that it adds a lot of overhead.
When you look at the details underneath more crypto, there is a lot of ah hah - and ‘doh’ - moments due to implementation realities.
this is cool