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!
it would depend on the government and the situation. I suspect most don't realize this is possible. a small government can generate immediate demand for their currency doing this.
The original e-cash paper is from 1983. Governments absolutely know this is possible.
It's just much "too private" to get any political traction. At the very least, I suspect an acceptable modern alternative would either have caps on what can be sent/received completely anonymously (e.g. per recipient and timespan) or want non-anonymous recipients (to allow for VAT/sales tax accounting etc.)
when you unblind a blind signature all the signer knows is that it's a signature they signed at some point, they know nothing (true zero knowledge) about when or where they signed it among all the other signatures.
Yes, and then you have a signed piece of data that others can verify. How does that help you with preventing duplication of signatures?
E-cash depends on the secrecy of the signed data, and immediate redemption with the issuer once it's been spent/accepted. This is a terrible model for physical cash.
> immediate redemption with the issuer once it's been spent/accepted. This is a terrible model for physical cash
not when everything is now online.
also the obvious way such cash would work is that "redemption" is just the new minting of coin. the central authority will mint a new coin by blindly signing your secret after you "destroy" the spent coin by giving them the unblinded signature.
This thread is about printing QR codes on physical cash. GGP explicitly said:
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!
I don't see how any e-cash solutions can help here.
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.
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.
This is a radical idea, but we should remove photos from ids entirely.
Having the photo there just encourages sloppy ID checks by human eye, and it's much easier to mislead the human eye than it is to forge an NFC chip.
If the photo was in the chip only, we'd force ID verifiers to do their job properly, and make forgeries structurally impossible. With basically everybody having an NFC-enabled phone now, you wouldn't even need people to get extra hardware for this.
I have to say that I really don't love the idea of having my ID scanned (and definitely not stored, wink wink) every time I buy a drink etc. Having both paths available, depending on the "severity" and expected anonymity of the situation, seems nice to have.
Depends, if the only id checks are performed by trained officials/administrators for legally significant purposes then yeah I’d agree.
But if you need to be ID checked entering a club or just buying a beer… they’re not training for that, and they’re not buying the hardware to handle it automatically either. Looking at a photo is an appropriate level of security for that purpose.
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).
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 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.
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.
Interestingly, I've never had anyone scan my DL barcode. About 10% of them look at my ID and manually enter it. The rest look at my gray beard, ask me for my birthdate, and key in whatever random plausible date I give them. :) (There's one store where the gray beard is enough and they remotely approve me at the self checkout, no questions asked. The misery of it is that I only buy NA beer and that still requires an ID.)
At 7-11, they will not - cannot - do this. Their pos system requires a scannable license, and will block even a 50 year old from buying age restricted items. N=3 stores for me, and only tested in NY.
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.
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.
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.
Not quite. The analogy works for secret keys (what you're calling "symmetric keys") but a private key is unlike real world key analogies because as you'll quickly discover if you deploy real world keys in a high security environment people can examine the lock to figure out the correct key. The whole point of private keys is that this cannot work in a public key system. That step does not exist.
It is true that publishing your private key is bad but you'd hope the name makes that pretty clear. Despite the way I remember (U2's "The Fly" lyrics, "A secret is something that you tell one other person, so I'm telling you, child") people generally do not understand that the whole point of secrets is that at least two parties know, which means you might always be betrayed by somebody you think is keeping your secret. For a private key it's easy, don't tell anybody, nobody knows, you can't be betrayed, done.
For example Hacker News learns my password to this web site every single time I sign in because that's just a secret. We've known how to do better for decades but only a handful of systems I use (e.g. Google) do so and all of them have a "traditional" password option which is like discovering your aeroplane still has a smoking section in 2026.
I don't see the issue. Attacking a physical lock as you suggest is analogous here to breaking the cryptography in some way. So the NSA busts out its sooper sekrit quantum computer ...
The inability to betray is a sharp observation but I think the analogy still holds flawlessly. It's a physical lock that you haven't handed out the key for so you're the only one with access to it. However the public counterpart still defies easy explanation.
Why did you put "symmetric keys" in scare quotes? Is that not the common term in your neck of the woods when speaking about symmetric crypto?
Encryption scrambles the data. Key is the piece of information that lets the information be scrambled in specific way so that it can be unscrambled by someone in possession of the same (symmetric) or complementary (asymmetric) key.
The only "lock" in the whole thing is the scrambler (encryption software), and that one is usually publicly known and available.
Obvious way to make this clear: if "keys" were a lock, the original data in readable form would be there, accessible if you found a way to bypass or destroy the lock. The whole point of encryption as opposed to locking is that you cannot do this, because the data itself is scrambled - and thus you don't even need to ship any "lock", just the scrambled data, because the "lock" is something everyone already has or can procure.
the whole point of secrets is that at least two parties know
This isn't true. If I do something privately by myself and never tell anyone it's still a secret. If I have a hidden compartment in my desk to hide things and I'm the only one who knows about it, it's a "secret compartment". A secret doesn't have to involve a second party at all.
It's not perfect for symmetric keys at all, because the fundamental fact about locks and keys is that a lock sits on the outside of the thing you're protecting, attaching to it or to a container in which the thing is placed. Encryption is about directly scrambling the protected thing.
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.
I think this is worth highlighting. Public Key Cryptography is a surprising idea. Like Computation, if you'd told a 19th century mathematician about this, they might buy it as a concept but deem it unlikely to ever happen in practice or be of any significance, in the 20th century these were both realised and caused a massive change to our society.
These are not analogs to things ordinary people had already seen. For Computation we just got used to it being everywhere and so we don't need to explain it so much.
For what it’s worth, it’s the analogy I use, and for the twenty or so college sophomores I taught on Tuesday, the analogy is sufficiently understandable that they were able to generate and use SSH key pairs to do their homework.
I think the reason we (the HN crowd) don’t like it is that the analogy starts to break down when you start thinking through all of the operations you can do with public keys. But this does not matter much for somebody learning to use them for the first time. I’ve had to grow comfortable with the idea of giving people imperfect explanations so that they can build an intuition. Once that happens I can return with the mathematics so that they can really understand what is going on.
More people being exposed to asymetric keys probably leads to some confusion when imagining the public keys roll as lock in a symetric system.
IE; the existence of the asymetry allows for the public key to function more than just a "lock", but a much more easy to rationalize "signer attestation.
Except it makes no sense if you look at the thing, because then you realize that the "lock" and "key" are literally the same thing. In the real world, the lock and the key are completely different objects - there's no way to confuse which is which (and there's no way for one to act as the other if you use them in opposite order, either).
The analogy doesn't make sense because it's skipping the existence of the third thing that's the actual (pad)lock - the encryption/decryption software. And it does that because it wants to talk about data as having the property of being "locked", which makes no sense in the first place, but that one isn't immediately obvious.
The whole analogy of locks and keys fundamentally makes no sense when talking about data, because locks are external devices, attached to or directly containing the protected thing, while encryption is the process of scrambling the very thing being protected.
All confusion stems from this bad choice of analogy, trying to "make it simple" for the normies.
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.
Sure, but you generally those are separate conversations in which you don't need to appeal to the duality of encryption and authentication or apply the analogy to the latter.
An alternative way to think about it would be a padlock and a key. Anyone can close the padlock (assuming the common spring loaded design), but only the key holder can open it.
While this works for encryption, it doesn't really work for explaining signatures or however. Maybe someone can come up with a good analogy for that case.
That's the analogy I was taught in college. The public key is really a padlock that had infinite number of copies, but there was only one key that could open all the padlocks. If someone wanted to send a secret message to the person who owned the key, the would obtain a copy of the padlock, put their message in a box and lock it with the padlock, then send the box to the key owner. The key owner was the only person who could unlock the box and read the message.
That actually never occurred to me. But it makes sense non-technical people would be skeptical of sharing a public "key". I like public address better than lock (I think lock just adds confusion).
Because originally it was not really that much of an analogy: we only had what is now called "'symmetrical' encryption", but was just "encryption" back in the day (dating back to even Caesar perhaps). So the 'key idea' made complete sense: don't lose the one thing that could unlock things.
It was only more recently (in the relative, historical sense (~1970s)) that public and private "keys" became a thing, and the differentiation between symmetrical and asymmetrical encryption was made/invented.
The problem is arguably the symmetry in asymmetrical encryption - namely both "private" and "public" key are the same thing; the labeling "public" vs. "private" reflects your arbitrary choice of which of one you give away, and which one you keep for yourself.
It's surprising that we didn't invent any kind of physical padlock that accepts two keys, with the lock mechanism such that, when locked with one of the two keys, can only be unlocked by the other key. I can imagine obvious use cases for that, e.g. in shipping, but I guess this won't adopted because it makes the key management problem immediately obvious. But should such a thing existed, that would be the best (edit: just better - see my other comment explaining why "lock" is the dumb part here) analogy to draw terminology from.
But that's the "you need two keys at the same time" case, which is different. I'm talking about "each of them can lock alone, but once locked, only the other one can unlock".
The real problem is that lock and key is a fundamentally dumb analogy for a process that scrambles something.
It's surprising that we didn't invent any kind of physical padlock that accepts two keys, with the lock mechanism such that, when locked with one of the two keys, can only be unlocked by the other key.
As mentioned in the video they're usually used in commercial settings. Also:
One Way Cylinder Keying: Allows for the issuance of one key that can ONLY lock, one key that can ONLY unlock and one key that can BOTH lock and unlock the cylinder. Perfect for applications where one key holder should only have authorization to lock, while another should only have authorization to open and yet another can have the authorization to perform both functions. One way keyed products are supplied with 2 nylon head cut keys per product and 1 key order card per product.
namely both "private" and "public" key are the same thing; the labeling "public" vs. "private" reflects your arbitrary choice of which of one you give away, and which one you keep for yourself.
It is not quite arbitrary. With RSA, you could potentially store only the modulus and the exponents, publishing one exponent and keeping the other one private (or making each privately known to different people, with both having the modulus). However, the way it is commonly stored is with the private key file includes both exponents and several other numbers, and the public exponent is usually 65537 which makes it easy to guess so you cannot effectively keep it secret. With some other kinds of cryptography (other than RSA), you can figure out the public key from the private key even without doing things like this.
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.
The choice to have different keys everywhere is key to how the dumbest Security Keys work and thus ensures that two parties who trust "you" don't have (from this at least) a way to correlate your identity.
A single Security Key can authenticate to Facebook as WeedLover420 and then be used to sign into the Google account of the Secretary of the US Marijuana Task Force and even if both Facebook and Google were co-operating in the work there's no way to connect these authentications. Obviously WeedLover420 is more likely to get caught because they used the same IP address to do both things and they stink of weed and they look stoned all the time, but none of those are because of the Security Key, that was locked down good.
The OP itself and the title given here uses confusing language that isn't helping.
"Recovering the signing key", the title suggested by HN submitter -- I would not call the public key a "signing key". I might call it a "verification key". You can not recover the "signing key".
The author of the OP: "ECDSA has a specific cryptographic property that given a signature and the message it signed, you can mathematically recover the public key that produced it" -- no, the "public key" did not produce the signature!! If you could actually recover the private key that was used to produce the signature, that would mean that ECDSA was fundamentally flawed in it's very fundamental design, and it is not, in this way anyway. You could say "public key that can be used to verify it", or "verification key that goes with the private key used to sign it", or anything different from what they said.
This stuff is confusing for people who didn't learn it long ago, and people who should know better using incorrect and/or misleading language does not help here! Just say "public" and "private", the actual standard terminology. if you aren't sure how to decribe them more transparently, these already at least describe which key is intended to be secret and which isn't! -- calling the public key a "signing key" or "a key used to produce the signature" is just wrong.
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.
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.
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!
I loved that pixelated mono space font. It’s a personal site; the author is allowed to have some whimsical elements and not conform to your readability standards. You can always change the font yourself in the browser.
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.
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.
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.
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 depends entirely on the purpose of the forgery. Some grocery stores do ID checks by looking at the front of the ID. Others just run the ID across a scanner and the employees are so rushed they don't read it or check the picture. Similar things happen e.g. at bars or casinos. Incomplete forgeries can get you far enough under the right circumstances.
You are assuming that the forgers care about the machine readable part at all. Vast majority of forged EU ID cards I have seen are trivially recognizable by the fact that the MRZ contains something that kinda-sorta matches the human readable part, but is syntactically invalid and has wrong checksums.
I quite like the way passports touch on this - the electronic part has a password; that password is made up of info from the printed data page - so you need both sets of information to validate it.
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.
ID chips can be manufactured, so they can obviously be cloned.
Thinking like yours leads to the asinine situation we saw ten, fifteen years ago where insurers were refusing to pay out vehicle theft claims because "There's no way to clone an RF keyfob or RF immobilizer chip!". Spoiler alert: There were many, many ways to do that.
most bars have scanners that will warn if the same id is scanned twice. it means that someone producing fake ids would at least need a repository of valid barcodes such that two purchasers wouldn't experience the birthday problem trying to get into a bar.
Generally it's configurable. The one that comes to mind first is TokenWorks's Anti-Passback feature which says "Set your custom timeframe (1 hour to 7 days)"
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.
Walk into bank? The last time I opened a bank account (2023), I tapped my driver's license to my phone, it got my details+photo via NFC, I took a "liveness check" video and was onboarded. This has been the workflow for many years now for consumer account openings, or installing a banking app on a new phone. I think bunq did it first around 2017. As soon as (EUDI) wallets are more standardized, both neobanks and high streets banks will adopt that too.
Very soon we are going to be in a world where you walk into a bank to open/maintain an account
I've never in my life walked into a bank to open a bank account. I've got accounts with many different banks these days. Real banks and credit unions, not fake neo banks.
The only times I've ever been in a bank was to get large denomination ($100s) currency, as most ATMs around me don't dispense those. And most of the time I didn't even bother going into a bank I had an account with, most will let you get cash for free with a debit card even if you don't normally do business with them.
The main idea in this that scares me is trusting the State of Alabama (e.g.) to protect their private keys. Humans tend to be the weak links in all of these chains.
Colloquially, we could say: States now issue drivers licenses cards having both a readable number and an authentication code; the state could provide a way for the public to check if the drivers license is true by verifying the authentication code, but they don't provide this service.
..
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 didn't realize that "over the counter" delivery of drivers licenses was not the normal method. When I get a new driver's license at the DMV, I go to a self serve kiosk, have my picture taken, then walk over to a room and my license is already printed by the time I get there. They have 3 massive card printers (imagine a laser printer, but 6 ft/182.88 cm long). It event prints a pseudo-hologram.
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?
How it works in my state: For in person renewals/changes, they punch VOID into your old license, give it back to you, and give you a temporary license printout. Then your new license is mailed a couple weeks later.
For remote renewals/replacements, they just give you a temporary license to print out and then mail you a new one. The old license never gets physically cancelled.
I lost my old one, so ordered a replacement. Later I found the lost one, so I have two... The number is different, though, so I'm sure the old one is invalidated in the database. (Oregon)
If we lose ours, they reprint it with the same expiration date as the lost one, but the new one has "DUPLICATE 1" printed on it (presumably that 1 is a counter). But our drivers license number stays the same for life.
This post is uninformative and stupid. In fact it was a waste of my time. I bet the person who wrote it is lame and probably really likes trains. He probably likes trains a whole lot i bet. Anyways, thanks for nothing.
Maybe we should create petitions for each of the 31 states covered by IDEMIA and all the states covered by Canadian Bank Note to add this to the ID cards.
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.
how to use the DMV's public key to check whether a California ID is real.
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.
The forgery path is downloading the leaked database of 153 million driver's license images, picking one with the right gender, rough age, weight and height, and printing a card with that text+barcode and your photo.
I come to HN to learn things I never realized I wanted to know.
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.
the first part of the article was interesting, but I couldn't finish it because it reads so heavily in claude's 'voice'
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.
No government wants untraceable e-cash. They want it fully traceable.
it would depend on the government and the situation. I suspect most don't realize this is possible. a small government can generate immediate demand for their currency doing this.
The original e-cash paper is from 1983. Governments absolutely know this is possible.
It's just much "too private" to get any political traction. At the very least, I suspect an acceptable modern alternative would either have caps on what can be sent/received completely anonymously (e.g. per recipient and timespan) or want non-anonymous recipients (to allow for VAT/sales tax accounting etc.)
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.
when you unblind a blind signature all the signer knows is that it's a signature they signed at some point, they know nothing (true zero knowledge) about when or where they signed it among all the other signatures.
Yes, and then you have a signed piece of data that others can verify. How does that help you with preventing duplication of signatures?
E-cash depends on the secrecy of the signed data, and immediate redemption with the issuer once it's been spent/accepted. This is a terrible model for physical cash.
not when everything is now online.
also the obvious way such cash would work is that "redemption" is just the new minting of coin. the central authority will mint a new coin by blindly signing your secret after you "destroy" the spent coin by giving them the unblinded signature.
This thread is about printing QR codes on physical cash. GGP explicitly said:
I don't see how any e-cash solutions can help here.
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.
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 wonder if we might have the equivalent of Certificate Revocation List for IDs leaked this way.
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.
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.
This is a radical idea, but we should remove photos from ids entirely.
Having the photo there just encourages sloppy ID checks by human eye, and it's much easier to mislead the human eye than it is to forge an NFC chip.
If the photo was in the chip only, we'd force ID verifiers to do their job properly, and make forgeries structurally impossible. With basically everybody having an NFC-enabled phone now, you wouldn't even need people to get extra hardware for this.
I have to say that I really don't love the idea of having my ID scanned (and definitely not stored, wink wink) every time I buy a drink etc. Having both paths available, depending on the "severity" and expected anonymity of the situation, seems nice to have.
Depends, if the only id checks are performed by trained officials/administrators for legally significant purposes then yeah I’d agree.
But if you need to be ID checked entering a club or just buying a beer… they’re not training for that, and they’re not buying the hardware to handle it automatically either. Looking at a photo is an appropriate level of security for that purpose.
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).
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 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.
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.
I've heard the advice to use a passport card for this. It has your age, it has your name, but it does not have your address.
Of course passports are expensive and not everyone has them, but if you do, next time you renew, opt for the book+card option.
Interestingly, I've never had anyone scan my DL barcode. About 10% of them look at my ID and manually enter it. The rest look at my gray beard, ask me for my birthdate, and key in whatever random plausible date I give them. :) (There's one store where the gray beard is enough and they remotely approve me at the self checkout, no questions asked. The misery of it is that I only buy NA beer and that still requires an ID.)
At 7-11, they will not - cannot - do this. Their pos system requires a scannable license, and will block even a 50 year old from buying age restricted items. N=3 stores for me, and only tested in NY.
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.
Where did you get the impression the author thinks it’s a bad thing? From the article:
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
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.
Not quite. The analogy works for secret keys (what you're calling "symmetric keys") but a private key is unlike real world key analogies because as you'll quickly discover if you deploy real world keys in a high security environment people can examine the lock to figure out the correct key. The whole point of private keys is that this cannot work in a public key system. That step does not exist.
It is true that publishing your private key is bad but you'd hope the name makes that pretty clear. Despite the way I remember (U2's "The Fly" lyrics, "A secret is something that you tell one other person, so I'm telling you, child") people generally do not understand that the whole point of secrets is that at least two parties know, which means you might always be betrayed by somebody you think is keeping your secret. For a private key it's easy, don't tell anybody, nobody knows, you can't be betrayed, done.
For example Hacker News learns my password to this web site every single time I sign in because that's just a secret. We've known how to do better for decades but only a handful of systems I use (e.g. Google) do so and all of them have a "traditional" password option which is like discovering your aeroplane still has a smoking section in 2026.
I don't see the issue. Attacking a physical lock as you suggest is analogous here to breaking the cryptography in some way. So the NSA busts out its sooper sekrit quantum computer ...
The inability to betray is a sharp observation but I think the analogy still holds flawlessly. It's a physical lock that you haven't handed out the key for so you're the only one with access to it. However the public counterpart still defies easy explanation.
Why did you put "symmetric keys" in scare quotes? Is that not the common term in your neck of the woods when speaking about symmetric crypto?
Again, the "lock" part is the dumb part.
Encryption scrambles the data. Key is the piece of information that lets the information be scrambled in specific way so that it can be unscrambled by someone in possession of the same (symmetric) or complementary (asymmetric) key.
The only "lock" in the whole thing is the scrambler (encryption software), and that one is usually publicly known and available.
Obvious way to make this clear: if "keys" were a lock, the original data in readable form would be there, accessible if you found a way to bypass or destroy the lock. The whole point of encryption as opposed to locking is that you cannot do this, because the data itself is scrambled - and thus you don't even need to ship any "lock", just the scrambled data, because the "lock" is something everyone already has or can procure.
This isn't true. If I do something privately by myself and never tell anyone it's still a secret. If I have a hidden compartment in my desk to hide things and I'm the only one who knows about it, it's a "secret compartment". A secret doesn't have to involve a second party at all.
And in fact, we have a dedicated term for shared secrets
It's not perfect for symmetric keys at all, because the fundamental fact about locks and keys is that a lock sits on the outside of the thing you're protecting, attaching to it or to a container in which the thing is placed. Encryption is about directly scrambling the protected thing.
The mental model is that encryption is a locked box you can only open with the key.
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.
I think this is worth highlighting. Public Key Cryptography is a surprising idea. Like Computation, if you'd told a 19th century mathematician about this, they might buy it as a concept but deem it unlikely to ever happen in practice or be of any significance, in the 20th century these were both realised and caused a massive change to our society.
These are not analogs to things ordinary people had already seen. For Computation we just got used to it being everywhere and so we don't need to explain it so much.
For what it’s worth, it’s the analogy I use, and for the twenty or so college sophomores I taught on Tuesday, the analogy is sufficiently understandable that they were able to generate and use SSH key pairs to do their homework.
I think the reason we (the HN crowd) don’t like it is that the analogy starts to break down when you start thinking through all of the operations you can do with public keys. But this does not matter much for somebody learning to use them for the first time. I’ve had to grow comfortable with the idea of giving people imperfect explanations so that they can build an intuition. Once that happens I can return with the mathematics so that they can really understand what is going on.
This analogy is exactly what made it click when I was a teenager.
More people being exposed to asymetric keys probably leads to some confusion when imagining the public keys roll as lock in a symetric system.
IE; the existence of the asymetry allows for the public key to function more than just a "lock", but a much more easy to rationalize "signer attestation.
Except it makes no sense if you look at the thing, because then you realize that the "lock" and "key" are literally the same thing. In the real world, the lock and the key are completely different objects - there's no way to confuse which is which (and there's no way for one to act as the other if you use them in opposite order, either).
The analogy doesn't make sense because it's skipping the existence of the third thing that's the actual (pad)lock - the encryption/decryption software. And it does that because it wants to talk about data as having the property of being "locked", which makes no sense in the first place, but that one isn't immediately obvious.
The whole analogy of locks and keys fundamentally makes no sense when talking about data, because locks are external devices, attached to or directly containing the protected thing, while encryption is the process of scrambling the very thing being protected.
All confusion stems from this bad choice of analogy, trying to "make it simple" for the normies.
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
Maybe we should not use analogies? Just call them secret-text and public-text.
Agree. Even just “secret” would be fine for the private key. Maybe pair it with “identity” or “id”.
"public-text" doesn't describe the purpose of a public key.
Sure, but you generally those are separate conversations in which you don't need to appeal to the duality of encryption and authentication or apply the analogy to the latter.
An alternative way to think about it would be a padlock and a key. Anyone can close the padlock (assuming the common spring loaded design), but only the key holder can open it.
While this works for encryption, it doesn't really work for explaining signatures or however. Maybe someone can come up with a good analogy for that case.
That's the analogy I was taught in college. The public key is really a padlock that had infinite number of copies, but there was only one key that could open all the padlocks. If someone wanted to send a secret message to the person who owned the key, the would obtain a copy of the padlock, put their message in a box and lock it with the padlock, then send the box to the key owner. The key owner was the only person who could unlock the box and read the message.
Certificate and signature could work as an analogy for public keys, if they weren't already taken by higher level concepts.
That actually never occurred to me. But it makes sense non-technical people would be skeptical of sharing a public "key". I like public address better than lock (I think lock just adds confusion).
Because originally it was not really that much of an analogy: we only had what is now called "'symmetrical' encryption", but was just "encryption" back in the day (dating back to even Caesar perhaps). So the 'key idea' made complete sense: don't lose the one thing that could unlock things.
It was only more recently (in the relative, historical sense (~1970s)) that public and private "keys" became a thing, and the differentiation between symmetrical and asymmetrical encryption was made/invented.
The problem is arguably the symmetry in asymmetrical encryption - namely both "private" and "public" key are the same thing; the labeling "public" vs. "private" reflects your arbitrary choice of which of one you give away, and which one you keep for yourself.
It's surprising that we didn't invent any kind of physical padlock that accepts two keys, with the lock mechanism such that, when locked with one of the two keys, can only be unlocked by the other key. I can imagine obvious use cases for that, e.g. in shipping, but I guess this won't adopted because it makes the key management problem immediately obvious. But should such a thing existed, that would be the best (edit: just better - see my other comment explaining why "lock" is the dumb part here) analogy to draw terminology from.
We did/do have that kind of lock: A safe deposit box at a bank. To open it, you need two keys, one of which you have and one of which the bank has.
But that's the "you need two keys at the same time" case, which is different. I'm talking about "each of them can lock alone, but once locked, only the other one can unlock".
The real problem is that lock and key is a fundamentally dumb analogy for a process that scrambles something.
They do:
* https://www.youtube.com/watch?v=VAriLDgpnY8
As mentioned in the video they're usually used in commercial settings. Also:
* https://mangionelocksmiths.com/wp-content/uploads/2017/02/Mu...
It is not quite arbitrary. With RSA, you could potentially store only the modulus and the exponents, publishing one exponent and keeping the other one private (or making each privately known to different people, with both having the modulus). However, the way it is commonly stored is with the private key file includes both exponents and several other numbers, and the public exponent is usually 65537 which makes it easy to guess so you cannot effectively keep it secret. With some other kinds of cryptography (other than RSA), you can figure out the public key from the private key even without doing things like this.
Well most people don't verify identity with some sort of physical key. So it doesn't work as an analogy in the first place for signatures...
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.
The choice to have different keys everywhere is key to how the dumbest Security Keys work and thus ensures that two parties who trust "you" don't have (from this at least) a way to correlate your identity.
A single Security Key can authenticate to Facebook as WeedLover420 and then be used to sign into the Google account of the Secretary of the US Marijuana Task Force and even if both Facebook and Google were co-operating in the work there's no way to connect these authentications. Obviously WeedLover420 is more likely to get caught because they used the same IP address to do both things and they stink of weed and they look stoned all the time, but none of those are because of the Security Key, that was locked down good.
github.com/your-username.keys; they're already there.
The signing key? Sure, but it's not an SSH access key.
The OP itself and the title given here uses confusing language that isn't helping.
"Recovering the signing key", the title suggested by HN submitter -- I would not call the public key a "signing key". I might call it a "verification key". You can not recover the "signing key".
The author of the OP: "ECDSA has a specific cryptographic property that given a signature and the message it signed, you can mathematically recover the public key that produced it" -- no, the "public key" did not produce the signature!! If you could actually recover the private key that was used to produce the signature, that would mean that ECDSA was fundamentally flawed in it's very fundamental design, and it is not, in this way anyway. You could say "public key that can be used to verify it", or "verification key that goes with the private key used to sign it", or anything different from what they said.
This stuff is confusing for people who didn't learn it long ago, and people who should know better using incorrect and/or misleading language does not help here! Just say "public" and "private", the actual standard terminology. if you aren't sure how to decribe them more transparently, these already at least describe which key is intended to be secret and which isn't! -- calling the public key a "signing key" or "a key used to produce the signature" is just wrong.
I hate shit like this. Do not let your crypto layer know about the structure of what it's signing. Keep security stupid.
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.
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!
https://web.archive.org/web/20260917035309/https://ryan.scie...
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.
I loved that pixelated mono space font. It’s a personal site; the author is allowed to have some whimsical elements and not conform to your readability standards. You can always change the font yourself in the browser.
this is cool
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.
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.
This is a great investigation but I have two small nits:
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 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.
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 depends entirely on the purpose of the forgery. Some grocery stores do ID checks by looking at the front of the ID. Others just run the ID across a scanner and the employees are so rushed they don't read it or check the picture. Similar things happen e.g. at bars or casinos. Incomplete forgeries can get you far enough under the right circumstances.
You are assuming that the forgers care about the machine readable part at all. Vast majority of forged EU ID cards I have seen are trivially recognizable by the fact that the MRZ contains something that kinda-sorta matches the human readable part, but is syntactically invalid and has wrong checksums.
I imagine a good forger would add wear marks to the barcode so it doesn’t scan for a plausible reason.
I quite like the way passports touch on this - the electronic part has a password; that password is made up of info from the printed data page - so you need both sets of information to validate it.
The ICAO standard for passport chips is really well done. Especially since you can read the photo from the chip itself.
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!
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.
This is why chip-based IDs are superior, esp. with phones and NFC being ubiquitous.
ID chips can't be cloned, so you don't even need photo auth (unless you want to protect against stolen but real IDs).
ID chips can be manufactured, so they can obviously be cloned.
Thinking like yours leads to the asinine situation we saw ten, fifteen years ago where insurers were refusing to pay out vehicle theft claims because "There's no way to clone an RF keyfob or RF immobilizer chip!". Spoiler alert: There were many, many ways to do that.
There are also many ways to steal a car without having a key at all.
How about having the signed data contain a hash of the photo and having some way for the verifier to access the photo (perhaps via an API)?
An actual hard-to-clone chip to contain the authority to access the photo would be even better.
most bars have scanners that will warn if the same id is scanned twice. it means that someone producing fake ids would at least need a repository of valid barcodes such that two purchasers wouldn't experience the birthday problem trying to get into a bar.
What do you mean by scanned twice? Can't someone leave and reenter?
Maybe it has a short TTL? So it would catch a group of people that all bought fake IDs from the same place.
All except the first person to get through. :)
Generally it's configurable. The one that comes to mind first is TokenWorks's Anti-Passback feature which says "Set your custom timeframe (1 hour to 7 days)"
https://www.idscanner.com/product-features/anti-passback/
What are you talking about. ZNB field data related to nothing youve mentioned. Stands for zuck my balls. Haha.
dog out.
-dog22212
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.
for example, a reliance on apple wallet, instead of an open standard.
With that quibble aside, I do like the basic structure of your solution.
Walk into bank? The last time I opened a bank account (2023), I tapped my driver's license to my phone, it got my details+photo via NFC, I took a "liveness check" video and was onboarded. This has been the workflow for many years now for consumer account openings, or installing a banking app on a new phone. I think bunq did it first around 2017. As soon as (EUDI) wallets are more standardized, both neobanks and high streets banks will adopt that too.
I've never in my life walked into a bank to open a bank account. I've got accounts with many different banks these days. Real banks and credit unions, not fake neo banks.
The only times I've ever been in a bank was to get large denomination ($100s) currency, as most ATMs around me don't dispense those. And most of the time I didn't even bother going into a bank I had an account with, most will let you get cash for free with a debit card even if you don't normally do business with them.
Louisiana has one but I’d be shocked if it was up to date with the latest in crypto having met the company owner.
The main idea in this that scares me is trusting the State of Alabama (e.g.) to protect their private keys. Humans tend to be the weak links in all of these chains.
My elderly parents and some of my technology illiterate coworkers are going to hate that with a passion.
“But my phone isn’t a wallet. My wallet is a wallet.”
So a private company sees a full set of PII for people in more than half of the states, with no opt out bc everyone MUST have a state ID to function.
Time for a federal law banning the DMVs from outsourcing this stuff (or selling the bulk data like they do to insurers).
Colloquially, we could say: States now issue drivers licenses cards having both a readable number and an authentication code; the state could provide a way for the public to check if the drivers license is true by verifying the authentication code, but they don't provide this service.
..
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.
The analogy is right there in the name: Signatures.
But rather than identifying forgeries by inspecting the handwriting details and ink pigments or whatever, we have math.
I didn't realize that "over the counter" delivery of drivers licenses was not the normal method. When I get a new driver's license at the DMV, I go to a self serve kiosk, have my picture taken, then walk over to a room and my license is already printed by the time I get there. They have 3 massive card printers (imagine a laser printer, but 6 ft/182.88 cm long). It event prints a pseudo-hologram.
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 got a temporary license and received the real one in the mail later. Yes, you can keep the old one.
What's the temporary license printed on? Standard paper?
My licenses have always been printed on a plastic card, but I remember seeing older licenses that were basically laminated photo paper.
How it works in my state: For in person renewals/changes, they punch VOID into your old license, give it back to you, and give you a temporary license printout. Then your new license is mailed a couple weeks later.
For remote renewals/replacements, they just give you a temporary license to print out and then mail you a new one. The old license never gets physically cancelled.
I lost my old one, so ordered a replacement. Later I found the lost one, so I have two... The number is different, though, so I'm sure the old one is invalidated in the database. (Oregon)
If we lose ours, they reprint it with the same expiration date as the lost one, but the new one has "DUPLICATE 1" printed on it (presumably that 1 is a counter). But our drivers license number stays the same for life.
This post is uninformative and stupid. In fact it was a waste of my time. I bet the person who wrote it is lame and probably really likes trains. He probably likes trains a whole lot i bet. Anyways, thanks for nothing.
dog signing out.
-dog22212
Maybe we should create petitions for each of the 31 states covered by IDEMIA and all the states covered by Canadian Bank Note to add this to the ID cards.
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.
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.
IIUC, the forgery path then involves getting any legitimate California license and changing the photo only? I guess that works.
The forgery path is downloading the leaked database of 153 million driver's license images, picking one with the right gender, rough age, weight and height, and printing a card with that text+barcode and your photo.
Which makes sense, as the signature is for the barcode data...