Self-signed CA and digital signatures

Question

I am asked to design the public key crypto system for an IoT-like devices. These devices are going to be talking to each other over TCP/IP as well as communicating with a cloud-based API server. The firmware for these devices are developed in house.

The requirements are:

1. The devices should be able to authenticate each other's identity and talk over secure channels.
2. The API sever should also authenticate the identity of all devices.
3. Digital signature: all firmware updates will carry a digital signature and the devices should only upgrade itself if the signature is valid.

My solution so far for the first two requirements is to:

1. Generate a RSA key for the corporate (keep private in the corporate) and use it to generate a self-signed CA
2. Use the self-signed CA to generate a X509 cert for the API servers.
3. Use the self-signed CA to generate a X509 certificate for each device.
4. Add the self signed CA to each device trusted CA store.

I am new to this, so I still have some questions.

1. Is the above valid?
2. For the digital signing, as far as I can tell I can use the private key from step one to sign the firmware binaries. Then on the devices, can we just extract the public key from the corporate CA cert and use it to verify the signature?

Thanks.

Answer 1

1 - What you are doing is valid, you are doing good.

2 - You shouldn't use the key on step 1 to sign, but key from step 2. The key from step 1 is for the CA, and you should only use it for signing other certificates. You could create a dedicated certificate for signing firmware, or use the API endpoint certificate to sign them. It works the same.

The key from step 1 is the most sensitive part of your infrastructure. Treat is as the master-key. Use it only for signing other certificates.

Answer 2

Just an emphasize on ThoriumBR's answer.

Self signed certificates can be used on either of those approaches:

• simple test certificates with no to little value
• root of a PKI

For the latter use case, it is the central point of the whole PKI: everything loses any trust if it is compromised. For that reason, very few person can use it, and it is only (seldom) used to signed intermediary certificates.

The number of levels in intermediary certificates is given by the complexity of the organization: every person allowed to deliver (sign) certificates should own one (private) certificate for auditing reasons. That way it is possible to identify who is responsible for a certificate compromission.

Nothing enforces that, except best practices: the trust of a certificate cannot be higher than the trust you can have on all the process that delivered it...

Said diffently, a X509 certificate infrastructure is not that hard to build, xca is nicely documented graphical tool that should meet your needs. The hard part is to define secure procedures for delivery, renewal and (eventually) revocation of the certificates.