5 ms·

I'm not a cryptographer so I might miss something but I have the impression that - either a stolen card can be reused thousands of time meaning that it's so ea

I'm not a cryptographer so I might miss something but I have the impression that - either a stolen card can be reused thousands of time meaning that it's so easy to get a fake that it's not worth the implementation cost - either there is away to uniquely identify a card and then it becomes another identifier like tracking ids.

neom 3y ago
It would be neat if some authority like the passport office or social security office also provided a virtual ID that includes the features OP described and allowed specific individual attributes to be shared or not shared, revoked any time, much like when you authenticate a 3rd party app to gmail or etc.
- shuntress 3y ago
  These are the things that the post office should be handling.
- smeej 3y ago
  Putting on my conspiracy hat for a minute: They don't want to make it easy for you to authenticate anonymously. They obtain their surveillance data from the companies that tie you, individually, to your data. They'd be shooting themselves in the feet.
- plorg 3y ago
  Yeah, hell no.
ndriscoll 3y ago
Assuming you can make active queries to the verifier, you could do something like - Have your backend generate a temporary AES key, and create a request to the verifier saying "please encrypt a response using AES key A indicating that the user coming from ip X.Y.Z.W is over 16". Encrypt it with a known public key for the verifier. Save the temporary AES key to the user's session store. - Hand that request to the user, who hands it to the verifier. The verifier authenticates the user and gives them the encrypted okay response. - User gives the response back to your backend. Potentially the user could still get someone to auth for them, but it'd at least have to be coming from the same IP address that the user tried to use to log into the service. The verifier could become suspicious if it sees lots of requests for the same user coming from different IP addresses, and the service would become suspicious if it saw lots of users verifying from the same IP address, so reselling wouldn't work. You could still find an over-16 friend and have them authenticate you without raising suspicions though, much like you can find an over-21 friend to buy you beer and cigarettes. Since you use a different key with each user request, the verifier can't identify the requesting service. Both the service and the verifier know the user's IP, so that's not sensitive. If you used this scheme for over-16 vs. over-18 vs. over-21 services, the verifier does learn what level of service you are trying to access (i.e. are you buying alcohol, looking at porn, or signing up for social media). Harmonizing all age-restricted vices to a single age of majority can mitigate that. Or, you could choose to reveal the age bucket to the service instead of the verifier by having the verifier always send back the maximum bucket you qualify for instead of the service asking whether the user is in a specific bucket.
- hanspragt 3y ago
  There is no way my 94-year-old neighbor can successfully do any of that.
  - ndriscoll 3y ago
    That's the protocol for the computer, similar to oauth. From the user perspective, your 94-year-old neighbor would have an account with id.gov that they've somehow previously established (potentially the DMV or the post office does this for them), and the user flow works much like "Sign in with Google" buttons do today.
- woodruffw 3y ago
  If you can make active queries to the verifier, so can any adversarial party. These kinds of ZK-with-oracle schemes need to be very carefully gamed to ensure they're truly ZK, and not just "you learn nothing if you only query once." > and the service would become suspicious if it saw lots of users verifying from the same IP address This implodes under CGNAT, cafe internet, hotel internet, etc.
  - ndriscoll 3y ago
    You can make active queries, with the user's involvement. The verifier can potentially have a prompt with e.g. "The site you were just on would like to know that you are over 21. Would you like to share that with them?" We do need to get people onto ipv6 so CGNAT can die. Restricted services could potentially disallow signups or require more knowledge (e.g. full ID) if coming from shared IPs as a risk mitigation strategy, depending on how liable we want to hold them to properly validate age. If you've already signed up for facebook at home, obviously you don't need to validate your age again at the cafe. Fake IDs exist in the real world. The system doesn't have to be perfect, and we can say that there's some standard of reasonable verification that they should do for these sorts of cases. Personally I'm more in favor of an approach where sites label their content in a way where parents can configure filters (ideally using labels that are descriptive enough that we don't get into fights over what's "adult", and instead leave that decision to individual families), but if we're going to go an ID-based route, there are at least more private ways we could do it, and I think technologists should be discussing that, and perhaps someone at one of these big companies can propose it.
vlovich123 3y ago
mDL wide scale rollout works be using the trusted computing element that is part of your phone and enrollment would be the same as obtaining a driver’s license in the first place. There is no physical card - there is an attestation that only an enrolled device can hand out with revocation support in case of security flaws. Is it going to be absolutely secure? No. The cost just needs to be high enough that it becomes inaccessible to the vast majority of adolescents. Theft of your parents phone becomes a lot easier attack vector but phone biometrics/password requirements will thwart that for most parents. This doesn’t need to be 100% fool proof.
WalterBright 3y ago
You can also use fake ID to buy booze. Making it illegal is, by itself, enough to discourage a lot.
- j16sdiz 3y ago
  Those need some kind of face to face interaction. The perceived risk of being caught is much higher.
- mirekrusin 3y ago
  You can't run for loop on buying booze with fake id.
jlokier 3y ago
There's a unique identifier, but it's your secret and can't be used for tracking. Sites needing verification don't learn anything except that you "have" a token matching the condition they are checking. This includes not learning your unique identifier, so they can't use it for tracking. The issuer also doesn't learn anything about your verification queries. You have an incentive to keep the secret token to yourself, and would probably use existing mechanisms for that: You might manage like your phone number, private email and other personal accounts today. Not perfect, but effective most of the time for most people. You might decide to share it with someone you trust, like your sibling. That's up to you, but you wouldn't share it widely or with people you don't trust, even under pressure, because: To prevent mass reuse of stolen tokens, it's possible to use more cryptography to detect when the same token is reused in too many places, either on the same site or across many sites, without revealing tokens that don't meet the mass-reuse condition, so they still can't be used for tracking. If mass-reused tokens auto-revoke, they can't be reused thousands of times by anyone, and that also provides an incentive to avoid sharing with people you don't trust. I won't pretend this is trivial. It's fairly advanced stuff. But the components exist these days. The last paragraph above requires combining zero-knowledge proofs (ZKP) with other branches of modern cryptography, called multi-party computation (MPC) and perhaps fully homomorphic encryption (FHE).

neom 3y ago

It would be neat if some authority like the passport office or social security office also provided a virtual ID that includes the features OP described and allowed specific individual attributes to be shared or not shared, revoked any time, much like when you authenticate a 3rd party app to gmail or etc.

shuntress 3y ago
These are the things that the post office should be handling.
smeej 3y ago
Putting on my conspiracy hat for a minute: They don't want to make it easy for you to authenticate anonymously. They obtain their surveillance data from the companies that tie you, individually, to your data. They'd be shooting themselves in the feet.
plorg 3y ago
Yeah, hell no.

ndriscoll 3y ago

Assuming you can make active queries to the verifier, you could do something like - Have your backend generate a temporary AES key, and create a request to the verifier saying "please encrypt a response using AES key A indicating that the user coming from ip X.Y.Z.W is over 16". Encrypt it with a known public key for the verifier. Save the temporary AES key to the user's session store. - Hand that request to the user, who hands it to the verifier. The verifier authenticates the user and gives them the encrypted okay response. - User gives the response back to your backend. Potentially the user could still get someone to auth for them, but it'd at least have to be coming from the same IP address that the user tried to use to log into the service. The verifier could become suspicious if it sees lots of requests for the same user coming from different IP addresses, and the service would become suspicious if it saw lots of users verifying from the same IP address, so reselling wouldn't work. You could still find an over-16 friend and have them authenticate you without raising suspicions though, much like you can find an over-21 friend to buy you beer and cigarettes. Since you use a different key with each user request, the verifier can't identify the requesting service. Both the service and the verifier know the user's IP, so that's not sensitive. If you used this scheme for over-16 vs. over-18 vs. over-21 services, the verifier does learn what level of service you are trying to access (i.e. are you buying alcohol, looking at porn, or signing up for social media). Harmonizing all age-restricted vices to a single age of majority can mitigate that. Or, you could choose to reveal the age bucket to the service instead of the verifier by having the verifier always send back the maximum bucket you qualify for instead of the service asking whether the user is in a specific bucket.

hanspragt 3y ago
There is no way my 94-year-old neighbor can successfully do any of that.
- ndriscoll 3y ago
  That's the protocol for the computer, similar to oauth. From the user perspective, your 94-year-old neighbor would have an account with id.gov that they've somehow previously established (potentially the DMV or the post office does this for them), and the user flow works much like "Sign in with Google" buttons do today.
woodruffw 3y ago
If you can make active queries to the verifier, so can any adversarial party. These kinds of ZK-with-oracle schemes need to be very carefully gamed to ensure they're truly ZK, and not just "you learn nothing if you only query once." > and the service would become suspicious if it saw lots of users verifying from the same IP address This implodes under CGNAT, cafe internet, hotel internet, etc.
- ndriscoll 3y ago
  You can make active queries, with the user's involvement. The verifier can potentially have a prompt with e.g. "The site you were just on would like to know that you are over 21. Would you like to share that with them?" We do need to get people onto ipv6 so CGNAT can die. Restricted services could potentially disallow signups or require more knowledge (e.g. full ID) if coming from shared IPs as a risk mitigation strategy, depending on how liable we want to hold them to properly validate age. If you've already signed up for facebook at home, obviously you don't need to validate your age again at the cafe. Fake IDs exist in the real world. The system doesn't have to be perfect, and we can say that there's some standard of reasonable verification that they should do for these sorts of cases. Personally I'm more in favor of an approach where sites label their content in a way where parents can configure filters (ideally using labels that are descriptive enough that we don't get into fights over what's "adult", and instead leave that decision to individual families), but if we're going to go an ID-based route, there are at least more private ways we could do it, and I think technologists should be discussing that, and perhaps someone at one of these big companies can propose it.

vlovich123 3y ago

mDL wide scale rollout works be using the trusted computing element that is part of your phone and enrollment would be the same as obtaining a driver’s license in the first place. There is no physical card - there is an attestation that only an enrolled device can hand out with revocation support in case of security flaws. Is it going to be absolutely secure? No. The cost just needs to be high enough that it becomes inaccessible to the vast majority of adolescents. Theft of your parents phone becomes a lot easier attack vector but phone biometrics/password requirements will thwart that for most parents. This doesn’t need to be 100% fool proof.

WalterBright 3y ago

You can also use fake ID to buy booze. Making it illegal is, by itself, enough to discourage a lot.

j16sdiz 3y ago
Those need some kind of face to face interaction. The perceived risk of being caught is much higher.
mirekrusin 3y ago
You can't run for loop on buying booze with fake id.

jlokier 3y ago

There's a unique identifier, but it's your secret and can't be used for tracking. Sites needing verification don't learn anything except that you "have" a token matching the condition they are checking. This includes not learning your unique identifier, so they can't use it for tracking. The issuer also doesn't learn anything about your verification queries. You have an incentive to keep the secret token to yourself, and would probably use existing mechanisms for that: You might manage like your phone number, private email and other personal accounts today. Not perfect, but effective most of the time for most people. You might decide to share it with someone you trust, like your sibling. That's up to you, but you wouldn't share it widely or with people you don't trust, even under pressure, because: To prevent mass reuse of stolen tokens, it's possible to use more cryptography to detect when the same token is reused in too many places, either on the same site or across many sites, without revealing tokens that don't meet the mass-reuse condition, so they still can't be used for tracking. If mass-reused tokens auto-revoke, they can't be reused thousands of times by anyone, and that also provides an incentive to avoid sharing with people you don't trust. I won't pretend this is trivial. It's fairly advanced stuff. But the components exist these days. The last paragraph above requires combining zero-knowledge proofs (ZKP) with other branches of modern cryptography, called multi-party computation (MPC) and perhaps fully homomorphic encryption (FHE).