6 ms·

The issue is that those are mechanisms to validate a card against a central authority. But most usages are in cases where the ID is self-validating and cannot b

by mcherm 5y ago

The issue is that those are mechanisms to validate a card against a central authority. But most usages are in cases where the ID is self-validating and cannot be authenticated against a central authority.

kadoban 5y ago
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
- 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
What prevents someone from checking an ID against a central-authority? I mean, doing so online isn't necessary -- there're plenty of validation mechanisms that could work offline, and presumably they'd be useful in the odd cases in which internet-connectivity isn't available. But internet-connectivity tends to be pretty accessible in most scenarios where an ID would need to be checked anyway, right?

by mcherm 5y ago

kadoban 5y ago

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

What prevents someone from checking an ID against a central-authority? I mean, doing so online isn't necessary -- there're plenty of validation mechanisms that could work offline, and presumably they'd be useful in the odd cases in which internet-connectivity isn't available. But internet-connectivity tends to be pretty accessible in most scenarios where an ID would need to be checked anyway, right?