Build a lightweight PKI for IoT using Azure KeyVault

Vitaliy Slepakov
4 min readOct 14, 2020

PKI is a crucial component of many IoT solutions. This blog post will demonstrate how to create a lightweight version for yourself using Azure KeyVault.

In case you didn’t know Azure KeyVault offers customizable certificate management capabilities that help jumpstart one’s IoT certificates experience. It integrates with some well-known CAs and can request certificates from those and you can also integrate with other CAs by writing some code.

In IoT one can think of multiple ways of bringing certificates on to a device. One of the recommended flows can be broken down into following steps:

  1. Device generates a key pair. Ideally the private key is stored in an HSM.
  2. Device generates a certificate signing request (CSR) using its private key.
  3. This CSR is then sent to a public key infrastructure (PKI) endpoint using a protocol like e.g. EST or others.
  4. PKI returns a signed certificate to the device.
  5. Device starts using this certificate.
  6. Before the device certificate expires, device repeats steps 2–5

Setting up a PKI and operating it in a secure way, making sure it is available to meet SLAs is a non-trivial task and most companies either don’t have the expertise or struggle with internal structures and unclear responsibilities. In fact work on a PKI can seriously slow down IoT projects.

Azure KeyVault REST API documentation provides a good overview of the certificate management capabilities. Specifically the sign API can be used for certificate issuance since this is what a CA does: it digitally signs a certificate. The OPC-Vault, one of the microservices of the Azure Industrial IoT Platform already uses this API. It turns out that there are even more products from other companies which leverage this API in their implementation.

I extracted relevant source code from the OPC-Vault repository, removed OPC UA specific parts and put together a sample in my GitHub repo to demo the concept. On a high level the architecture looks like this:

High-Level Architecture

So basically there is an API Façade sitting in front of the KeyVault. It can be used to implement custom authentication/authorization schemes, standard protocols like EST or SCEP, multi-tenancy etc. While it is possible to obtain the issuing CA certificate using the built-in integration with e.g. GlobalSign or DigiCert or you can even just import one, in my example I am using Azure KeyVault built in capability to generate certificates as part of the API Façade. The advantage here is that the private key does not leave Azure KeyVault. Access to the certificate and its private key is protected by RBAC backed by Azure Active Directory. Also I enabled soft-delete and purge protection functionality to make sure that I won’t loose my private key. For simplicity I chose the IPC-style approach (basically just calling an executable) for the API Façade layer.

Considerations

When we think about IoT, we think about millions of connected devices. In such cases PKI becomes a very critical component which needs at least to be:

  • Highly available
  • Highly scalable
  • Highly secure

As with any PKI offering out there, it is incumbent on the IoT solution owner to verify if Azure KeyVault meets their specific solution requirements. In terms of security, Azure KeyVault is a very advanced solution which also offers HSM support:

Also the aforementioned API Façade would need to meet the availability and scalability requirements as well as implement proper security. While this is definitely achievable with all the goodness of Azure PaaS services, one would still need to do some implementation work and also to operate/monitor the solution later on, so there is still an investment to be made.

Conclusion

Certificate management capabilities of Azure KeyVault look interesting and can definitely be used for evaluating your IoT solution experiences. However, we highly urge review by PKI experts for fitness in your particular deployment scenario if rolling out for production use.

Also the API Façade requires some investment to make it highly available, scalable and secure. So this is not a turn-key solution.

Having said that, I would primarily recommend this approach for testing and development purposes only, unless you understand the implications and requisite responsibilities for operating a PKI.

Check out the example on GitHub:

Update (4/23/2021)

Added an EST Façade implementation which works with IoT Edge 1.2

Next Steps

  • Sample for IoT Edge EST integration (in progress)
  • Sample for the device side

--

--