IoT Security Best Practices

Overview

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.

The Challenge

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.

The Solution

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.

Certificate Authentication Best Practices

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.

1. First we have to validate that the certificate is a valid certificate and the public key matches the signature of the authentication challenge.
2. Once we have validated the signature, we must validate that the certificate chains up to one of our trusted authorities.
3. Validate that the certificate is not listed in the CA’s Certificate Revocation List (CRL).

   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.

4. Use the subject name or subject alternate name to determine the identity of the entity authenticating to your API.

   Using subject name or subject alternate name to determine the identity of the user allows for seamless certificate rotation.

5. Grant access.

How to Bootstrap a New Device

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:

Creating the Identity

1. IoT device creates a private key, and uses it to create a certificate signing request (CSR) with its unique device ID.
2. The CSR is transferred to the IoT programming service. Note: Since there is no authentication between the IoT device and the IoT programming service, this has to be done over a secure bus where it would be physically impossible for another device to impersonate an IoT device.
3. The IoT Programing Service sends the request to the CA.
4. The CA returns a signed certificate.
5. The certificate is installed in the IoT device.

Using the Identity

1. The IoT device uses that certificate to authenticate with Azure Provisioning Service.
2. Device Provisioning Service assigns an IoT Hub to this device.
3. The IoT device starts communicating with Azure IoT Hub.