4 ms·

With pubkey crypto you could easily allow validating with a self-contained device. That's just a signature check. The obvious way to do that has some drawbacks

With pubkey crypto you could easily allow validating with a self-contained device. That's just a signature check. The obvious way to do that has some drawbacks though, the big one being that if the private key ever leaks, your whole system is now useless and needs to be replaced (cards, verifiers and all). And you'd need to either generate all the cards in one place, or the private key would need to be available in multiple places. Not really a recipe for success long-term.

_Nat_ 5y ago
> The obvious way to do that has some drawbacks though, the big one being that if the private key ever leaks, your whole system is now useless and needs to be replaced (cards, verifiers and all). That's a problem addressed with [public key infrastructure (PKI)](https://en.wikipedia.org/wiki/Public_key_infrastructure https://en.wikipedia.org/wiki/Public_key_infrastructure). In practice, it could be done pretty securely and cheaply.
- Dylan16807 5y ago
  > That's a problem addressed with [public key infrastructure (PKI)] I don't really agree. Yes, you want to use PKI. But it doesn't solve the problem of needing to immediately update all your equipment when there's a key leak, and replace or reprogram a huge number of cards. PKI just makes things a bit smoother in general. My suggestion is pretty simple. Have a few different locations that sign keys, have them all sign each card, and require multiple valid signatures. Exact details up to the implementer, but that way you could have at least one key leak without causing any user hassle.
jcrawfordor 5y ago
There's been multiple efforts towards some type of PKI verification of driver's licenses, but they've all failed to gain adoption for various reasons. Perhaps the simplest is this one: driver's licenses are not really intended by the state to be verifiable offline, as in basically every case the state has to verify a driver's license they will need to perform an online check anyway (for revocation, for example, if not also for warrants and the whole NCIC gamut). So the level of motivation for the state (and more specifically the AAMVA which promulgates standards for driver's license) to implement this kind of verification is pretty low. Add to that the moral hazard of normalizing digital imaging of driver's licenses (which is a real concern as "digital ID" schemes or anything that looks like one face significant political opposition in the US) and practical challenges (cryptographic signatures compact enough to add to the PDF417 are possible but not as well standardized, the federal government has consolidated cryptographic ID efforts on ICC "smart cards" which are costly) and it's just a hard sell.
- porker 5y ago
  > cryptographic signatures compact enough to add to the PDF417 are possible but not as well standardized Do you know which are compact enough while remaining secure? I looked into this recently and failed to find one. Went for online verification in the end so data being signed was minimal.
  - _Nat_ 5y ago
    [Removed: Mistaken information.]
    - nemo1618 5y ago
      Signatures aren't just uniformly-distributed entropy, like hashes are; they encode real information, e.g. elliptic curve coordinates. Hashing and truncating the signature would destroy that information, meaning the signature could no longer be verified.
      - _Nat_ 5y ago
        Ick, yeah, you're right: might've been thinking hash-then-sign, but backwards.
  - jcrawfordor 5y ago
    An ECDSA signature for example can be represented as 64 bytes with good security, and adding 64 bytes to a PDF417 isn't too big of a deal. That's basically just the curve coordinates and nothing else though, so the verifying device has to either guess-and-check or use some other data to figure out what public key it should be verifying against, and there's no expiry or anything like that. In practice, now that we have elliptic curve algorithms that tend to allow very compact keys at a good security level, the bigger problem is less the actual cryptographic signature and more all the PKI metadata that normally needs to be tied to a signature to make it useful (especially if you have multiple levels of authority, which you probably want to or revocation becomes a huge problem). There are ways around carrying around PKI metadata with the signature (i.e. a normal x509 certificate) but there are tradeoffs and it's not like a well-established standard, which tends to make government organizations uncomfortable about adoption.
kuschku 5y ago
In the EU, most states have eID systems. The German system is as follows: You've got a central agency, responsible for IDs, paperwork and currency, with a root key in an HSM. From this key, intermediate certificates are generated for each ID production plant. This HSM is kept offline in the vault that also keeps the mint masters for coin and currency production. The ID production plants then sign IDs with their intermediate key, also kept in an HSM, and tack their own certificate on. The ID now has an X.509 certificate, or rather multiple ones, with a certificate chain going back to the root certificate of the agency. Now if you send a correctly signed request via NFC to the ID, the ID will generate a response in its own HSM, and return a signed response with the whole certificate chain. Such a request can be "given the following date, is the owner of this ID above 16?" (18, 21 are also available). The request can also be "what is the full personal data for this person?" To send such a request, the request also needs to be signed, also with a certificate chain going back to the same root CA. The agency provides certificates with different features enabled or disabled to different users. e.g. a bar can get one that allows them to query IDs for "are you 18 today?" with a certain limit of how many requests per ID they can make per day (the ID verifies that) to avoid brute forcing the actual birthday. This is for example used in fully automated cash-operated cigarette dispensers. You can also get a certificate that allows you to request all ID data, but is restricted to your own ID.
- zeeZ 5y ago
  From my anecdotal experience working with those cards, they'll fail and brick early into your brute force attempt anyway. The card can use the date in the certificate provided to approximate the current date, and will remember the last good date it saw, so you can't just decide to change the date and do another x years old check. AFAIK there is no "rate limit" for those.

_Nat_ 5y ago

> The obvious way to do that has some drawbacks though, the big one being that if the private key ever leaks, your whole system is now useless and needs to be replaced (cards, verifiers and all). That's a problem addressed with [public key infrastructure (PKI)](https://en.wikipedia.org/wiki/Public_key_infrastructure https://en.wikipedia.org/wiki/Public_key_infrastructure). In practice, it could be done pretty securely and cheaply.

Dylan16807 5y ago
> That's a problem addressed with [public key infrastructure (PKI)] I don't really agree. Yes, you want to use PKI. But it doesn't solve the problem of needing to immediately update all your equipment when there's a key leak, and replace or reprogram a huge number of cards. PKI just makes things a bit smoother in general. My suggestion is pretty simple. Have a few different locations that sign keys, have them all sign each card, and require multiple valid signatures. Exact details up to the implementer, but that way you could have at least one key leak without causing any user hassle.

jcrawfordor 5y ago

There's been multiple efforts towards some type of PKI verification of driver's licenses, but they've all failed to gain adoption for various reasons. Perhaps the simplest is this one: driver's licenses are not really intended by the state to be verifiable offline, as in basically every case the state has to verify a driver's license they will need to perform an online check anyway (for revocation, for example, if not also for warrants and the whole NCIC gamut). So the level of motivation for the state (and more specifically the AAMVA which promulgates standards for driver's license) to implement this kind of verification is pretty low. Add to that the moral hazard of normalizing digital imaging of driver's licenses (which is a real concern as "digital ID" schemes or anything that looks like one face significant political opposition in the US) and practical challenges (cryptographic signatures compact enough to add to the PDF417 are possible but not as well standardized, the federal government has consolidated cryptographic ID efforts on ICC "smart cards" which are costly) and it's just a hard sell.

porker 5y ago
> cryptographic signatures compact enough to add to the PDF417 are possible but not as well standardized Do you know which are compact enough while remaining secure? I looked into this recently and failed to find one. Went for online verification in the end so data being signed was minimal.
- _Nat_ 5y ago
  [Removed: Mistaken information.]
  - nemo1618 5y ago
    Signatures aren't just uniformly-distributed entropy, like hashes are; they encode real information, e.g. elliptic curve coordinates. Hashing and truncating the signature would destroy that information, meaning the signature could no longer be verified.
    - _Nat_ 5y ago
      Ick, yeah, you're right: might've been thinking hash-then-sign, but backwards.
- jcrawfordor 5y ago
  An ECDSA signature for example can be represented as 64 bytes with good security, and adding 64 bytes to a PDF417 isn't too big of a deal. That's basically just the curve coordinates and nothing else though, so the verifying device has to either guess-and-check or use some other data to figure out what public key it should be verifying against, and there's no expiry or anything like that. In practice, now that we have elliptic curve algorithms that tend to allow very compact keys at a good security level, the bigger problem is less the actual cryptographic signature and more all the PKI metadata that normally needs to be tied to a signature to make it useful (especially if you have multiple levels of authority, which you probably want to or revocation becomes a huge problem). There are ways around carrying around PKI metadata with the signature (i.e. a normal x509 certificate) but there are tradeoffs and it's not like a well-established standard, which tends to make government organizations uncomfortable about adoption.

kuschku 5y ago

In the EU, most states have eID systems. The German system is as follows: You've got a central agency, responsible for IDs, paperwork and currency, with a root key in an HSM. From this key, intermediate certificates are generated for each ID production plant. This HSM is kept offline in the vault that also keeps the mint masters for coin and currency production. The ID production plants then sign IDs with their intermediate key, also kept in an HSM, and tack their own certificate on. The ID now has an X.509 certificate, or rather multiple ones, with a certificate chain going back to the root certificate of the agency. Now if you send a correctly signed request via NFC to the ID, the ID will generate a response in its own HSM, and return a signed response with the whole certificate chain. Such a request can be "given the following date, is the owner of this ID above 16?" (18, 21 are also available). The request can also be "what is the full personal data for this person?" To send such a request, the request also needs to be signed, also with a certificate chain going back to the same root CA. The agency provides certificates with different features enabled or disabled to different users. e.g. a bar can get one that allows them to query IDs for "are you 18 today?" with a certain limit of how many requests per ID they can make per day (the ID verifies that) to avoid brute forcing the actual birthday. This is for example used in fully automated cash-operated cigarette dispensers. You can also get a certificate that allows you to request all ID data, but is restricted to your own ID.

zeeZ 5y ago
From my anecdotal experience working with those cards, they'll fail and brick early into your brute force attempt anyway. The card can use the date in the certificate provided to approximate the current date, and will remember the last good date it saw, so you can't just decide to change the date and do another x years old check. AFAIK there is no "rate limit" for those.