3

I have multiple IoT devices that will be connected to a cloud based platform in order to control these devices.

In order to have a proper security I´m thinking about using Authentication Certificates so that each IoT device is a trusted element in my system. The problem here is that I don´t really know much about this topic and I would like to know:

  • When is this Certificate needed to be generated? During production in FW load on the IoT device?
  • Can I generate using a specific application those certificates? Does it have to be done by a certified authority?
  • Once I´ve confirmed a IoT device is correctly signed by the CA and a secure channel is established, is there any additional need for this certificate?
  • In case the previous question is afirmative, is there a Expiry Date of these certificates? And would this imply in any costs?
Improve this question

2 Answers 2

Reset to default
3
  • When is this Certificate needed to be generated? During production in FW load on the IoT device?

Each individual device should generate its own certificate during initial setup, to prevent any other party from observing the private key.

  • Can I generate using a specific application those certificates? Does it have to be done by a certified authority?

This first part depends on what your deployment target is, but since the most likely target is some form of Linux, you're looking at OpenSSL. After the device generates its certificate, it wants to send what's known as a Certificate Signing Request (CSR) to your own issuing CA - this can be a completely self-signed chain (and not involve an external CA), but getting an intermediary issuing CA isn't difficult either (usually for things like subdomains).

  • Once I´ve confirmed a IoT device is correctly signed by the CA and a secure channel is established, is there any additional need for this certificate?

You need the certificate every time you begin to authenticate/connect, after which (due to the way TLS works) it's exchanged for a symmetric key (that is, the certificate itself is no longer needed). However, there's nothing to automatically "delete on connect" these certificates that I'm aware of, especially because you usually need them because of the very real likelyhood of service interruptions (which would require you to reconnect).

  • In case the previous question is afirmative, is there a Expiry Date of these certificates? And would this imply in any costs?

Certificates have an expiry period. Valid policy lengths depend on the issuer (whoever validates/signs the CSR), so if you're doing the issuing this can be whatever you want. There would be no costs other than the extra processing time/bandwidth, plus access to the signing server. Note that some microservice platforms do things like rotate certificates every week/day/hour.

You should also check the cloud platform for recommendation on IoT device setup, because this is going to be a really common topic. For example, this topic in the Azure IoT documentation goes over at least some of this.

Improve this answer
6
  • First of all, thanks a lot for the detailed answer. Regarding the deployment target, I don´t really understand what do you mean (I'll have IoT nodes running baremetal, connected via BLE to a phone, which acts as a bridge with backend) On the other hand, each IoT device will be periodically connecting to backend, but my intention is to use the certificate for an initial symmetric key generation between both endpoints (Diffie-Hellman). After that, I would only use that symmetric key which would be stored in both backend and IoT device.
    – LazyTurtle
    May 7, 2020 at 11:18
  • And I´m also curious on how the certificates are generated in backed. Would there be aunique certificate per IoT device? This would imply generating a public/private keypair per device in backend, correct? Which is the typical way to proceed?
    – LazyTurtle
    May 7, 2020 at 12:02
  • Ideally, yes, there's a unique certificate per device. This means you can track the identity of each device individually, and the compromise of one device doesn't lead to the compromise of any other. Your proposed plan of switching to a symmetric key is exactly how TLS/SSL works (although it's a session, not permanent, key), so since your device almost certainly support it, I'd just open a normal connection.
    – Clockwork-Muse
    May 7, 2020 at 16:04
  • Interesting and relevant answer, but wondering how much of is really applicable on micro-controllers (per the OP), even today in 2021. For a start, many MCs do not even meet the assumption of running Linux (or embedded Linux and the like). I am plainly wondering about this OP, and cannot see much (except @stefan-vaillant's input).
    – Eric Platon
    Sep 17, 2021 at 1:42
  • 1
    @EricPlaton - While "of course it runs linux" may have been a bit of an assumption on my part, the device capabilities as described obviously include actually performing an SSL connection, so generating the certificate seems likely. If that isn't possible, the only real change to my answer is that a different device would need to generate the certificate (and probably immediately forget it) - at that point, it would have to be part of the firmware load.
    – Clockwork-Muse
    Sep 17, 2021 at 17:20
3

In addition to the great answer above: If you want to be super secure, you can generate&store the device specific private key in a hardware security module (HSM). Check out your microcontroller vendor for HSM support and related command/API support.

The generated private key can then be accessed using PKCS#11 API from OpenSSL. Note that this is bleeding edge: for sure start from the good answer above from Clockwork-Muse.

Improve this answer

You must log in to answer this question.

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