5

Similar to the question here, I'd like to apply the same question to a person.

For example, I have implanted a chip in my hand that holds an encrypted private key that serves as my personal unique identifier. As it is tied to my person physically, I have just a single origin for the key it holds.

I currently use this key to authenticate with my own servers. What I'd like to do is register this key's public component for use at work.

What vulnerabilities does this expose to my key and the servers I use it with, assuming that the key itself is adequately secure?
Should I consider creating additional private keys to identify me?

Community
  • 1
Steffan Donal
  • 103
  • 7
  • "I have implanted a chip in my hand" - this completely changes the question from a practical key management question, to a hypothetical question about future key management technology. I think either question would be ok, but you should be more clear about which one you're asking. – paj28 Apr 24 '16 at 19:48
  • Well, not entirely hypothetical, as I actually *have* implanted such a chip in my hand. – Steffan Donal Apr 24 '16 at 19:59
  • @SteffanDonal: (Just curious) If your key gets exposed, can you change it easily? or you have to go through surgery? – lepe Apr 25 '16 at 02:16
  • @SteffanDonal - well I wasn't expecting that! Can you tell me a bit more? How does it communicate with a computer? And does it just hold a single private key? Also, just for my curiosity, can you feel the chip in your hand? – paj28 Apr 25 '16 at 07:15
  • @lepe: I can change it using my smartphone's NFC feature easily! If I ever wanted to upgrade the chip I would have to slice into my hand with a scalpel. I injected the chip myself, and yes paj28, I can feel it under the skin - you can see it too, if you press on it! It's a tiny NFC chip in a glass capsule the size of a grain of rice. You can treat it as an equivalent to a USB stick that has a read-range of 1 inch at best. It has 808 bytes of usable storage, so I've had to store the very minimum of my private key to allow it to fit + encryption. I use a cheap NFC reader as my PC interface. – Steffan Donal Apr 25 '16 at 11:16
  • Was the private key generated on the chip in your hand, or in the smartphone? I suspect the latter, but would like to confirm. – Stone True Apr 29 '16 at 20:54
  • The two prime numbers were generated on an offline computer, then transferred to the chip encrypted using a serial NFC read/writer. @StoneTrue – Steffan Donal May 01 '16 at 19:40

2 Answers2

5

The problem with this approach is that the same identity is used by every destination, so sites can swap notes to see where you've been and draw correlations that you may not want to expose.

There are several ways to solve this issue, such as the one used in the FIDO U2F security key. In this case, the device contains a symmetric key (not an asymmetric key pair) and the necessary crypto hardware such that the secret key never needs to leave the device.

On site enrollment, the device creates a new public/private key pair and sends the public key to the server along with a "key ID" for that key. On authentication, the site sends to the browser the "key ID" for that user and expects the response to be signed with the corresponding public key.

But instead of storing the private key corresponding to each key ID, the ID is itself the private key encrypted with the device's secret symmetric key.

There are additional features to the protocol to make phishing impossible, but those are beyond the scope of this answer.

Note that this is only safe because the secret never leaves the hardware. The same principle is true for any hardware security token; it's the fundamental difference between a true security key and something like a thumb drive; a storage device can be copied. This is at odds with human-implanted keys because the hardware necessary to do actual crypto calculations while being powered by NFC requires too much area to comfortably fit under the skin.

Using a protocol like this one gives you the added advantage that it's already supported by other peoples' sites, so all you have to worry about is your local implementation. But it's not so good for SSH keys and such. If you're going to use it as an SSH key, you've got to get it to somehow communicate with your key agent (which probably means writing a new key agent).

tylerl
  • 82,225
  • 25
  • 148
  • 226
2

Using the same private key across separate domains is basically secure. If you authenticate to a system, you don't give away you private key, and that system cannot impersonate you. So you can use your key across work and personal systems, and a work system cannot then access your personal systems.

However, there are often reasons to use different keys. For example, your work may have a policy that they need a copy of all private keys used to access their systems. In that case, you would want to use a separate key.

There is also the privacy issue that tylerl mentions. And it is a bit more serious than most people imagine, because in most protocols the client certificate is transmitted unencrypted.

paj28
  • 32,736
  • 8
  • 92
  • 130