'Tough To Forge' Digital Driver's License is Easy To Forge (arstechnica.com) 87
An anonymous reader shares a report: In late 2019, the government of New South Wales in Australia rolled out digital driver's licenses. The new licenses allowed people to use their iPhone or Android device to show proof of identity and age during roadside police checks or at bars, stores, hotels, and other venues. ServiceNSW, as the government body is usually referred to, promised it would "provide additional levels of security and protection against identity fraud, compared to the plastic [driver's license]" citizens had used for decades.
Now, 30 months later, security researchers have shown that it's trivial for just about anyone to forge fake identities using the digital driver's licenses, or DDLs. The technique allows people under drinking age to change their date of birth and for fraudsters to forge fake identities. The process takes well under an hour, doesn't require any special hardware or expensive software, and will generate fake IDs that pass inspection using the electronic verification system used by police and participating venues. All of this, despite assurances that security was a key priority for the newly created DDL system. "To be clear, we do believe that if the Digital Driver's Licence was improved by implementing a more secure design, then the above statement made on behalf of ServiceNSW would indeed be true, and we would agree that the Digital Driver's Licence would provide additional levels of security against fraud compared to the plastic driver's licence," Noah Farmer, the researcher who identified the flaws, wrote in a post published last week.
Now, 30 months later, security researchers have shown that it's trivial for just about anyone to forge fake identities using the digital driver's licenses, or DDLs. The technique allows people under drinking age to change their date of birth and for fraudsters to forge fake identities. The process takes well under an hour, doesn't require any special hardware or expensive software, and will generate fake IDs that pass inspection using the electronic verification system used by police and participating venues. All of this, despite assurances that security was a key priority for the newly created DDL system. "To be clear, we do believe that if the Digital Driver's Licence was improved by implementing a more secure design, then the above statement made on behalf of ServiceNSW would indeed be true, and we would agree that the Digital Driver's Licence would provide additional levels of security against fraud compared to the plastic driver's licence," Noah Farmer, the researcher who identified the flaws, wrote in a post published last week.
Re:No Digital ID (Score:5, Insightful)
Re: (Score:2)
Jimmy Dore is no better. Like there are absolutely legitimate criticisms and concerns about how systems operate but this really comes across as chicken little scaremongering, which we have been hearing about for years and none have come to pass in quite the way these people have said, especially when the most relevant information the government or corporations already have by your existing cell phone data anyway.
Re: No Digital ID (Score:2)
Re: (Score:2)
Any sources that don't appear to be completely insane at first glance?
Simple counter-source though: The many countries which already have an entirely digital form of ID which aren't some dystopian nightmare.
Re: (Score:2)
Ya, because Rogan is above pushing bullshit like a brick is above the Sargasso Sea (to borrow a Douglas Adams' phrase).
... or DLLs (Score:5, Funny)
digital driver's licenses, or DDLs
Just another DLL hell then.
Real crypto security is hard (Score:4, Informative)
..really hard, and only a very few know how to do it
Government officials who pay for stuff like this are clueless and have no way to guarantee that the stuff they buy actually works
Semi-competent security companies see a pot of gold
Re: (Score:2)
Indeed. But many claim to know how to do it and then mess it up, hoping nobody will notice while it is still under warranty. If it is under warranty in the first place. Probably also a "cheapest bidder" situation as so often when governments need to get rid of some taxpayer money...
Re: (Score:2)
What I find really ironic about this stuff is that they could get the job done for pennies on the dollar by involving the internets. Have a competition for open source solutions, and everyone attacks everyone else's. You can't improve security by having a secret method anyway, the method will always get out (often by being reverse engineered, but sometimes it's just simply leaked.) The whole thing was probably some kind of kickback scam and they didn't even really make a good faith effort, but even when the
Re: Real crypto security is hard (Score:1)
Yeah, but then it canâ(TM)t be abused by the government either. There is a reason the government wants it implemented poorly.
Re: (Score:1)
Re: (Score:2)
..really hard, and only a very few know how to do it
Government officials who pay for stuff like this are clueless and have no way to guarantee that the stuff they buy actually works
Semi-competent security companies see a pot of gold
Designing cryptographic algorithms is extremely hard and should only be done by researchers in the field, implementing those algorithms is also extremely hard, and again should only be done by professionals in the field.
Designing secure applications is only moderately hard, and can be done by experienced professionals.
The basics for a thing like this should be trivial:
1) Use a secure public/private key pair so that someone with the public key can authenticate a signed license.
2) Allow an authenticated devic
Re: (Score:2)
Ok, yeah, maybe.
But, using a 4-digit number as an encryption key doesn't really pass the bar as giving it any honest effort. It suggests the app developer really didn't know much about programming, much less security. Allowing backup of the credential is also another pretty big flaw, but much less significant.
Things like this should have a clear boundary on use case and intended level of security. It's like using the SSN in the US as a unique identifier and password.
Designing a much more secure system is
Re: Real crypto security is hard (Score:2)
If the license data were simply signed by the issuer they could have left it wide open and it wouldnâ(TM)t have mattered; because modifications would break the signature. Turning this into a trusted-client problem was purely optional; and a terrible choice. Once you go down that road itâ(TM)s just a questi
Re:Real crypto security is hard (Score:5, Informative)
..really hard, and only a very few know how to do it Government officials who pay for stuff like this are clueless and have no way to guarantee that the stuff they buy actually works Semi-competent security companies see a pot of gold
In this case, it's actually really easy. Just implement the ISO 18013-5 standard [iso.org], which has well-designed security, is careful to ensure that you never have to hand anyone your phone, and is also very careful about other aspects privacy, taking care to ensure that license presentations aren't inherently linkable and that data minimization is possible (you can provide only the information required, e.g. if you're buying alcohol you can prove that you're over 21 without providing any other information).
I know, because I designed the ISO 18013-5 crypto security protocol :-) (though the final version isn't exactly what I designed; it was slightly improved by cryptographers from NIST, Google and Apple).
This ISO standard is what Apple implemented recently, BTW, and what Android launched support for in 2019. It's actually very well done, and the security has been thoroughly reviewed.
Re: (Score:2)
the final version isn't exactly what I designed; it was slightly improved by cryptographers from NIST, Google and Apple
Oh, I think BSI [bsi.bund.de] also contributed a tweak, though I don't recall exactly what, and can't be bothered to review the committee's comment history.
Open Standards - ISO standards are not open (Score:4, Interesting)
Also, fuck standards like zigbee that claim they are open standards and yet only publish for free part of the standard, require fees if you want enough information to actually implement the standard and also claim copyright preventing anyone from forking the standard.
Re:Open Standards - ISO standards are not open (Score:5, Interesting)
Re: (Score:2)
I've been burned by ISO standards that refer to other standards and having to buy 3 different standards
You're buying individual standards? That's insane. If your job depends on it then you should be buying a subscription service that gives you access to all the standards.
But tip for you:
a) People don't publish thousands of standards each hundreds of pages long out of the goodness of their heart. There is a non-trivial administrative overhead to managing the publishing of standards. Even if the standards themselves are open why do you feel so entitled that other people did the work for you?
b) All ISO standard
Re: (Score:2)
Yes, it is 'really easy' to implement a standard that came out almost 2 years AFTER your implementation (your link says published Sep 2019, article says their system has been in use 30 months).
I'm curious - does your standard work with no communication between the users phone and whatever device is verifying the ID? How do you verify that a photo displayed on a phone is genuine? Certainly it is simple if there is a file transfer containing the photo, but what if it is just displayed? I can see most peopl
Re: (Score:2)
Yes, it is 'really easy' to implement a standard that came out almost 2 years AFTER your implementation (your link says published Sep 2019, article says their system has been in use 30 months).
The standard was available long before that. The final stages of standardization move slowly. NSW actually participated in an mDL committee meeting in Melbourne in early 2019, and they could have used the draft standard as it was at that stage. They'd have had to make some small tweaks when the final version came out, but they'd have had something secure. Even if they didn't want to use the in-progress standard they could at least have looked at it to see how to build something good.
I'm curious - does your standard work with no communication between the users phone and whatever device is verifying the ID?
No. It uses either QR
Re: (Score:2)
The standard was available long before that. The final stages of standardization move slowly.
That is not a counter argument. The only reason you would be looking at a draft standard for implementation is to do gap assessments against a current product or practice, or to see what is likely to change from a previous edition of a standard.
Every standards body has had standards which have changed in non-trivial and expensive ways during the final review process. Hell both ISO and IEC have had standards that needed to be withdrawn immediately after publishing to change something that was fundamentally w
Re: (Score:2)
The standard was available long before that. The final stages of standardization move slowly.
That is not a counter argument. The only reason you would be looking at a draft standard for implementation is to do gap assessments against a current product or practice, or to see what is likely to change from a previous edition of a standard.
Your argument would hold a lot more weight if it weren't for the several other companies who launched implementations of the draft about the same time NSW did. Including Google.
Every standards body has had standards which have changed in non-trivial and expensive ways during the final review process. Hell both ISO and IEC have had standards that needed to be withdrawn immediately after publishing to change something that was fundamentally wrong with them which wasn't caught during review, or was mispublished due to a clerical error.
It was clear at the time that nothing like that would happen.
Designing a product or service, let alone one that gets pushed onto 8 million people, based on a draft of a standard would be supremely fucking stupid.
Mobile apps are very easy to update.
Re: (Score:2)
I left out the most important point: Even if NSW didn't implement the draft standard, they absolutely could and should have read it and lifted good ideas from it, rather than encrypting files with a four-digit PIN.
Re: (Score:2)
The only way to authenticate the data is to send it to the verifying device, so that it can verify the cryptographic signatures.
Right. And that is a major problem if, due to the belief that people do not want their phones communicating with the police, one of the requirements is 'no communication between the devices'.
Re: (Score:3)
The only way to authenticate the data is to send it to the verifying device, so that it can verify the cryptographic signatures.
Right. And that is a major problem if, due to the belief that people do not want their phones communicating with the police, one of the requirements is 'no communication between the devices'.
Well, people who are worried about that can just carry a plastic driving licence card, and share their home address with every grocery store clerk and bartender.
Re: (Score:2)
Well, that's true for security *as a whole*. But it's not that hard to do a better job at *this particular task*.
Re: Real crypto security is hard (Score:3)
Re: (Score:3)
Re: (Score:2)
Maybe so but you don't design a system for the 1% case, you don't make it less private/secure for 99% of the time. You digitally sign the document public/private key. This is not really necessary for anything like bars etc to validate age, they should just get internet if they want to validate ids.
Re: (Score:2)
Re: (Score:2)
No its simple.
Really you don't need cryto (apart from https), you need a link to a page on a secure server that stores a picture, and you are of age. For police more information could be provided with a valid login, like your name, you have a valid license etc.
The solution is simple you cannot trust the client at all, if someone private access to it.
Sure you can put an image on the app, just in case you have no internet but it can't be trusted, you could always write a app that looks identical.
This could in
No database check (Score:2)
Reading the article the crutch seems to be that the verification codes and machines that verify them all happen locally, it doesn't seem like the scanner takes the scanned code and verifies it against a central database which seems like a pretty glaring oversight, its like security based on the principle of "trust me bro!".
These systems should be at least as secure as Apple or Google pay or even a pin chip credit card. I doubt there is a way to make a digital ID like this work in a fully offline m
Re:No database check (Score:5, Informative)
It's even worse than that--the data is stored in an encrypted file whose key is a four digit PIN (i.e. 10^4 combinations at most required to decrypt the data). Once decrypted, the data is in a text file that is trivially edited, reencrypted, and reuploaded to the device. There's not even any checksumming done.
Re: (Score:2)
Re: (Score:2)
How do you get a photo into a QR code? And if the photo can't be verified as being genuine, the rest doesn't really matter, does it?
Re: (Score:2)
You don't the phone sends you a signed file via blue tooth or something, in the case you really are out of internet range, however if there really is no communication for a large part where police are involved then you probably have bigger police safety issues.
Re: (Score:2)
"The phone sends" - so now your phone is actively sending data to the police. Can't find any problems or pushback with that. Nope, none at all.
As for police communication - you know that does not require internet access, right? Police communication is generally by licensed radio (voice), not the public cell network.
Re: (Score:2)
Honestly, you wouldn't get much pushback. This is Australia, not the US. And this digital ID is completely optional. You're perfectly free to just show them your plastic license.
Re: No database check (Score:1)
Who has the private key? You canâ(TM)t generate a public key offline if you donâ(TM)t also give the generating party access to a private key.
Re: (Score:2)
I think public-key signatures should make this pretty hard to break or impossible with local-only verification as long as the verifying system is not compromised. In fact, just some scripting around PGP/GnuPG should be able to do it reliably. But apparently that is not what the government wanted. They probably went cheaper than possible in some place and lost it all as a result. Morons making decisions.
Re: (Score:2)
The problem is in how much data you can store in the QR code and make it readable under less than ideal circumstances. They use a 33x33 code which is only good for something like 50 characters; a 117x117 code would really be needed for an offline system, and I doubt you can pull that off on a phone reliably.
Re: (Score:2)
Makes sense. Although I would expect 117x117 to work fine on any reasonably modern phone. For example, the badly printed 117x117 sample on wikipedia gave my current phone no problems. Sure, for an older tablet with a 2MP camera I had to go down to the 57x57 there, but that tablet has a really bad camera. My guess would be this task can be done securely at around 1000 bits and up (half for the signature using some ECC signature scheme and half for the data), giving you something like a 61x61 QR code (1120 bi
Re: (Score:2)
How do you put a photo into a QR code? You don't. And if the photo can't be verified as genuine, it doesn't really matter how well the rest of the data is protected, does it?
Re: (Score:2)
How do you put a photo into a QR code? You don't. And if the photo can't be verified as genuine, it doesn't really matter how well the rest of the data is protected, does it?
Usually this is done by a type of fingerprint. If the photo is physically there it can be compared to that fingerprint. You basically do face-recognition on the picture for that. No idea whether that would work here for the offline case as I do not know how many bits are in a typical "fingerprint" for a face.
Re: (Score:2)
Then that requires every single person or entity that checks IDs for any reason to have facial recognition technology. Somehow I don't think that is going to fly.
Re: (Score:2)
Then that requires every single person or entity that checks IDs for any reason to have facial recognition technology. Somehow I don't think that is going to fly.
Only for the picture on the ID, not the actual face of the person that ID belongs to. It would probably be all rolled into one app and it would not be the problem that face recognition is usually because it is not general. Remember this is only about tying the QR code on the ID to the picture on the ID to prevent forgeries, not about tying the ID to the person presenting it. That part would still be done with the old Eyeball 1.0
Re: No database check (Score:1)
A fingerprint of a complex picture is still thousands of bits. Youâ(TM)re talking hundreds of millions of individuals, each requiring a complex set of private information. Encryption and PKI is impossible, since you canâ(TM)t generate complex challenge/response so there wonâ(TM)t be any privacy.
Re: (Score:2)
Remember these are formalized pictures that have to fulfill certain criteria. Also, this is about _one_ individual each time. It just needs to be hard to generated another matching picture that fulfills the same formalized picture requirements.
As your rant about the crypto, maybe get some actual clue on how that works? There is absolutely no requirements for PKI here. There is also absolutely no requirement for "challenge-response" stuff in PKI. There is no "privacy" requirement here, as this is about a fri
Re: (Score:1)
The point was about hiding the information that's embedded for privacy reasons while simultaneously allowing privileged entities to review the data. Definitely need some form of keys and encryption for that.
Re: (Score:2)
Sounds like the coupon generators that people on 4chan were exploiting. Burger King was giving away free Xboxes in a contest and you would get a coupon for the store to scan. You still had to pay taxes on the purchase and some genius generated a fake coupon and paid for the tax using his debit card.
Re: No database check (Score:2)
Re: (Score:2)
The COVID vaccinations just had your name, not photo. The photo was provided by your regular ID. And what fantasy world do live in where '99.9% of the time' you have internet access? Here is an coverage map for Australia: https://www.telstra.com.au/cov... [telstra.com.au] Doesn't look like 99.9% of the time there is internet access.
Re: (Score:2)
Re: (Score:2)
I'm confused as why coverage in Europe matters in the slightest for an Austrailan ID system (which is what the article is about).
Re: (Score:2)
It works 99.9% of the time, because 99.9% of the time, you're not in a any of those white patches. There are virtually no people there.
No Digital Signature? (Score:2)
It should be pretty straightforward. Have a digital signature that covers all the key data. This can be checked without any network connection assuming the verification app includes the public keys, which it should.
It's going to require a bit more data transfer than just a QR code, as you'll need to send the photo, name, birth date, and other critical information, along with the signature to the verification device, which then checks the signature and displays the data that was verified. (You can't trust
Re: (Score:2)
Re:No Digital Signature? (Score:4, Insightful)
That's great if you have network connectivity. I wouldn't count on that everywhere in Australia.
Re: (Score:2)
No, you make the entire DL, then calculate a 256 bit hash. Send the hash to the central repository, which checks the name and the hash and returns an arrest/don't arrest code back.
Better yet, implement https://www.iso.org/standard/6... [iso.org], which is secure and works offline.
Any Slashdot commentator could have done better (Score:4, Insightful)
Re: (Score:2)
Almost.
I am not a programmer, so had they hired me, they would have gotten nothing useful.
However...I do work for the gov't, so had they hired me, they would have gotten garbage, but it would have been overpriced and delivered late, but at least they would have gotten something.
Re: (Score:2)
We'd all be living in a utopia if these experts started to apply themselves!
Re: (Score:2)
We'd all be living in a utopia if these experts started to apply themselves!
Some of us have [iso.org]. It's not our fault if NSW ignored our work.
Re: (Score:2)
HAHA (Score:2)
Haha!
Hard to fake a centrally maintained database (Score:1)
Given a DL#, people should be able to pull up a redacted DL from a central database.
For most, the home address should not be provided.
Re: (Score:2)
But the purpose was for it to be an offline system for maximum utility... just like a physical DL.
Re: (Score:2)
If you need to be able to revoke licenses (either because some are issued by corrupt insiders or in error; or as part of a DUI penalty or the like) reasonably fresh revocation lists would be helpful; but even without them forgeries would not escape detecti
Re: (Score:1)
In my state, they know your vehicle inspection status, the owner, and the owner's driver's license and insurance status before they get out of the car. They don't even use the inspection stickers much any more. They just run the license plates. I suppose it wouldn't work if the wireless internet goes down.
Re: (Score:2)
I take it Noah Farmer is now a wanted man? (Score:2)
That's typically what happens when you embarrass the government.
I read the article - how it should be done (Score:2)
Handing your phone to the authorities? (Score:2)
Re: (Score:2)
What would lend anyone to think that they're not going to poke around an unlocked phone when granted the opportunity, particularly when they aren't under direct supervision?
(Which, btw, is going to be the typical case, as they already take your physical ID back to their cruiser to perform a lookup on you and write up any infractions they're planning to issue to you upon their return)
Yea, I'll be keeping my physical driver license, thank you very much.
I already have my vehicle insurance card available on my
I'm baffled. (Score:3)
My (admittedly layman's) impression is that this would be a practically textbook place to use an asymmetric key signature(most likely, in practice, a fair number of signing keys descended from a trusted root to ease revocation if some specific insider turns out to be selling fake IDs on the side and you don't want to revoke every license in one go): If the digital license is just signed by the issuer it wouldn't even matter(from a security perspective, there may be a privacy interest in adding some friction) if the file is stored in cleartext and trivially writeable; if you actually try to modify it you'll break the signature; and verifying the signature is doable even offline, since a cache of public keys and CRLs is of trivial size and only needs frequent updates if you are really, really, concerned about being on the cutting edge of catching all revoked IDs.
Is there some gotcha that I'm missing that would prevent signing from being trivially the right answer; or did they in fact achieve failure on a conceptual level that's as bad as it looks?
Re:I'm baffled. (Score:5, Informative)
Can anyone think of a plausible reason why they would have skipped the (seemingly obvious) option of taking advantage of cryptographic signatures
None whatsoever. Particularly since they were actually involved (a little) in the ISO 18013-5 Mobile Driving License standardization committee.
My (admittedly layman's) impression is that this would be a practically textbook place to use an asymmetric key signature
Indeed!
The ISO standard goes a step further, but a signature is the basis of ISO mDL security against forgery. The ISO standard has the issuer (e.g. DMV or other government entity) sign a "Mobile Security Object", which for each field in the mDL contains (1) a randomized ID, (2) a random salt and (3) a salted hash of the field value. During presentation, the mobile device sends the reader each field value and its randomized ID, as well as the whole MSO. The reader verifies the signature on the MSO, which proves that the license as a whole comes from the legitimate issuer. The reader uses the IDs to match each field (e.g. surname) to the appropriate entry in the MSO, uses the salt from that entry to compute the salted hash of the field name and value, and compares the result to the hash from the entry. If it matches, it knows that the field value is from the issuer and part of this license.
The per-field salting is so that when the reader receives the whole MSO and a subset of the fields it can verify those fields without being able to deduce any information about fields not provided.
The per-field IDs are so that the reader can't deduce even the presence of any fields that weren't revealed. Suppose, for example, that the DMV were to include a field indicating that the individual has a medical marijuana card. If the user chose not to present that field in some case, we would not want the reader to be able to determine its presence just by looking at the MSO. So the MSO does not contain field names and the IDs are randomized so the reader cannot know that, e.g. field 24 is the medical marijuana card.
The reader could potentially deduce some information about what fields are present from the number of fields in the MSO, so the standard recommends padding the MSO with a random number of bogus entries.
To prevent separate parties who verify your license from being able to collude to determine that you went to both of them, the standard recommends that MSOs be single-use, so you present a different MSO (with different random values and hashes) to each party. Of course, if the fields you present uniquely identify you they'll be able to link the presentations, but if, for example, you only presented the "over 21" field to both, they can't. (At present the binding between individual and credential is done with a portrait image, so if they keep copies of the portrait images they can match those to link the presentations. There are some ways to reduce the effectiveness of that, and in the future we'll move away from portrait image-based identity verification to fix it completely. The basic strategy is to move identity verification to secure hardware in your device and to have relying parties trust the device when it says it matched your biometric. This is very hard, but not impossible.)
revocation if some specific insider turns out to be selling fake IDs on the side and you don't want to revoke every license in one go
The standard's approach to revocation is a bit simpler: it recommends that MSOs have a short lifetime, say 30 days. So issuers don't have to deal with revocation lists, instead devices just regularly reach out to the server to get new MSOs and when a given ID is revoked, the server just refuses to give it any more. This means there's some revocation delay, but there's always some delay anyway, and this means that relying parties don't have to check revocation lists (which is good because people mostly don't bother).
Re: I'm baffled. (Score:1)
There are a lot of practical issues with all that. Not a single IoT device in government or business gets updates that frequently of any sort. Youâ(TM)re lucky if someone is even involved in doing updates yearly. Most devices will linger for 5-15 years without ever seeing an update. So every solution needs to be forwards and backwards compatible at every point of its lifecycle. This would mean currently publishing XP-era encryption which is relatively trivial to break due to its flaws and the fact it h
Re: (Score:2)
What are you going to sign, where are you going to put the signature, and how does that data get to whoever is looking at the ID? From the looks of it, this is purely a 'visual' ID. This makes sense - most people would not have a problem with police, bartenders, etc looking at their phone displaying an ID, but very few are going to want to allow their phone to communicate with those checking the ID.
So, sure you could sign data in a QR code (although even RSA2048 is going to increase the amount of data by
Superbad (Score:2)
So are mail-in ballots (Score:2)
Mail-in ballots are so easy to fake it's ludicrous. They're all identical. There are no unique, one-time-use serial numbers on them. Once removed from the signature envelope, there's no way to distinguish one from another nor is there any way to verify that your vote has been tallied the way you intended. There isn't any micro-printing, holograms, security threads or any other anti-forging methods in use by mints all over the world.
Re: (Score:2)
NSW claims (Score:2)
Apparently the police's QR-reader does download the DDL from the government database, so they can detect a fraudulent DDL. It's private businesses who don't have access to the original file, that are vulnerable. But tampering with a DDL is a crime so the government doesn't have to do anything.