Thread

1. dmurray · 1789628355 · focus · HN ↗

   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.

   1. crote · 1789630767 · focus · HN ↗

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

      1. dfox · 1789648967 · focus · HN ↗

         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.

         1. hedora · 1789659747 · focus · HN ↗

            I imagine a good forger would add wear marks to the barcode so it doesn’t scan for a plausible reason.

Unofficial Hacker News client; not affiliated with Y Combinator.