how to build device authentication and key distribution between raspberry pi and server

Question

I have several raspberry pi devices, and I want to link them to one web application securely with ssl in public key infrastructure. and the raspberry pi should keep a credential key inside its memory for the device authentication. But I have two issues 1. who(raspberry pi or server) should generate the key pairs 2. who keeps the private key.

so for the first issue,I 'd like to follow the example of Amazon EC2 service. where the server instance generates the key pairs, and server keeps the public key and send the private key to user. One personal reason is, I want a group of raspberry pi to share the same key if they want to connect to one particular service. so each particular service would generate a key pair and share it with a group of devices linked to the service. if we allows each device to generate a key pair for the service, it is hard for the server to control the access, right?

for the second issue, as what aws does, the private key is send to the user,that also means we have to ensure the private key given to the user/device securely. But I am wondering if it is a threat to issue the same private key to many devices, that if one device's key is stolen, the whole service on the server side is compromised. in that reason, is it even better to give these devices a public key than a private key?

please correct me if my guess is wrong based on my limited security knowledge

Answer 1

It would be best & the most secure if you wrote a short script that could generate a keypair on each raspberry pi and then copied the public key to the server (e.g. scp). This way your private keys are on the pi's in the way the system is intended for.

It doesn't matter who generates the key's per say, just how they're transported. You can think of it as it doesn't matter if Lowes or Home depot makes the keys, just that everyone gets the correct key transported to them without getting them copied along the way. You always want your private keys to be kept secret, but it doesn't matter if a public key is intercepted.

The most secure thing is to say, client1, client2, and client3 are authorized to talk to the server. In other words, the server says, I know these three clients individually and can decide later on if one of them has gone AWOL and stop talking to them until they present a new proper key.

It would be a slight inconvenience to not copy the same keys across all devices, but it will save you headaches down the road if security is compromised for any reason, will keep your system from grinding to a halt while you figure out what went wrong, and is the proper thing to do.

(Case 2) But, it depends on how your devices are talking to each other. If it is through ssh, the above is what you would want to do. If you are using ssl and https just to make sure that the end user on a pi knows that they are, in fact, connected to the server, then you would have a private key on the server and authenticate the public ssl certificate on all of your pi's via your browser or whatever. It doesn't matter if any pi's are compromised in this regard, since all your ssl certificate is doing is telling the pi's that they are, in fact, talking to the server in authority. Your only secret key to be worried about would then be protected the server itself (don't share this with your pi's).

Ultimately it depends on who needs to be authenticated. If people need to know that the server is the real server, then case 2 would apply. If the server needs to know that its' clients really are who they say they are, case 1 applies.