Identifying and Mitigating PKI Assessment Risks

Your PKI design and certificate policy have an impact on the security of your network and devices as a whole. You should design and implement your PKI to fend off typical dangers, much as you would guarantee your home has an earthquake-resistant foundation or a hurricane-resistant roof.

Many of these choices must be made in advance, during the design and development of your software or product. Although it takes work to implement the required security measures in your PKI, taking the necessary precautions will help you reduce security concerns in the future.

Think about this, What risk to your security would a compromised certificate on your network? Could a server be accessed using the certificate’s authentication? Could it be used against your users in a man-in-the-middle attack?

When creating a programme or device that makes use of certificates for authentication or secure communications, these queries should be carefully considered. Technical choices must be made regarding how your product will handle certificates and how your PKI will be designed and managed.

This article is intended for designers and producers who work with private-trust client or device certificates, such as those found in software or Internet of Things (IoT) devices.

Creating a PKI with Long-Lasting Security

We frequently converse with developers who are unaware of their alternatives for creating PKI and certificate policies. You have a lot of flexibility with private-trust PKI when it comes to your client and device certificates, enabling you to increase the security of your program or device.

We’ll go into detail about three crucial factors you should take into account to improve your PKI. Choosing certificate validity periods and replacement, safeguarding private keys, and utilizing certificate revocation—as well as how to use these controls effectively to reduce risk—are the first three topics.

Although certificates offer authentication and encryption, using them is not as straightforward as just installing them and calling it a day. Both of these qualities can be jeopardized, but with right mitigations they can also be strengthened.

The simplest solution could be to set up a shoddy PKI and never worry about managing your certificates, but this comes with security risks you might not have thought about.

Let’s use the recent deprecation of SHA-1 as an illustration. Researchers were aware of the weakness of the SHA-1 hashing method, which was designed to give cryptographic signatures to uniquely identify certificates. Last year, Google showed two distinct files with the same hash in a real-world collision.

The SHA-1 algorithm was effectively killed out by this collision, and many certificates were changed with the more secure SHA-2 algorithm to maintain security. Long-lived certificates were also included, which would become more exposed as time went on (computing power increases make it easier to exploit). Even if a SHA-1 collision would seem impossible right now, what about in 5 years? 20 years? These are crucial factors to take into account if your products will be used over an extended period of time.

The complexity of PKI security is quickly demonstrated by this straightforward example. You would need a technique to reissue and replace certificates on your devices, a revocation mechanism to deal with certificates you know were compromised, and the assurance that your network and users are no longer exposed to reduce the security hazards of a flawed hashing algorithm.

Validity of a Certificate

In the SSL/TLS realm, compromised technologies are an unavoidable issue. The protocol’s fundamental cryptographic technologies are built with a deprecation date in mind since we anticipate that stronger computers in the future may eventually compromise their security.

Major changes have occurred over the past ten years, such as the abandonment of the MD5 and SHA-1 hashing algorithms and the switch to 2048 bit. We’ll eventually run out of 2048-bit keys and have to replace them. It will be much easier to deal with these changes if you have a plan in place.

You must weigh the benefits of a long-lasting certificate against the difficulty of safeguarding long-lasting keys when determining the validity time for your certifications. Protecting these keys becomes more difficult over time as encryption standards deteriorate, are replaced, and as your collection of certificates expands. A flawed algorithm may eventually necessitate the urgent replacement of certificates for sustained security, as in the case of our SHA-1 example.

It’s important to think about both the expiration date and the process for replacing your certifications. Most of the time, we’ve discovered that trying to use a single certificate throughout the device’s lifetime involves too many security trade-offs.

You establish a wider variety of certificates (and accompanying private keys) that need to be kept secure by selecting longer validity periods. Because it grants them access for extended periods of time, this expands the number of targets for attackers and motivates them to compromise a certificate. This in turn makes having a revocation system more crucial and necessitates keeping revocation data on hand for longer periods of time, resulting in bigger revocation files and greater network activity.

However, creating a secure PKI does not require that certificates be changed every year. Long-lived certs can still be used while making effective plans for these changes. When you replace and renew device certificates, you can select the validity term that works best for you without being concerned that you’ll need to replace them in the future.

Keeping Private Keys Safe

Key compromise shares many of the same security factors as certificate validity. Attackers can mimic a device, decrypt and read data, and authenticate to a network if they can obtain a private key.

Keys must be safeguarded against compromise, revoked, and replaced if they are ever compromised if you wish to offer real authentication and encryption. This means that putting keys on a device in plain text, where they could be easily extracted, is not a good idea. Instead, think about a hardware defense like a secure chip (TPM) or a software solution like an encrypted key store, which offers real defense against attackers.

Even if you think your keys are suitably safeguarded, it’s crucial to have a functional revocation scheme. Attackers may become interested in finding a means to circumvent your security measures if they discover there is no practical way to stop them when they steal a key. An additional line of defence called revocation serves to neutralise and dissuade intruders.

These barriers have a lot in common. A dependable revocation system—one that can handle a high rate of revocations—becomes more crucial and expensive if your keys are simple to compromise.

Revocation

Because certificate revocation is a “high-cost” service that necessitates an active internet connection and high availability, several manufacturers and developers think they can’t support it. That is not the situation. You can check revocation information using industry-standard technology without connecting to a server or using the internet at all.

CRL (Certificate Revocation Lists) and OCSP are two technologies that are widely used in the business for verifying revocation information (Online Certificate Status Protocol). A CRL is comparable to a blacklist of serial numbers for certificates for individuals who are unfamiliar with these systems. With OCSP, the client sends a request across the internet to a central service to learn the status of a certain certificate’s revocation—much like calling an API. The X.509 certificate protocol includes both the CRL and OCSP protocols.

The more straightforward option, CRL, gives you flexibility in situations where your device might not have a dependable or quick internet connection. Traditionally, the issuing CA signs a CRL file every day, which the client can access online. However, the CRL can be cached and stored in circumstances where the device cannot quickly or routinely connect to the internet.

CRLs are signed and have a validity period, just like certificates. CRLs are reliable because they are signed by the CA. A CRL does not have to be sent from the CA directly to the device. Instead, they can be dispersed via a network, such as an internal network or a centralised cloud server. This has a benefit over a straightforward blacklist or whitelist. If a CRL file has a valid signature, you can download it from any location without worrying about manipulation.

When a CRL expires, which can be set for weeks or more, it can be cached on a device and used until then. Because of this, it’s a suitable choice for devices with spotty or erratic internet connections. This enables you to keep the advantages of revocation checking in many situations without incurring the technical expenses of repeatedly getting new data.

As long as the devices have access to a gateway or server that does, OCSP can also be used when the devices themselves do not have internet connectivity. The revocation information can be transmitted during the TLS handshake thanks to an optional OCSP feature called “stapling,” which enhances network performance. Both OCSP and CRLs can be implemented, with the most current CRL serving as a backup.

The fact that a commercial CA will already support one of these standard approaches is a benefit of employing it. They are flexible standards that may be customised to meet your unique needs because they support a wide range of possibilities.

Conclusion