The first question we have to answer is: why should you use certificate-based authentication? There are two main reasons: first, password-based authentication has proven to not be secure enough for IoT devices with attacks, such as the Mirai IoT Botnet. Secondly, once you figure out certificate authentication, it is actually easier to manage and rotate certificates vs using passwords.
The next thing we have to do is try to understand how certificate-based authentication works. Certificate authentication works by using cryptographic keys to prove the identity of the certificate holder; if implemented with a Certificate Authority, you can prove the identity of the client by checking the certificate was issued by a trusted certificate authority and usually the subject name of certificate (or the subject alternate name) has the identity of the client (in this case, the device ID of the IoT device). This means that you don’t have to register each certificate in Azure IoT hub; instead, you just have to register your certificate authority in Azure IoT hub and then Azure will know which device is authenticated by checking that the certificate was issued by the trusted CA, and then checking the device ID on the certificate.
The first step (after creating your Certificate Authority for Azure IoT) is to create the certificates inside of the IoT devices. As mentioned in our blog about IoT security best practices, you must have your IoT programming system in the factory register, the device in your CA, and issue the first certificate for the device. After the first certificate, your IoT device can renew its certificate with its existing certificate.
Azure IoT has 3 ways to authenticate devices: Symmetric Keys (passwords), X.509 Self-Signed (manually having to register each certificate), and X.509 CA Signed (the right way). Here are detailed instructions on how to add a device to Azure IoT Hub with Certificate CA Signed authentication in the Azure portal. While it is important to see how it is registered, we recommend using code to automate the IoT Hub device registration. Note, it is important to do it directly in Azure IoT Hub; while the Azure Device Provisioning service sounds like a great option to register devices, it only supports X.509 Self-Signed and cannot do CA signed certificate authentication. This means that each time you rotate the certificate, you must register the new certificate in Azure.
As mentioned in our IoT security best practices blog, the hardest part of this design is adding the first certificate to the IoT device. This is why we have created a code sample and detailed instructions on how to create the first certificate for your IoT device.
If you are using a cloud based Certificate Authority such as EZCA, then you can have your devices talk directly to the certificate authority through modern protocols such as a simple REST call. To make it easier for users, we have created a C# NuGet package that makes certificate renewal one simple line of code. If you are not using C#, you can use the sample code or the swagger page to write your own code to automatically renew your IoT certificates. Remember, since we are using a trusted certificate authority, we don’t need to register the new certificate in Azure, it all happens automagically!
If you read the Azure IoT Documentation you probably came across Microsoft mentioning that they do not follow the RFC 5280 standard for certificate revocation (fun fact, this vulnerability was found and disclosed by a Keytos engineer). This means that if you revoke a certificate in your CA, Azure IoT Hub will not know that the certificate has been revoked and will continue to allow the device to authenticate. Instead of fixing the issue, they recommend that you manually disable the device in Azure IoT Hub. We are happy to announce that EZCA is the only Azure CA that automatically disables the device when the certificate is revoked, meaning that if you are using EZCA as your Azure IoT Certificate Authority, then you do not have to worry about disabling your devices once a certificate is revoked.
