5 ms·

I see talk in this thread that uses the term 'private key'. Which makes me think about using a literal cryptographic private / public key combo for this sort of

I see talk in this thread that uses the term 'private key'. Which makes me think about using a literal cryptographic private / public key combo for this sort of thing. Say I have a private key, and I want a business to have a way to ID me. They give me a key associated with me in their database, and I encrypt it with my private key, and give the results back. Now when someone wants to do business with them in my name they must turn those results back into what the business has in their database. So long as I keep my key safe the business can leak data all they want. This would shift all the work for security over to the citizens though, which could have mixed results...

simonsarris 9y ago
And what happens when someone's private key leaks? Do they have to get issued a new one somehow? If someone has gone through 7 private keys, how do you know that the one person-claiming-to-be-someone is giving you the most up to date one vs an older one, etc. There would be a lot of non-trivial considerations by pushing all this on average joes (both as individuals and as people attempting to verify individuals). A system that appears secure but isn't is more dangerous. I can hear a 60 year old now: "Aunt Claire is stuck in london and needs money! We know its her, here's her [expired key] encrypted message!"
- kiddico 9y ago
  That is a solid question. The optimist in me says 'well if the private key is leaked we're in about the same spot we are now with SSNs'. Every other part of me just cries. In regards to "which version do we trust if a new key has been issued?": My gut says there would need to be a centralized system to for which ones have been voided, and which ones haven't. At that point what we're doing is making SSN's that we can invalidate, with the added disadvantage of being much more confusing to work with. I have no idea what the right answer is, but Aunt Claire is (possibly) in need so we need to figure this out fast.
- tomschlick 9y ago
  As a user above stated, use an oAuth service from the government. When at a business you could "prove" to their system who you are by authenticating with the govt service with your private key (most likely on a smart card like the military's CAC card). The business then gets an oauth token that you could revoke. If you lose your private key you would have to go to some government services office and bring additional documents to prove who you are just like a passport.
- dredmorbius 9y ago
  To prevent re-use of old keys, a key-revocation protocol should exist. There's an existing (though pretty crufty) version of this in PGP, though it relies on keeping your revocation key safe, which is a bit of a stretch as that's something you need ... once. A "bad keys" registry might be a useful / necessary thing. Enforcing a regular expiry might also be an option, though ... you'd have to think through that. Keep in mind that technology is continuously improving (or at least has been to date), and there might be a circumstance in which All Keys Suddenly Go Bad, which would have to be dealt with. (Figuring out ways in which to make such situations Less Obviously a Shitfest could be ... useful.) When I've very roughly scoped things out at Google Scale (> 3 billion registered Android profiles), and made modest assumptions such as 1% of users lose their token annually, you're looking at ~10,000 resets per day. So you'll have to have provisions for doing this in any system that's intended to be in the least part useful. As for attacks, I'd strongly suggest finding a good reference of 19th century financial frauds and reading through it. The fundamentals do not (generally) change. http://www.npr.org/sections/npr-history-dept/2015/02/12/385310877/how-scams-worked-in-the-1800s http://www.npr.org/sections/npr-history-dept/2015/02/12/3853...
Ajedi32 9y ago
> I encrypt it with my private key Don't you mean with your public key? Pretty sure encrypting things with your _private_ key is pretty unusual. (Unless you're talking about digital signatures with RSA.)
- kiddico 9y ago
  I think I am? I have no idea. I have a relatively weak understanding of cryptography.
  - dredmorbius 9y ago
    You would sign the value with your private key. That enables verifying the signature against your public key.
Qantourisc 9y ago
Basically you give the user a device that has the private key, but never exports it. eID uses this: https://images.duckduckgo.com/iu/?u=https%3A%2F%2Fimage.slidesharecdn.com%2Fbelgianeidcardtechnicaloverview-123627095274-phpapp01%2F95%2Fbelgian-eid-cards-technicalities-29-728.jpg%3Fcb%3D1277972488&f=1 https://images.duckduckgo.com/iu/?u=https%3A%2F%2Fimage.slid...
- cr0sh 9y ago
  I've written here on HN before that it should be a device that is issued that has the private key, but that private key is also hashed with a pin and some piece of biometric data. The pin itself would be changeable (forced every 90 days, at will anytime). The device would have a keypad. You would go down to some place (govt office) to get the device (card?). They would take the device, pop it in a reader/writer, and the device would ask you for a key and your biometric data (maybe a fingerprint?). The device would have on it a keypad and fingerprint reader (or whatever). Once you typed in your pin and scanned your fingerprint, it would generate a private key, hash all three together and store it in the card. This key would be "permanent" to the card (if you lose the card, you have to get another). The key wouldn't be saved anywhere (not in a govt database, etc). And it couldn't be retrieved from the card. To prove your identity, you would slot the card into a reader, swipe your fingerprint, type in your pin. If your pin and fingerprint plus key on card hashed matches the stored hash - then you are identified and the card outputs a "true" value to the reader. Otherwise, it outputs a "false" value indicating no match. Multi-factor auth - something you have (the card), something you know (the pin), something you are (the fingerprint/biometric). That's the basic gist or blueprint - essentially an ID card that can't have it's id read (not easily at least - I imagine that you could read it with proper decapping and electron microscopy), with a built in keypad and biometric read sensor in one unit. Anywhere you need to do a transaction to prove yourself, you need to use a reader (even online - so as a part of you getting your card, you would get a reader too). There's probably a ton in the scheme that I am missing or have wrong, but I think the basic idea is there, and I think it is possible to do with today's technology. The idea is that just having the card alone isn't enough. Just having the id number/key isn't enough. You need all three pieces for it to work. It isn't "rubber hose" proof - but then again, not much is or can be.

simonsarris 9y ago

And what happens when someone's private key leaks? Do they have to get issued a new one somehow? If someone has gone through 7 private keys, how do you know that the one person-claiming-to-be-someone is giving you the most up to date one vs an older one, etc. There would be a lot of non-trivial considerations by pushing all this on average joes (both as individuals and as people attempting to verify individuals). A system that appears secure but isn't is more dangerous. I can hear a 60 year old now: "Aunt Claire is stuck in london and needs money! We know its her, here's her [expired key] encrypted message!"

kiddico 9y ago
That is a solid question. The optimist in me says 'well if the private key is leaked we're in about the same spot we are now with SSNs'. Every other part of me just cries. In regards to "which version do we trust if a new key has been issued?": My gut says there would need to be a centralized system to for which ones have been voided, and which ones haven't. At that point what we're doing is making SSN's that we can invalidate, with the added disadvantage of being much more confusing to work with. I have no idea what the right answer is, but Aunt Claire is (possibly) in need so we need to figure this out fast.
tomschlick 9y ago
As a user above stated, use an oAuth service from the government. When at a business you could "prove" to their system who you are by authenticating with the govt service with your private key (most likely on a smart card like the military's CAC card). The business then gets an oauth token that you could revoke. If you lose your private key you would have to go to some government services office and bring additional documents to prove who you are just like a passport.
dredmorbius 9y ago
To prevent re-use of old keys, a key-revocation protocol should exist. There's an existing (though pretty crufty) version of this in PGP, though it relies on keeping your revocation key safe, which is a bit of a stretch as that's something you need ... once. A "bad keys" registry might be a useful / necessary thing. Enforcing a regular expiry might also be an option, though ... you'd have to think through that. Keep in mind that technology is continuously improving (or at least has been to date), and there might be a circumstance in which All Keys Suddenly Go Bad, which would have to be dealt with. (Figuring out ways in which to make such situations Less Obviously a Shitfest could be ... useful.) When I've very roughly scoped things out at Google Scale (> 3 billion registered Android profiles), and made modest assumptions such as 1% of users lose their token annually, you're looking at ~10,000 resets per day. So you'll have to have provisions for doing this in any system that's intended to be in the least part useful. As for attacks, I'd strongly suggest finding a good reference of 19th century financial frauds and reading through it. The fundamentals do not (generally) change. http://www.npr.org/sections/npr-history-dept/2015/02/12/385310877/how-scams-worked-in-the-1800s http://www.npr.org/sections/npr-history-dept/2015/02/12/3853...

Ajedi32 9y ago

> I encrypt it with my private key Don't you mean with your public key? Pretty sure encrypting things with your _private_ key is pretty unusual. (Unless you're talking about digital signatures with RSA.)

kiddico 9y ago
I think I am? I have no idea. I have a relatively weak understanding of cryptography.
- dredmorbius 9y ago
  You would sign the value with your private key. That enables verifying the signature against your public key.

Qantourisc 9y ago

Basically you give the user a device that has the private key, but never exports it. eID uses this: https://images.duckduckgo.com/iu/?u=https%3A%2F%2Fimage.slidesharecdn.com%2Fbelgianeidcardtechnicaloverview-123627095274-phpapp01%2F95%2Fbelgian-eid-cards-technicalities-29-728.jpg%3Fcb%3D1277972488&f=1 https://images.duckduckgo.com/iu/?u=https%3A%2F%2Fimage.slid...

cr0sh 9y ago
I've written here on HN before that it should be a device that is issued that has the private key, but that private key is also hashed with a pin and some piece of biometric data. The pin itself would be changeable (forced every 90 days, at will anytime). The device would have a keypad. You would go down to some place (govt office) to get the device (card?). They would take the device, pop it in a reader/writer, and the device would ask you for a key and your biometric data (maybe a fingerprint?). The device would have on it a keypad and fingerprint reader (or whatever). Once you typed in your pin and scanned your fingerprint, it would generate a private key, hash all three together and store it in the card. This key would be "permanent" to the card (if you lose the card, you have to get another). The key wouldn't be saved anywhere (not in a govt database, etc). And it couldn't be retrieved from the card. To prove your identity, you would slot the card into a reader, swipe your fingerprint, type in your pin. If your pin and fingerprint plus key on card hashed matches the stored hash - then you are identified and the card outputs a "true" value to the reader. Otherwise, it outputs a "false" value indicating no match. Multi-factor auth - something you have (the card), something you know (the pin), something you are (the fingerprint/biometric). That's the basic gist or blueprint - essentially an ID card that can't have it's id read (not easily at least - I imagine that you could read it with proper decapping and electron microscopy), with a built in keypad and biometric read sensor in one unit. Anywhere you need to do a transaction to prove yourself, you need to use a reader (even online - so as a part of you getting your card, you would get a reader too). There's probably a ton in the scheme that I am missing or have wrong, but I think the basic idea is there, and I think it is possible to do with today's technology. The idea is that just having the card alone isn't enough. Just having the id number/key isn't enough. You need all three pieces for it to work. It isn't "rubber hose" proof - but then again, not much is or can be.