Managing Device Certificates Is Becoming Harder

As the number of devices connected to the Internet balloons, certificate management is becoming more complex, more essential, and significantly harder to keep track of.

There are many different certificates for many different purposes, not to mention certificates that are unique to each device. And the lifetimes of those certificates may vary, making it even tougher to keep operating certificates valid.

“We’re seeing an increasing scale of the number of keys that are being used in organizations,” said Sami van Vliet, principal product manager at Keyfactor, in a recent presentation. Public keys are communicated via certificates, and all of those certificates must be managed.

Makers of Internet-connected devices increasingly must upgrade their certificate-management infrastructure. As it becomes harder to track certificate inventory management manually, automated management systems are growing in popularity. While this is a good practice for any connected device, safety-critical devices must be particularly vigilant in maintaining the authenticity of certificates because security attacks can threaten lives.

The role of certificates
We, and our electronic devices, interact with innumerable faceless entities every day. While we generally trust that our electronics will work well and be safe, we implicitly are placing our trust in devices and people who are involved without our knowing it. So end users need extra assurances that devices and people are who they purport to be. They need someone to vouch for their authenticity, and that’s the role of a certificate.

Most certificates are based on the X.509 standard (which itself is based on the more general ASN.1 syntax standard), although there are other options. Whichever option is chosen, every entity that will examine the certificate will need to recognize the format. That makes X.509 the overwhelming favorite.

A certificate can contain many specific details, but at a high level it’s a document that attests to someone or something truly being who they claim to be. In order to establish independent attestation, it can be issued by a certificate authority (CA) — a company that itself needs to be highly trusted in order for its pronouncements of authenticity to be credible. But it’s reasonable ask, “How does the CA know that the device or person is authentic?”

There are at least three levels of CA certificate, and they involve increasing confidence in the organizations for which they vouch:

• Domain validation (DV) certificates attest that a specific web domain is legitimate. These are low-cost or free certificates, and they can be acquired within a day or so. Their generation can be automated. But they apply only to websites, not devices.
• Organization validation (OV) certificates go further in confirming the validity of an organization, which takes human intervention. Costs here are a little higher, and it might take an extra day or two to obtain.
• Extended validation (EV) certificates are yet more robust, take more human involvement, cost much more, and take more like a week to obtain. Their value lies in providing the highest level of trust.

Certificates are usually structured as a chain that can be traced back to some initial trusted organization. Browser certificates always are rooted in a public certificate authority (CA), but device certificates may not be. High-quality CA certificates can be expensive, so the usual approach is to have the CA attest to the company. The company then creates certificates based on that fundamental certificate. If anyone questions the company-created certificates, they can always point to the CA-generated one and say, effectively, “Yes, we’re vouching for ourselves with all of these certificates. But you can trust us since a CA vouched for us.”

But some device companies simply self-certify. Larger companies have an easier time with that because they have an observable history, as well as accumulated goodwill, that would be irresponsible (although not impossible) to squander. “The person who owns that central root of trust certificate has to promise not to use the private key for any inappropriate purpose, like signing the enemy’s code,” said Mike Borza, security IP architect at Synopsys. How these chains of certificates are built and attested is a design decision.

Among the details that a certificate can contain will be the public key of a public/private key pair for use in the public-key infrastructure (PKI). When authenticating itself to another system, the certificate both acts as bona fides as well as delivering the public key to the other side. But certificate contents can go far beyond that. “There are certain fields that you can have, like the certificate serial number, thumbprints policies, and object identifications,” said Mark Thompson, senior vice president of product management at Keyfactor. “Whether they’re used or not is based on the policy of the issuer, the client of the issuer, and the receiver.”

Certificates are issued with a lifetime. After that lifetime expires, the certificate no longer will be honored. In addition, security breaches might cause an organization to revoke a compromised certificate and issue a new one instead. Any such certificate can be added to a revocation list, and during authentication the certificate may be refused even if it’s still within its lifetime.

Certificates are also specific to a service or other purpose. Not just any old certificate will do. “Just because someone can provide you a certificate doesn’t mean it’s for the right service or process,” said Michael Deckert, supplier management for cybersecurity at Siemens EDA, and Charter of Trust’s advocacy and communications taskforce lead.

In addition, certificates can be dependent upon other certificates. “For any version of IP, you can can say this version is not compatible with another version of IP,” said Simon Rance, head of marketing at ClioSoft. “That can be based on different certificates, whether that’s trust certificates or encryption. We call those policies. You also can set up workflows, where if something gets flagged, then something else gets involved or triggered.”

Web certificates vs. device certificates
Web browsers have built-in certificates that vouch for website visitors. Authentication normally happens in the background with a slight delay — unless something seems amiss. “In a browser world, certificates have to be trusted by third parties. So everyone has to agree on a general paradigm of how things work,” explained Thompson.

When asked about what should go in a device certificate, Keyfactor’s most common response was, “It depends.” Browser certificates may have much more information in them than would fit into a small IoT device. The size of device certificates can vary widely to as large as 4K bytes. The nature of the device functionality and its associated services and threat models will determine critical content. And the ease of updating will influence the lifetime of the certificate.

“Certificates that govern the use and policies around a web server are, in fact, the same certificates that are put onto devices,” Thompson continued. “But you may use different algorithms to construct them. And you may have different policies that include or exclude different fields to make it smaller so that it fits on an embedded device.”

Because device interactions are limited to a few parties — perhaps the device builder, some service providers, and a cloud hosting platform — broader agreement on certificate content isn’t required. “If you’re building a set of devices that communicate to your cloud platform, you can set all the policies for that and how you want those certificates to work,” Thompson added.

Browser and web-service certificate lifetimes are shrinking. While five-year certificates used to be common, now they’re moving down to as little as 30 days. “We see shortening lifetimes also in DevOps environments, when they’re doing micro-service deployments for these modern web architectures,” said Thompson, noting that some of those certificates may last only one day. “It would be harder to do that for embedded devices.”

In addition to the overhead of such frequent updates in a device, there’s also the problem of connectivity. “If the devices are out in the field, they might not have connectivity, or it’s intermittent, or you don’t have a reliable connection or reliable callbacks,” said Ellen Boehm, senior director of IoT product management at Keyfactor. “So that high certificate renewal frequency would be pretty challenging.”

One other important role for a device certificate is for use in a secure-boot operation. “Sometimes we do that in conjunction with validating the signature of the firmware before starting up the device,” added Boehm.

Updating certificates
Over-the-air (OTA) updates may be far easier to implement today than they used to be, but they still represent effort and a disruption to the user, depending on how long an update takes to install. “Some IoT devices can stay around for many, many years,” said Mrugesh Chandarana, senior product manager at HID in a recent presentation. “And you are not in control of it, or it’s hard for you to replace those certs. In those cases, people issue 10-year, 20-year, 25-year certs, [since] it stays within those devices.”

The security parameters specified in the certificates also may change over time. For instance, the cryptographic strength or even key technology may change as attack strategies overcome existing protections. That can require a new certificate that upgrades how security is handled. This can be straightforward in a device where the cryptographic functions are implemented in software.

But if, as is preferable, they’re implemented in hardware, then key strength might be upgradable, but switching algorithms may not be. For instance, hardware-accelerated RSA operations could not be simply switched over to ECC algorithms unless that capability was already built into the hardware. Given that some devices may have lifetimes of a couple of decades, it behooves designers to make their cryptography hardware as future-proof as possible.

All of this means that a given device may undergo multiple certificate replacements throughout its lifetime. The certificate history can be preserved by linking certificates together if future traceability is a concern. “In the commercial realm, there’s good reason to be able to tie development, manufacturing, and operational certificates together,” said Steve Carlson, director, aerospace and defense solutions at Cadence. “Then any feedback that you get from misbehaving devices can be traced back to the manufacturing lot as well as to design issues.”

Certificates vs. keys
While there’s a relationship between certificates and keys, they are by no means the same thing. Private and symmetric keys are never communicated in a certificate. Certificates communicate only the public key of a PKI key pair.

The PKI keys typically are used only for authentication because they don’t work as well as symmetric keys for content encryption. The authentication process usually will include the exchange of symmetric session keys for encrypting content during the life of the session. The key exchange will be encrypted using the PKI keys, but once both sides have the necessary symmetric key, then it can be used for further encryption of the content.

Where possible, private and symmetric keys will be stored in as secure a manner as feasible. Secure elements and other forms of hardware roots of trust store and generate keys internally, but those keys are never available outside the unit. “You store a private symmetric key into a hardware security module so it can’t be gotten,” said Thompson. “And you put systems around it so that the key never leaves the hardware security module, but it can be used securely.”

Proliferating certificates
Device certificates can apply to numerous different aspects of a device. And each device will have its own set of certificates.

“From the hardware root of trust, you’re going to create private/public key pairs for different applications,” said Tom Katsioulas, head of the trustchain business at Siemens EDA. “One can be to protect the memory access. Another one may be to protect the storage. The third one may be to protect JTAG and the actions required for getting into the chip. Those are very distinct profiles for what you want to protect. The root of trust is the thing that is always the same, no matter how many private public key pairs you have.”

Given the number of possible IoT devices in the future, this means an explosion in the number of certificates that need to be managed. And they will vary according to the device’s lifecycle.

During chip development, a carefully managed process would involve each design artifact being signed upon check-in for each modification. “At each stage of the process there’s a certificate attached that says, ‘Okay, here was the input product, here’s the output product, and here are the signatures on each,’” said Synopsys’ Borza. “And, by the way, here are the certificates for the tools, as well.”

Final silicon deliverables, which are electronic files, will be signed, whether RTL or GDS-II. Firmware and software also must be signed. Many of these signatures could be based on a common certificate, but if multiple organizations are involved, then each one may have its own signing certificate.

Manufacturing is where a unit gets its first individual identity, replacing any certificates that might have applied during development. “Developers need separate keys. Those are changed to production keys so that, if a developer key leaks, it can’t be used against a production unit,” said Haydn Povey, general manager, embedded security solutions at IAR Systems. The device gets a fundamental ID certificate as well as any other certificates needed for various services.

That ID certificate may be replaced with a “permanent” ID once the device is on-boarded and commences operation. “Factory provisioning of initial ‘birth’ certificates on devices lets you add additional data to the certificate that identifies the device, a production run, or something like that,” said Boehm. “And then use that information for vetting the device when you’re commissioning it in the field, swapping out that initial certificate — which could be a self-signed certificate – and putting in a certificate fully vetted and validated for that device.”

The certificates at this point are mostly about the software in the device, not the hardware. “When you manufacture something, you will inject credentials,” said Katsioulas. “And those are really associated with the firmware of the chip. It has nothing to do with the physical assets.”

During operation, the keys and certificates must remain constant unless they are explicitly updated. “Depending upon how you do the key chains, you also have the manage them,” said Katsioulas. “So sometimes you’re going to retire a key chain, and you’re going to produce a new key chain for someone else. But on the other hand, if it becomes very costly, you may keep the same certificates throughout the lifecycle.”

Reasons for updating could include a certificate expiring or the revocation of a certificate if, for example, a system is hacked. Each update itself also must be signed. The signing certificate attests to the updating process and is unrelated to the device identity. “You can have one signing certificate for multiple devices, but you should always have unique identity certificates for every device,” noted Thompson.

The device user may add yet more certificates. “The manufacturer of, for example, a medical device, puts a certificate in it so that that device can communicate back to the manufacturer, and it can receive updates and maintenance, tuning, and critical things like that,” explained Thompson. “That device is eventually sold to a hospital. The hospital itself is going to put its own certificate on there so that it can communicate to its electronic health-record system. Two different certificates, two different levels of trust.”

In addition, there will be certificates associated with any Internet services to which the device is connected, including server development and maintenance. “Now we’ve got DevOps situations where people are spinning up servers on an increasingly rapid basis,” said Keyfactor’s van Vliet. “And those servers need certificates.” There may be a certificate for each server in use – and perhaps for each process within a server. And the server-based certificates may be renewed much more frequently than the device-based certificates.

One aspect that does not get a certificate is debug access, which is too often overlooked. “Many people still don’t lock down JTAG,” observed Povey.

Debug access is a very delicate business. “JTAG unlocks are very secure operations that are done only in very secure environments,” noted Thompson.

Fig. 1: A simplistic view of the certificate environment. Different certificates apply at different stages of a device’s lifetime. During development, signing certificates attest to the various inputs. Design tools may have their own certificates. During provisioning, the device gets its initial identity, which may be replaced during on-boarding. It also may receive other certificates for various web services. During operation, certificates may be replaced in an update, which will itself be signed by a certificate. Source: Bryon Moyer/Semiconductor Engineering

Managing all of the certificates
This increasing number of certificates is where the management challenge lies. Historically, certificates have been managed manually – even for websites. With long lifetimes, having to renew certificates was not such a difficult problem. But with the number proliferating, and with lifetimes shortening dramatically for some certificates, many organizations have found that they no longer can reasonably manage them by hand. For short-lifetime certifications, a person responsible for renewal taking even one day off work could result in a service becoming unavailable until the person returns.

Imagine a large company with hundreds of products, each of which has multiple certificates of varying lifetimes, with individual certifications for each unit of each product, and you have a very challenging manual management problem. Some companies may not even have a complete handle on their certificate inventory, where that inventory can be found, or when the various certificates must be renewed.

For this reason, automated certificate management tools are now available to keep track of the entire range of certificates.

“The goal is to put all of this data into context,” said ClioSoft’s Rance. “When you define different IP, you have to layer that into the metadata. For instance, does it require integration with other secure IP to become a secure subsystem? What kind of trust policies are there? In automotive, the management system knows every piece of IP for this year’s model, and there are tools for taking a snapshot of that. But a car built this year will not hit the market for five years. IP needs to be updated with new certificates, and all of that has to be managed.”

This can get very complicated very quickly. Certificate management systems can assist in taking a full certificate inventory when setting things up, and then they can track all of the certificates, renewing as needed (unless there’s a reason not to renew). Complex systems like future automobiles will need automation in order to keep the systems running. “The OEM may take all these authentication mechanisms and put lifecycle management software on top of it to be able to manage those in an aggregated manner, as opposed to individually,” said Katsioulas.

Barring some unforeseen change in how security, trust, and authenticity are handled, makers of connected electronic devices will need to add certificate management to their list of responsibilities. While this appears to be in transition at the moment, it looks to be a basic requirement in future years.

Related
Blockchain Attempts To Secure The Supply Chain
The technology is cumbersome and potentially flawed, but it can provide a chain of custody when necessary.
New And Innovative Supply Chain Threats Emerging
But so are better approaches to deal with thorny counterfeiting issues.
Uniquely Identifying PCBs, Subassemblies, And Packaging
New approaches to preventing counterfeiting across the supply chain.
Who’s Watching The Supply Chain?
The proliferation of advanced packaging and heterogeneous architectures adds some new risks.