In my previous post, I suggested that PKI might be the answer to securing the Internet of Things (IoT) - it's an established standard and offers the authentication, encryption, and data integrity needed to secure the connections and communication between devices. While PKI does seem like a great fit, the massive and diverse nature of IoT deployments brings a slew of new considerations to the table regarding how to actually implement PKI. Let's take a look at some of the big ones.
Diversity of Devices
When we look at the IoT on a whole, one of the distinguishing features is the diversity of devices. Just as we’ve seen a huge diversification of mobile devices, we’ll see an even greater trend with IoT devices. Each will be more tailored to specific use cases with different specifications and capabilities. If we compare use cases between traditional PKI and IoT PKI, we’ll see a serious divergence. Traditional PKI implementations tend to have common themes (e.g., issuing certificates to users for portal access, SSL certificates for internal or public-facing servers), but it's likely every use case in the IoT could be a different nut to crack.
Within these scenarios, you’ll need to consider both the device’s connectivity and resources, and how these map to the requirements or features you want from a PKI. Many devices and environments will be constrained. For example, the RAM, storage, or CPU of the devices might be really limited. This can prevent you from leveraging traditional PKI features. Instead you’d be forced to explore a feature subset or alternative to meet your needs.
Trust Models
One of the bigger shifts compared to traditional PKI are the trust models needed to support your ecosystem. For example, between what actors or elements in your environment does trust need to be established? Is this an open ecosystem, where users and devices might be deciding to join on their own, and are not owned or controlled by you? Or is this a closed ecosystem where you control or have authority over all actors in it?
Given those considerations, how will you embed, bootstrap, or build trust between these entities in your system? The answers to these questions may drive you to some unique or not-standard PKI deployment scenarios.
Size, Scale, and Scope of your Ecosystem
Now onto one of the most common themes of any IoT discussion – which is the massive size and scope of potential ecosystems. These are absolutely essential considerations, as traditional PKI has operated on orders of magnitude lower than these new IoT scenarios, and you’re going to need to find a CA infrastructure that can match your needs.
In addition to the raw number of devices you’ll be working with, how do the use case requirements in your ecosystem impact this CA infrastructure? Also, based on the type and constraints of the devices, where and how will you be provisioning them? How does that drive the performance and capacity needs of your security solutions?
Lifecycle Management Across Device and Cloud
Lifecycle management of keys and certificates now requires a combined analysis of device capabilities, the supporting cloud services, and PKI capabilities. This analysis will drive your requirements for how you will manage and track certificates through the lifecycle. Also, what is the lifespan of the devices you’re working with? Can they be updated after manufacturing or initial deployment?
Based on these questions, you’ll need to consider what the technical interface requirements are for your end devices -- Are they going to consume PKI services through an intermediate system or are you looking to have devices obtain certificates directly from CA services?
Additionally, as many IoT deployments are external customer facing, are there drivers motivating an alignment of cost and revenue models? If you’re going with managed services, can your provider support flexible pricing models that match your business case?
It's true that PKI can be a great solution for your IoT deployment, but the key takeaway here is that every deployment is going to have its own needs. I recommend you work with an IoT Certificate Authority (CA) that is flexible and can accommodate your business-driven environments. Try to avoid closed standards, and leverage known PKI best practices and existing technology where possible.
