With IoT’s gaining popularity, it has become a must have for many businesses, but as any emerging technology, IoT has been also grabbed the attention of hackers. Most IoT attacks from small attacks directed to specific companies, to large scale attacks such as the attack on DNS infrastructure by the Mirai Botnet, have a weak identity story to manage the IoT devices in common. As this space matures, it is our responsibility to apply best practices to protect users around the world from these bad actors. In this document we will share a guide outlining best practices to help you architect a secure and compliant device provisioning system.
When creating new IoT devices, it is difficult to design a secure identity bootstrapping story due to the problem of having to create devices at scale while also enabling the devices to authenticate securely with the cloud. This challenge becomes more complicated due to the limitations of IoT devices, unlike larger computers, IoT devices are limited in compute power and storage size.
Due to poor security planning, many companies addressed this challenge by having a shared secret between the cloud and all their IoT devices. This gave the attackers an easy way in, by cracking one simple password, they could control thousands or millions of IoT devices.
To solve this problem, industry experts have recommended using cryptographic certificates to control authentication between devices and cloud services. If implemented correctly, certificate authentication allows companies to have a secure authority that issues credentials to the devices, allowing for credential rotation, while giving companies the ability to revoke compromised credentials.
To properly authenticate certificates, we fist have to understand how certificates work. A certificate can be either self signed or signed by a trusted authority. By having a trusted authority sign the certificates, it allows you to only keep track of the certificate authorities instead of needing to register each certificate to be trusted by your code.
Now that we have a base understanding on how certificates should be verified let’s jump into the details of how you should validate a certificate to accept it as a valid credential.
CRLs are used to invalidate certificates that have yet to expire but were deemed no longer valid by the CA. It is a very important step that is sometimes overlooked.
Using subject name or subject alternate name to determine the identity of the user allows for seamless certificate rotation.
The biggest challenge with bootstrapping a new IoT device is devices have to have a way to authenticate with the cloud without sharing a common credential between all IoT devices. In the previous section we make it clear that the easiest solution to this problem is using certificates. We even created a code sample to automatically provision IoT devices in Azure IoT with a trusted CA, but what that sample doesn’t cover is how this should look in the factory. Lets break down the steps needed to bootstrap the identity of a new IoT device:
Connecting to Azure does not have to happen in the factory. Once the certificate is loaded, the IoT device can use that certificate to register itself in Azure once the IoT device is going to be used.