Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security

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

This discussion has been archived. No new comments can be posted.

'Tough To Forge' Digital Driver's License is Easy To Forge

Comments Filter:
  • ... or DLLs (Score:5, Funny)

    by Errol backfiring ( 1280012 ) on Wednesday May 25, 2022 @09:55AM (#62564934) Journal

    digital driver's licenses, or DDLs

    Just another DLL hell then.

  • by MpVpRb ( 1423381 ) on Wednesday May 25, 2022 @10:10AM (#62564974)

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

    • by gweihir ( 88907 )

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

    • 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

    • by Anonymous Coward
      Come on, developing new cryptographic algorithms and implementing cryptographic primitives correctly is difficult, but this should be standard fare: Make the driver's license a signed message from the government and verify the signature to see that the message hasn't been modified. The implementation could be a small shell script with a few invocations of OpenSSL.
    • ..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

    • 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

      • The fact that they were even trying to hide the license data from the user suggests that they screwed up well before they reached the implementation phase and ended up hiding it incompetently.

        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
    • by swillden ( 191260 ) <shawn-ds@willden.org> on Wednesday May 25, 2022 @12:22PM (#62565444) Journal

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

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

      • by FeelGood314 ( 2516288 ) on Wednesday May 25, 2022 @03:46PM (#62566054)
        Maybe ISO 18013-5 is a good standard. I can't tell, I don't feel like paying 195 whatever to find out. I've been burned by ISO standards that refer to other standards and having to buy 3 different standards to find out the key pad requirement I was looking for was that the cancel button be in a specific colour of yellow. I wish everyone would avoid non-open standards. If only there was another model to get people to agree on how to do things.
        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.
        • by swillden ( 191260 ) <shawn-ds@willden.org> on Wednesday May 25, 2022 @03:58PM (#62566088) Journal
          Yeah, the ISO business model is weird. The standards are openly available until they become published standards, at which point they are no longer redistributable. This is how ISO funds its administrative operations.
        • 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

      • by bws111 ( 1216812 )

        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

        • 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

          • 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

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

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

          • by bws111 ( 1216812 )

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

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

    • by hey! ( 33014 )

      Well, that's true for security *as a whole*. But it's not that hard to do a better job at *this particular task*.

    • You don't need crypto here, all you need is qr code that says "my document number is ABC123". Cop uses the app to scan it and asks a trusted server, "please show me doc with number ABC123". If the mug don't match, then the guy doesn't have a license, easy.
      • One of the design criteria was that it has to work offline
        • 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.

          • It's Australia, 1% is probably the cases where they have Internet. And as swilden have pointed out in numerous posts already there exists a perfectly fine ISO standard for how to create digital drivers licenses that works offline and does not have this problem. It's not unsolvable.
    • 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

  • 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)

      by Zak3056 ( 69287 ) on Wednesday May 25, 2022 @10:20AM (#62565022) Journal

      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.

      • by idji ( 984038 )
        It makes sense that this App needs to work offline. But surely they could have put a checksum into the JSON that was created with a private key by the NSW Department of Transport. The app then has the public key and can ensure that the checksum was created by the private key. This would work offline. And that second APP would only need to scan the QR Code. That QR Code contains all enough of the data from the license that the second app can display the license number, date and a verification that the checks
        • by bws111 ( 1216812 )

          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?

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

            • by bws111 ( 1216812 )

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

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

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

    • by gweihir ( 88907 )

      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.

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

        • by gweihir ( 88907 )

          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

          • by bws111 ( 1216812 )

            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?

            • by gweihir ( 88907 )

              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.

              • by bws111 ( 1216812 )

                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.

                • by gweihir ( 88907 )

                  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

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

                    • by gweihir ( 88907 )

                      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

                    • by guruevi ( 827432 )

                      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.

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

    • You can do offline doc like COVID vaccinations, but why would you, 99.9% of the time you can ask a trusted server, so why don't you?
      • by bws111 ( 1216812 )

        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.

        • Australia is mostly undiscovered continent. I mean in real world, like Europe, you have mobile internet pretty much everywhere, not connected is not a thing.
          • by bws111 ( 1216812 )

            I'm confused as why coverage in Europe matters in the slightest for an Austrailan ID system (which is what the article is about).

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

  • 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

  • by trevc ( 1471197 ) on Wednesday May 25, 2022 @10:28AM (#62565054)
    They could have hired any one of the Slashdot commentators and got an unbreakable system.
    • 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.

    • We'd all be living in a utopia if these experts started to apply themselves!

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

    • by Megane ( 129182 )
      But what if Slashdot had hired one of those guys as an editor?
  • Haha!

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

    • But the purpose was for it to be an offline system for maximum utility... just like a physical DL.

      • What puzzles me is why they didn't sign the blob of information covering all the fields on the license: computationally infeasible to alter it without breaking the signature; and checkable offline with just a copy of the issuing authority's signing key.

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

        • by Megane ( 129182 )
          Do you know how many bits you can store in a QR code? It becomes quite computationally feasible at that size. Still, what they used seems to be worse than a 32-bit CRC in regards to being able to forge it through brute force.
  • That's typically what happens when you embarrass the government.

  • The author was too kind to the New South Wales government. They were 100% incompetent. The ID should only have a QR code that is signed with an expiry date. The person scanning the code should have a device that accesses the central database, the database should check the date and if it's valid return enough information to validate the QR holder (probably a picture) and whatever information the scanning individual is allowed to know (in most cases above or below the legal drinking age). No information s
  • What happens when you present your unlocked phone to the authorities? Is that the same as granting a their request to search your car, as in are they now free to rifle through your texts/pictures/whatever for proof of illegal activity?
    • by Arethan ( 223197 )

      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

  • by fuzzyfuzzyfungus ( 1223518 ) on Wednesday May 25, 2022 @12:08PM (#62565400) Journal
    Can anyone think of a plausible reason why they would have skipped the (seemingly obvious) option of taking advantage of cryptographic signatures to protect the 'license' data from tampering; rather than doing some goofy obfuscation that does nothing to detect modified files?

    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)

      by swillden ( 191260 ) <shawn-ds@willden.org> on Wednesday May 25, 2022 @01:01PM (#62565562) Journal

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

      • 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

    • by bws111 ( 1216812 )

      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

  • Guessing I can keep using my McLovin driver's license just a little longer.
  • 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.

    • For the states where this isn't a lie, you'd still have a rather large problem with getting all the people from both parties watching the process to agree on who to add ballots for and not tell anyone. Then you'd need to rope in even more people, again from both parties, to hide the mismatch between envelope count and ballot count. The orange idiot you worship lost, sorry.
  • ... electronic verification system used by police ...

    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.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (7) Well, it's an excellent idea, but it would make the compilers too hard to write.

Working...