How to Provision and Store IoT Device Certificates
Every IoT device should operate over an encrypted channel. But how exactly does that security work as your fleet rapidly grows? Our recommendation is to use certificate authentication to deliver strong encryption while solving common fleet management problems. Today we’re showing how to provision and store IoT device certificates.
Certificate Authentication based on ECDSA
Golioth uses ECDSA encryption. You generate a root certificate and private key, use that key to sign all of your device certificates, then upload your public root certificate to Golioth. The last piece of the puzzled is placing a unique device certificate onto each device.
One method of doing so is to store the cert on a filesystem in non-volatile storage (NVS) that is separate from the firmware itself. Golioth has sample code to show you how, and that’s the subject of today’s video.
Root and Device Certificates
Generating the certificates is beyond the scope of this post, but the process is well-documented in the certificate authentication section of the Golioth docs. As a result of this process you will upload the generated public root certificate to Golioth. This lets Golioth securely connect to any device that uses certificates signed by your private root key.
Every device you put into the field needs to have a unique public/private key pair signed by your private root key. That device key and device certificate is what we store on the device file system.
Storing Device Certificates in a File System
Zephyr RTOS includes a filesystem which we have turned on in our certificate-provisioning sample code. Once the firmware is flashed to the device, use the Zephyr shell to create a directory in which the credentials are stored. This directory creation process can be further automated (through an mcumgr command or perhaps with some clever initialization in the firmware) but we chose to leave this as a manual step so that it’s obvious what is happening under the hood.
Credentials are transferred to the device over a USB connection using mcumgr because it facilitates writing to the filesystem over the serial connection. This is a separate process from updating the firmware, which means you can change the firmware without altering the device certificates. Likewise, you can update the certificates without overwriting the firmware.
Golioth Automatically Provisions Your Devices
We often discuss the security benefits of using certificates instead of pre-shared key authentication. But from a fleet-management standpoint there’s another huge benefit to doing so: automatic cloud provisioning for your devices.
This device was automatically added using certificate authentication
In a nutshell, you don’t need to tell Golioth that you’ve created new devices. As long as they have unique certificate credentials that were signed by your root key, Golioth will authenticate your device and automatically add it to your project.
We begin with an empty project in the video, and after adding the certificates to the device it automatically appears in the Golioth device list. The name of the device is specified in the certificate itself. You choose how you want to organize your device names when you create the certificates.
This may not feel profound with a test fleet of just one device. But as you scale, the ability to add hundreds or thousands of devices to your network becomes unmanageable. This is especially true if you are responsible for adding encryption keys and device names manually. Instead, upload your public root certificate to Golioth and we take care of the rest.
Test Out Provisioning and Storing IoT Credentials Now!
Your first 50 devices are free with Golioth’s Dev Tier. Take your test drive today and see how smooth and powerful the provisioning process can be!
Great post @mike !
Is there an instruction guide on how to load certificates with esp-idf ? (NVS or Filesystem).
Additionally I was wondering if there is a way to provide the certificate to the end device via CSR, maybe with the help of a Secure Element to generate a pair of keys and the CSR itself.
This way we could avoid to load individual certificates to the end device on the production floor. Thanks!
Hi @andrea.longobardi!
We don’t have an example for loading certificates using ESP-IDF (but we should! I’ve created a task for us to add one).
Because there are so many ways to provision and store certificates, and our goal is to support them all, the Golioth SDK doesn’t require any particular method. You could use XModem/YModem or something similar, and store it in either NVS or a filesystem (ESP-IDF doesn’t have a file transfer protocol built-in, but there are some examples out there).
It would certainly be possible to generate the key pair on the device, create a CSR, sign it, and then load the certificate back on to the device. Golioth does not provide a private CA service that can issue certificates, but there are several out there or you can roll your own. However, we still recommend loading certificates on the production line as the most secure and robust option (whether generating key pairs on the device or not) - otherwise you either need to hardcode a universal access token into every device or you need to have an unauthenticated endpoint for creating certificates, and in our experience there are often more unexpected issues when part of the provisioning process is performed outside the controlled environment of a production line.
Hi @sam !
Thanks for your feedback. We have solved this with some scripts that generates device specific certificate/key and put into an NVS partition bin file (that we can even encrypt if we want to).
We will evaluate if using a UART to upload certificate/key will give us any advantage, thanks for the suggestion!
Awesome! That sounds like a great solution. I would probably stick with that instead of using UART - using a programmer to directly write the flash should be faster and more reliable.
There are various approaches that can be used to add certificates to brand-new hardware during production. Generally, there are two considerations one has to take into account: where are the certificates stored (file system, secure element, …) and how are they transferred to a device (serial, programmer, …).
I would suggest you start by creating a file system and a directory where the certificates will be stored; take a look at our certificate provisioning sample on how to do that. Afterward, use mcumgr to manually send certificates over a serial connection and store them to a previously created directory in the file system. This way, certificates will continue to exist in the Flash memory even if the firmware is updated.
In a production scenario, the directory creation process should be automated without the need to use the Zephyr Shell, and instead of manually transferring certificates with
mcumgr, you can write scripts to take advantage of themcumgrcommand-line tool to automate this process further when a new device is connected to a PC host.