I have a hobby electronics project in mind for an electronic key (think house key, car key. etc., i.e., physical key). It would be a PCB that would be inserted into a slot. Both the key and lock would have dedicated hardware, yet to be determined. I'm thinking about using something like public key encryption, with the public key being stored in the hardware in the key (call this the client) and the private key being stored in the lock (server). While this is just a hobby project and I understand that nothing can be 100% secure, the public key will need to be transmitted to the server from the client to lock or unlock the lock. This poses a problem. If the public key is transmitted, it can be intercepted. If it can be intercepted, then the key can easily be copied, rendering the encryption useless.

How can this be mitigated? I was thinking about the server sending a code of some sort, possibly based on a hardware-based random number generator, to the client that would be used to obfuscate the public key. Still, that doesn't solve the problem; the contents of the key are not an issue. If the obfuscated key is intercepted, then we are back at square one. I feel like I am part way to the solution with this, but am missing a key portion.

I'm getting the feeling that what I am after is simply impossible. I know that quantum-based encryption is supposed to address this, but I am not going there, even if I could.

Public key authentication doesn't involve the transmission of the keys. Instead some challenge response system is used. Ex: in Kerberos, A encrypts and integer N and sends that integer to B. B then decrypts that integer and then encrypts the integer N + 1 and sends it back to A. If when A decrypts it and sees N +1 then it's reasonable certain that B has the corresponding key.

You exchange keys once, when "binding" the client/server devices, and after that, the client remembers the key.
If you can do that securely - e.g. using a wire instead of wireless - then you're good.

Not that even SSL/SSH/HTTPS/etc work this way. A certificate authority acts as a trusted third party to reliably tell if if a host is legit or a fake...but to know that this authority is legit, you need to have physically been sent a key from them. This happens when you buy a Windows DVD / a new PC / download an OS ISO.

If a hacker intercepts your new PC / DVD / ISO, they could tamper with these keys and impersonate the trusted third party.
That's how the NSA defeats undefeatable encryption :wink:

The point of a public key is that it is public, you can hire a billboard and write the key there, or tell the Internet about it. No harm done.

If you want to protect a public key, I'd say you're doing something wrong, or at least you're not using the encryption that you have.

A public key is used to encrypt messages that only the owner of the private key can read.

Everybody can send such a message though.

From what I understand of it:

Vice versa, by encrypting a message with a private key, everybody can read the message (by using the public key), but they are certain it originates from the owner of the private key.

Since the message is readable anyway, sending the message in cleartext is just as efficient, where you sign the message with a checksum-block, a digital signature.

Obviously, nothing stops you from layering these exchanges on top of each other, for example using a public key of the server to send a digitally signed message (so the server knows it's you) to it.

Likely it needs some random injection to avoid sending fixed messages, which you can just copy and re-transmit.

Reading on Wikipedia, a lot more ideas exist.

Maybe the Diffie-Helman scheme would be better for you, where you have a shared secret https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

The whole point of public key is so that it is safe to be copied. It is only used to encrypt data, and the private key is used to decrypt it. The private key belongs to the server only. Everybody else can have the public key, and it is okay (and meant to be) that this public key is shared.

During the TLS handshake process, client encrypts initial "hello" message to the server using the server's public key. Server determines and verifies that the message can be decrypted with its private key. In HTTPS scenario, there's the whole CA trust happening to verify the identity of the server, but I think you can skip this process.

Once the trust is established (that yes, I am indeed talking to the real myserver.com, not some fake server someone else is hosting), then there are more exchanges between client and server to determine the cipher and the symmetric key to be used. Once the symmetric key is determined, all subsequent transfer is encrypted using this symmetric key.

I used the terms "client" and "server" because they closely match what would be happening here, with the only caveat that the connection between the client and server would be measured in millimeters, not kilometers. Understand that this would be an actual hardware device; the key would be an actual object you would hold. As such, and keeping with the tradition of keys having visible (public) cuts on the blade, I figured the public key portion of the public/private key encryption should be stored on the key card. The private key (tumblers in a standard lock) would be held within the server (physical lock in the door/whatever). This is not a requirement of the design.

The intent here is not to encrypt data, but to create a digital door/whatever lock using electronics in a manner that is difficult to hack and impossible to pick. My mentioning of public key encryption is because it is the closest software design to a traditional key/lock.

SiCrane actually gave a solution that is very much in line with what I am intending. I can use that.

Can you use the client's private key to encrypt the message, this way only valid clients can generate messages even though anyone can read them

You realize there is an entire industry dedicated to this, on both the white hat side and the black hat side. I spent a few years in that industry. Like the gambling industry, billions of dollars can be at stake and there are some really really clever people out there, not necessary working with you, so I hope you're only doing this as a hobby project.

If you're following SiCrane's idea, make sure your nonce (the integer sent, incremented, and returned) is not sequential, or else replay attacks are trivial. You will also want to include a timestamp in your challenge packet and discard any responses within a short window of time.

You electronic key, of course, is easy to duplicate infinitely and each copy will be recognized as valid by the lock. You might consider embedding a second authentication factor into your device (eg. a pin code). On a smartcard, the PIN is usually required to actually unlock the signing key on the device (consider it as a symmetric encryption key used to wrap the public key). Never send any kind of key, password, or PIN over the wire. Always consider the security holes in any process like setting or updating the PIN.

You should read the bible on the subject.

You realize there is an entire industry dedicated to this, on both the white hat side and the black hat side. I spent a few years in that industry. Like the gambling industry, billions of dollars can be at stake and there are some really really clever people out there, not necessary working with you, so I hope you're only doing this as a hobby project.

If you're following SiCrane's idea, make sure your nonce (the integer sent, incremented, and returned) is not sequential, or else replay attacks are trivial. You will also want to include a timestamp in your challenge packet and discard any responses within a short window of time.

You electronic key, of course, is easy to duplicate infinitely and each copy will be recognized as valid by the lock. You might consider embedding a second authentication factor into your device (eg. a pin code). On a smartcard, the PIN is usually required to actually unlock the signing key on the device (consider it as a symmetric encryption key used to wrap the public key). Never send any kind of key, password, or PIN over the wire. Always consider the security holes in any process like setting or updating the PIN.

You should read the bible on the subject.

Thanks. I've been giving this a lot of thought and it just gets harder and harder. I'll definitely have learned something on the other side of this!

I've got some idea on how to integrate the actual hardware to make copying harder, although I am aware that nothing will make it impossible.

If you want to really get into this, consider the physical security of the system too.

For example look at the ironkey USB devices for inspiration.

You need to embed your hardware chips in a resin which causes unrecoverable Destruction of the hardware and data in the event someone tries to take the device apart to dump it's contents into a file using analysis tools.

The ironkey devices also have a three strikes auto destruct like something out of mission impossible. Very cool...