Authentication Mechanisms
At a high level, there are a few options:
1. Using Symmetric Keys (not recommended for production)
2. Using X509 Certificates
3. Using Trusted Platform Modules (TPMs)
Symmetric keys are an authentication option that provide a simple on-device symmetric key string that allows the device to authenticate with the IoT platform. However, because they often lead to bad practices like reusing keys across devices or hard-coding keys within software, they are not recommended for production. Also because of this, not all platforms support using symmetric keys and even if they do (like Microsoft Azure) they recommend only using them for prototyping purposes.
X509 certificates, are a much more secure and sophisticated identity and authentication tool. Essentially, you create a certificate chain, starting with either a self-signed root certificate or a certificate purchased from a public CA vendor. This certificate is then used to sign lower-level intermediate certificates or itself configured as trusted within the IoT platform. When this happens, the root certificate (or an intermediate certificate it has signed) can be used to sign unique leaf certificates which live on individual devices. These leaf or device certificates are completely unique and can also be used to authenticate the device’s identity to the IoT Platform.
TPMs or Trusted Platform Modules are dedicated hardware components that perform cryptographic operations to enable authentication. During manufacturing, these TPMs can be registered and configured with the IoT platform in order to provide similar identity and authentication functionality. The main functional difference between a TPM and something like an X509 certificate is that the TPM is a physical component attached to your board that securely stores and manages device identity. The the X509 option on the other hand is a set of files that can be copied on to (or off of) the device and must be stored as securely as possible on the device given that.
Device management platforms will almost always integrate with one or more of these authentication mechanisms tools. Let’s look at how different public clouds support these features:
*Microsoft does not recommend using Symmetric keys in production and suggests only using them when prototyping.
The Authentication Lifecycle
When configuring device certificates, keys, and other possible authentication mechanisms, you’ll also need to have a plan for:
1. How to setup devices with authentication credentials (Provisioning)
2. How to rotate your authentication mechanisms (Rotation)
3. What to do if a device is compromised (Revocation)
How you manage these steps is another important consideration when evaluating identity and authentication options with a platform.
With symmetric keys for example, you might need to simply replace an environment variable or a file containing the symmetric key used to connect. But, you’d have to do this for every device. So, you will need a mechanism to update that value on each device either through a secure connection from the IoT platform or, less efficiently, through a manual connection to the devices.
The same situation comes up with X509 certificates. First, you need to provision a new device certificate from your intermediate or root certificate. Then, you need a way to add the new certificate on the device and shift your device over to using the new certificate.
Different platforms have different ways of allowing you to manage authentication mechanisms. For the most part, these steps are handled through the platform’s APIs and SDKs. When you need to do this at a mass scale, you’ll need to write your own code to automate the process.
Certificate Provisioning, the process of placing a certificate on a device, can happen in many ways depending on the manufacturing process. One possible workflow looks like this:
1. A self-signed root certificate is created OR a CA-signed certificate is purchased from a vendor
2. This top-level certificate is used to create an intermediate certificate
3. The intermediate certificate is registered with the cloud platform
4. The intermediate certificate is used during manufacturing to create unique device certificates
5. The devices use these certificates to connect to the cloud
Rotation occurs when an X509 certificate is close to expiring or needs to be replaced for other reasons such as certificate compromise. To carry out certificate rotation, you’ll need a way to reliably provide a new certificate. Depending on the platform, the process might require the device to reconnect and reprovision. Because failed rotation can make a device inoperable it is a high-risk operation. While required when certificates approach being expired, rotation should be done with upmost caution and be thoroughly tested and rolled out slowly.
1. A new leaf certificate is requested and provisioned for the device
2. The certificate is sent securely to the device
3. The device securely stores and
4. The device tests that new certificate and after confirming
Certificate revocation may be required when a device certificate is known to be compromised. Typically, this might involve patching a device and then providing it with a new certificate that it then uses to connect to the platform. However, if an intermediate certificate is thought to be compromised, perhaps because of a manufacturing process, you might need to do this at a larger scale.
So how do different platforms handle these processes? At a high-level here are some of the options:
*AWS Lambda or provisioning templates
AWS has several options to onboard your devices. The majority of these involve writing some custom code and using the AWS Lambda service to register your devices when they connect with a trusted X509 certificate. This can either rely on a registration template or a more customized process in which Lambda functions with process each registration more individually.Each of these platforms have their own APIs and SDKs that can allow for customizable onboarding processes given some development overhead. But, these options can require developers to write significant amounts of code to make sure that the devices provision properly. However, some also offer other methods for device onboarding and provisioning with different levels of customization and automation.
Microsoft Azure provides its own more managed services for onboarding device by using the Device Provisioning Service, or DPS. This service allows you to configure how you want your devices to be provisioned, on which IoT Hubs and with what sort of device twin properties, based on the enrollment groups they’re associated with in DPS. This can help avoid writing significant amounts of provisioning code. It also has additional benefits when it comes to doing credential rotation down the line as DPS can be reused not just for an initial device registration but also any re-registration when devices need to renew certificates or other credentials.
Azure also offers the Azure Sphere platform, which allows manufacturers to purchase devices with a managed hardware and software platform that streamlines securely connecting to the Azure platform without manually managing identity certificates.