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?


  • What do you mean by IOT-like devices? Phones? Tablets? Custom units designed to work over wifi/gsm specifically for you product? Apr 26, 2018 at 13:20
  • @ShaneAndrie Networking devices (Wifi and Ethernet) on custom boards. Custom built embedded linux OS.
    – srd
    Apr 26, 2018 at 14:59
  • Another Question, who 'Owns' the device. The customer or your company? Does it only talk to your infrastructure? This seems eerily familiar to a certain Parking Company I worked for. Apr 26, 2018 at 21:24
  • @ShaneAndrie ha ha, I am sure it is not the same company, but the customer earns the device. Where are you going with these? Thanks
    – srd
    Apr 26, 2018 at 21:44
  • Lol, I just had company I worked try something similar after they developed there offering and it was a horrid mess. Anyway, I was just trying to establish if your company maintains full control over the certificates. You may want to be looking a doing Private Root CA setup, and also possibly SCEP servers. Apr 26, 2018 at 22:04

2 Answers 2


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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .