I want a private key embedded in a chip, that never leaves that chip, so all encryption and decryption happens on that chip—similar to how chip-and-pin credit cards work now. I'm identified by the corresponding public key. Then I want to embed that chip in my hand. Then I can unlock my car, house, computer, or phone and sign into any online service the same way: you send me a challenge token, I sign it with my private key then send it back.
I guess the approaches taken with U2F tokens here (and FIDO2) makes sense - have more than one token enrolled, and allow either to be used.
It's not perfect and there are usability issues around this, but they're mostly solvable. Needing both keys around to enrol into each service can be an issue, but this could be addressed by letting a user enrol other public keys as a delegate, and present a signed delegation token allowing that token to enrol a public key on behalf of an off-site token.
Revocation is the next issue - how do you revoke either of your tokens if stolen or compromised? PKI had this issue and ended up down the CRL Vs OCSP approaches. Clearly you need to be able to revoke without the token being present (maybe storing a signed revocation for A on your B token), and some kind of gossip-based network to spread the signed revocation around. That might avoid centralising it.
As long as your "chip" is designed as an ISO smartcard, you can also rely on pin protection (I'll ignore the implanted under skin aspect, other than to observe that does adjust the threat model as deniability around knowing the PIN is lost at that point. A duress PIN that validly unlocks but generates different keys would be a potential solution here for where mistaken identity can be used as an escape from an adversary).
Agreed, although most of this will end up wrapped up into the token and system itself, I suspect.
U2F is pretty much a "key" (some even visually looking like keys) that are used pretty much like a physical key - put the key into the keyhole (USB port), and press the flashing light. Done.
That level of UX is what we all need to build towards!
Well, lost or stolen hopefully wouldn't happen if it's embedded in my hand—that's the point of embedding it in my hand!
To protect against damage—which is a very real possibility, of course—I'd put identical chips in each hand, and if one fails or gets damaged, then you'd have to rotate keys by replacing both chips.
And you could have a third identical chip/key (or a different private key on another device in a safe somewhere) as a further backup, as my sibling comment recommends.
The security and privacy implications of this are horrifying to me, as are they to enough of the population that I doubt this will get widespread adoption.
Putting aside the embedded beneath the skin aspect (I share your concerns), this concept can actually work - see FIDO2 and U2F protocols. They're actually pretty good from a privacy perspective too, and give you unlinkability between services (as the key you present is derived from factors including the verified origin, i.e. URL, of the resource you're authenticating to).
Clearly the verified URL origin of something in the real world is complex, but there are ways to potentially make this work. Devices might have certificates for a URI, and this URI could be verifiable and convey attributes like the GPS coordinates to within 25m, that you can verify before authenticating. Users could presumably also whitelist certain origins (garagedoor.home.mydomain.net)
All of this apart from the subdermal part actually could work out well - a small number of people already do this via U2F, or even traditional smartcards.
I've thought about this a lot—I'm very interested in both security and privacy, so I wouldn't want to do this if I thought it would compromise either.
My current solution is that the device has three functions: encrypt/sign with private key, decrypt with private key, and send public key. They would be protected by a PIN—probably a six-digit alphanumeric pin. You might want to rate limit PIN attempts to one per second, as well.
With this scheme, I can't see how it would compromise privacy or security. No one can just scan your hand and know your identity, since you need the PIN to get your public key. And since all encryption/decryption happens on the chip, the chance that your private key gets stolen is pretty much as low as possible.
If you see any flaws with this scheme—I certainly wouldn't be surprised if there are, I just can't see any right now—please critique away!
