[Webinar Recap] Securing Next Gen PKI

PKI deployments have evolved and expanded to protect more business-critical infrastructure and applications than ever before, emerging as a secure and cost-effective technology to enable new initiatives like cloud, service mesh, and IoT.

Watch the on-demand webinar or read the highlights below to gain practical advice for evaluating in-house PKI vs. PKI as-a-Service from Keyfactor CSO Chris Hickman and Senior Director of IoT Product Management, Ellen Boehm.

How have PKI use cases grown over the years?

Because of its wide use case, PKI has actually become the de facto standard for many different types of security applications, from enterprise to IoT.

While PKI itself is not a new technology, it’s use cases continue to expand, which lends itself to a conversation about what type of PKI you should look for to secure your enterprise or devices.

And that conversation begins by understanding what the PKI today encompasses: certificate authorities, (which are what actually issue the certificates), hardware security modules (used to securely store the key materials), an identity repository and the downstream lifecycle management pieces for automating and managing the replacement of keys, roots of trust and more.

Years ago, when technology was slower and simpler, PKIs were built for specific applications, such as, if someone wanted to add better security to Wi-Fi, or wanted to use certificates to secure websites.

Over time, however, enterprises started using that same PKI for more than one use case, which made things difficult and costly to manage…if not managed correctly, that is.

Despite expanding and evolving to cover a variety of use cases—including things like DevOps— PKI remains a core technology to secure enterprises and the growing world of IoT, so it is critical to understand what type of PKI to implement for your specific use case.

How does PKI deployment for IoT Device Manufacturers differ from typical Enterprise PKI?

Though the volume of certificates and the number of unique PKI use cases has grown in both of the enterprise PKIs and IoT, the world of IoT, in particular, has been beneficial of the evolution. Because of a similar rapid expansion and evolution, the world of secure IoT runs in parallel with the evolution of PKI.

One of the big differences between PKI for IoT and enterprises is lifecycle. While the core tenants of what PKI can provide—methodologies, procedures, end result being a certificate, etc.—to keep devices secure throughout their entire lifecycle, PKI must be thought carefully about during the initial device design, build and provisioning in order to keep the device as secure as possible for as long as possible.

Additionally, PKI for IoT requires proper encryption of keys that are in the devices, established firmware signing and digital signatures to maintain devices over their lifetimes no matter where they are. Data must be encrypted at rest and in transit, and there must be a signature verification based on the PKI to ensure any updates that need to deploy are authentic before installing them.

Which enrollment interfaces does a modern PKI require to support IoT use cases & what authentication and authorization does Keyfactor support for IoT initial enrollment?

While some IoT devices can enroll via SCEP and EST, Keyfactor handles certificate enrollment key generation utilizing an orchestrator framework built into the firmware of your devices. Unique enrollments on IoT are set up depending on the hardware capability and requirements needed.

Keyfactor also uses client-side certificate authentication for initial device authentication. This means there will be a private key in the device that stays in the device with a mathematically generated and related public key that can be used for exchange.

This enables mutual authentication where both the client and the server or two devices can authenticate to each other, following security and IoT best practices.

What does “offline” mean, and what is the reason for an offline root?

Offline means offline—never to have touched a network at any point in time of its existence. There are no varying degrees of offline.

The reason for an offline root is so that root can never be compromised and there are no network path that can access it, completely isolating it from anything that can bring it in harm’s way.

An offline root, however, does create an operational burden, so it’s all about hitting a balance that’s right for your organization when using them.

At the end of the day, a root CA is going to be under any scrutiny through an internal or external audit and needs to be completely offline, not touching a network at any point in time and manually moved over. And while this seems like a daunting process, looking into managed PKI services (think PKI-as-a-Service) is one of the most affordable, secure and efficient paths for both enterprises and IoT manufacturers to take.

What is the impact of a root CA expiration and what does it mean for an enterprise? A manufacturer?

Certs simply need to expire. It is a given in the same way that your driver’s license or passport expires.

The verification expires after some time and must be proven again to showcase continual trust and validity that what you are trying to access is what you should be accessing.

And that that trust is built into the fabric of why PKI works.

When a root CA expires, it essentially forces either reissuance of that root CA or rekeying of that root CA, and either way, you’re going to have to reissue the trust of that new crypto key material to the devices that essentially chain up to it.

In order to do that, you need to be able to distribute those new certificates or rekeyed certificates to those devices that are impacted.

From the enterprise side of the house, there’s a number of different ways that that can be done, depending on what your enterprise looks like. But at the end of the day, if you do not do it efficiently and effectively, you will have some form of an outage or an impact.

Now, when it comes to IoT, pick anything that’s connected, like insulin pumps that are made by a manufacturer and then just go out to people all over the world. Or vehicles, or anything that is intentionally built to be connected to the internet and then goes off and kind of runs and lives its life.

It can be a major warranty cost to your company if you have to go and physically touch each of these things one at a time with a secure way to access that code and update the private key on it. With a strategic approach, you can create identities, and then update them, and keep them fresh over the lifetime of them at scale.