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.

 

I still think that there is something you might be missing about public keys, that is very important to understand:
Using your physical metaphors, the lock is the public key, and the key is the private key.

Supposing you have a lock on a door (public key). Anyone can come and copy this lock when you are not looking. But you don't care, because that would just enable them to lock another door with the copied lock. It would not enable them to create a copy of the physical key (the private key). As such, they would now have 2 doors which they cannot open...

That is the whole beauty of asymmetric encryption (the public/private encryption), and it's what makes it special: Having access to a lock, does not mean you can manufacture a key to open it...

So as long one device remains solely in your possession (the key in your pocket), it doesn't matter who has access to the lock. However, if someone steals your key (the private key) you are in trouble...

It would not enable them to create a copy of the physical key (the private key)

This is actually a poor analogy this direction too.

Take a lock barrel to any locksmith and they can use it to make a key for it :)

It's also moot. If I were to use RSA for this, both the lock and the key would need copies of the public/private keys. The key will not just be data storage; it will have its own processor doing encryption/decryption and authentication. Both the key and the lock will need to be able to both encrypt and decrpyt and the public key only allows encryption. That leaves me with symmetrical encryption, which it perfectly fine.

While it is not, nor has it even been, my intention to make the best/most secure lock and key (the NSA wont be locking their doors with it!), I still want to do this well. I have a LOT to think about!