Certificate Management for IoT Devices
Written by: Brenna Belletti, Soracom Solutions Architect
Published: November 18, 2020
Challenge: Certificate Management at Scale
In IoT, the transition from pilot deployments to full-scale production represents a major step, and brings significant new challenges. Among the most common of these new challenges is handling certificate management across large numbers of devices. Because Soracom supports so many IoT developers, across so many different verticals, this is a pain point we see frequently and one we’ve come to understand well. Naturally, we’ve also helped to solve it by developing some specific tools that harness the power of the cloud to make credential management much simpler.
Typically, companies establish a process to generate device credentials and load them onto devices manually. This can be done at the factory during the manufacturing process, but it requires a level of trust that the manufacturer will keep the private credentials secure. It also adds time, complexity and cost to the manufacturing process.
At Soracom, we address these common challenges by building services that help accelerate time to market, reduce threat surfaces, and improve your bottom line. In some projects, this could mean using services like Soracom Beam to offload authentication and encryption from the device entirely. For projects that need to keep certificates on-device, Soracom Krypton enables a cellular IoT device to provision its own certificates leveraging the built in authentication that the SIM card provides.
Example
I recently had the opportunity to work with a customer who was evaluating the Nordic nrf9160 SiP and needed X.509 certificates on the device to connect to AWS IoT.
Nordic provides sample code for the Nordic nrf9160 development kit that guides you through the standard manual process for loading X.509 certificates that I described generically above. For example, this AWS FOTA application sample connects to AWS IoT using AWS X.509 certificates.
Nordic describes two methods for provisioning certificates onto the board: manually load in the X.509 certificates using the LTE Link Monitor tool in the nrfConnect for Desktop application, or add the certificates into the sample code. Both approaches require you to manually generate the certificates in AWS and do some work to copy them into a tool or into code. They even warn you for the second method that there is a security risk as the certificates are stored in the application binary, so once they are flashed you would want to remove them from the code. These options may be fine for prototyping, but will present quite a challenge when it comes time to scale to production.
Solution: Certificate Management with Soracom Krypton
We can automate this process by having the device generate and download its own certificates on demand through HTTPS. Normally with Soracom Krypton, you would make a single HTTP request and get all three certificates back. However, constrained devices like the Nordic board may not be able to receive such a large payload in one shot. We have created a new lightweight version of Krypton that allows you to make three successive requests and download each certificate individually.
To get started, follow the steps in our developer docs to configure your AWS and Soracom accounts for Krypton AWS IoT Provisioning.
As part of your device’s bootstrapping process, add logic to make 3 requests to Krypton to download the private key, public certificate, and root CA certificates respectively as follows:
- krypton.soracom.io:8036/v1/provisioning/aws/iot/bootstrap with a body of {“requestParameters”:{“skipCertificates”:true}}
- krypton.soracom.io:8036/v1/provisioning/aws/iot/certificates/{cert_id} (passing the certificate id that was returned in the previous request)
- krypton.soracom.io:8036/v1/provisioning/aws/iot/ca_certificate
To get started testing on your Nordic board, check out this sample code I created. It creates a new “Thing” in AWS via Soracom Krypton and downloads the X.509 certificates. It then uses them to connect to AWS IoT’s MQTT Broker. It subscribes to a topic defined in prj.conf and echoes back anything it receives onto a similarly defined publish topic. (See nrf9160 Simple MQTT sample for more details.)
With this sample code, unique device certificates no longer need to be stored in the application binary. A single application binary can be flashed across all devices and each device will still receive its own unique set of credentials. This reduces the security risk of exposing sensitive information while also reducing complexity.
I hope this solution reduces some complexity in your IoT project. If you’re ready to jumpstart your IoT project, sign up here for a one-on-one IoT Consultation with Soracom.
