2

I have a number of devices which need to connect to a server via TLS. In order to make sure that only known devices connect to the server mutual authentication should be used. Similar the client devices should only trust a specific server certificate.

The firmware for each device therefore contains the client certificate and matching private key for client authentication and the server certificate for server authentication.

All it works correctly, but how can I handle this in a mass production ? I do not want to manually add to the firmware all the certs and keys and recompile the firmware for each device.

Is there any general rule/advice to handle this?

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
Die Go
  • 21
  • 1
  • 2
    This does not make sense for me (like your other quesion). The private key of the server should not be installed on the client (your device) but only the server itself. Also, is there really a server per device so that each device gets a different server certificate? I think you need to explain your use case in more detail. – Steffen Ullrich May 02 '20 at 09:23
  • if I understood correctly: Server cert: needed to be installed on the client device in order to be sure that the device it is connecting to the real server (not a fake or MiTM); Device cert: server needs this to trust the device; Private key stored in device: needed to decrypt the communication ( server will crypt data with public key of the device ) and server decrypt with its own private key ( device will have public key of server and encrypt data with this key ) If I have multiple devices I cannot use same keys/cert. How can I handle this without compile different image for each dev? – Die Go May 02 '20 at 11:49
  • 1
    Your understanding of SSL/TLS and how the keys are used is wrong, specifically your idea that the public/private keys are used for encrypting the traffic. Please study [How does SSL/TLS work?](https://security.stackexchange.com/questions/20803). Device certificates (which you did not even mention in your question) are only used when mutual authentication is needed, i.e. when the server needs to know which client this is. As I said, please explain your specific use case in more detail, especially since it looks like your understanding of the topic and therefore your conclusions are wrong. – Steffen Ullrich May 02 '20 at 12:01
  • Yes, sorry if I said something wrong , of course (but it was obvious :) I'm new to TLS/SSL. Basically I need to connect to a server ( and be sure that is my server ) and the server needs to be sure that the clients that are trying to connect to it are only "my devices" or trusted. I thought that I have to add server certs and devices cert (server's cert is the same for all of my devices, and devices certs (each one different ) to both server and each device ) in order to make this, and private/public keys for sharing data in an encrypted method. Is also this wrong? – Die Go May 02 '20 at 15:22
  • 1
    I've edited your question to make it more clear what you are trying to achieve. Note that you don't need to mention the public key explicitly since it is part of the certificate. – Steffen Ullrich May 02 '20 at 15:39
  • Thanks! So, each device will have: server cert ( same for all ) device cert ( different for each device ) private key of the device ( different for each device) And I will have to add these onto each device. Correct? Does the server needs to store the device cert, before the device tries to connect to it? – Die Go May 02 '20 at 15:58
  • It is sufficient that every client certificate is signed by th every same CA (Certification Authority) that the server recognizes as **trusted** – usr-local-ΕΨΗΕΛΩΝ May 02 '20 at 16:46

2 Answers2

1

If the requirement is that the server can authenticate a client device immediately after the device was first switched on then there is no other way but to ship devices where each has a unique certificate in the firmware or associated data. How this can be accomplished depends on the process how these devices are produced, i.e. how the firmware ends on the device, if associated data (like the certificate) can be added later etc. And this part is also not an information security problem, i.e. off-topic.

If there is instead some setup procedure involved when the device is first installed then it might be possible to create the certificate (or the CSR if a server side CA is involved, see below) during setup and inform the server about the new device and its previously unknown certificate. Of course there needs to be some authentication for this so that only valid devices announce themselves to the server. This can for example be accomplished if some unique key is shipped together with each device on paper or USB stick and is entered (or plugged in) as part of the setup procedure.

On the server side it might be possible to either store each client certificate for validation or have some private certificate authority (CA) which signs all the client certificates so that the server can simply accept all certificates issued by this authority and extract the device identity from the subject of the certificate. The approach of using a CA scales much better with many devices.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
1

I am not an expert of hardware manufactoring but here are my 2 cents on the topic.

Step one: set up a root PKI

On your server, you should create a custom Certification Authority (see my comment) that will be used later to sign all certificates. Configure your server to trust only that CA

Step two: you need an extra manufacturing step to enroll the devices

You should switch your device(s) on a first time at manufacturing time, at some stage. At that stage, before the device is shipped to the final user, have the firmware generate a custom private key, which will be unique for every device, and have that keypair signed with the CA certificate.

In order to enroll devices securely, i.e. make sure that no final user alters the firmware before the first boot, this process must be done at your physical facility. Either at the place the chip is manufactured, or at an intermediate stage of delivery chain but within your (office?) boundaries.

Step three: your devices will authenticate using a TLS signed CA certificate

One of the greatest features of TLS mutual authentication is that the server must not know in advance what client certificates are authorized, but they can be just signed by the same CA.

Other tips

Hardware-based key management, e.g. a TPM device, may be helpful a lot. a TPM device can use the Endorsement Key feature to help secure the firmware. The EK is issued by the manufacturer. I may assume that you are the manufacturer. While not a complete answer, TPM could be a good starting point to investigate.

Community
  • 1
usr-local-ΕΨΗΕΛΩΝ
  • 5,310
  • 2
  • 17
  • 35