Public key infrastructure (PKI) is the foundation of secure authentication and data exchange over large networks, especially large networks of IoT devices. It also underpins web communication between web browsers and websites. However, with perimeter defenses and threat detection improving and heavy-duty encryption (AES-128 or higher) becoming standard, attackers who wish to infiltrate networks or siphon data are increasingly focusing on stealing keys or exploiting PKI certificate weaknesses.
Six ways PKI can go wrong
Whether building in-house or deploying a third-party PKI, organizations need to be wary of the important areas where a PKI can become insecure. Here we’ll look at what they are and how to harden defenses around secure key provisioning and PKI deployment.
1. Weak key storage
In a PKI, private keys perform cryptographic operations, including encryption, decryption, and digital signing. This makes them high-value targets for attackers and is why they should always be stored securely on any device, even during run-time. Hardware security modules (HSM) can achieve the level of security required for at-rest and in-use private keys, but are often too costly or impractical to be deployed across millions of devices (such as IoT sensors and other devices).
Advanced attacks can also harvest keys from the environmental outputs of devices (sounds, heat, time taken to complete a process) through side-channel attacks. Thus, the key provisioning phase should include logical protection for keys while in use.
2. Insecure key provisioning
Key provisioning can occur at the factory-floor level or retroactively after deployment. Unfortunately, keys can often be compromised by failure to adhere to best practices at the key provisioning stage. For example, many devices are often grouped together to use the same key, which is theoretically perfectly viable. But, in the case of supply chain attacks, a compromised component sourced from elsewhere can introduce a backdoor into an entire chain of trust system without the manufacturer knowing.
Considering the resource constraints of IoT devices, such as not having the space for HSMs, key provisioning can become a critical vector for hackers seeking to escalate attacks along a hardware chain.
3. Not planning for scaling or extra PKI traffic
An in-house PKI can take considerable resources to build, deploy, and maintain. The work doesn’t stop at key provisioning, either, as security must be constantly monitored through certificate lifecycle management. Any PKI must also be built with the ability to easily scale with your business needs.
Beyond the resource usage of building and maintaining it, what’s also not often considered is how much bandwidth PKI traffic takes up. This includes directory requests, certificate issuing, and maintaining a certificate revocation list. This can lead to small but noticeable slowdowns across the rest of your functions, costing your organization time and money.
4. Outdated algorithms or protocols
PKI needs to be built as a secure system with the future in mind, not just in terms of scaling for size but also for staying at the cutting edge of security. Certain algorithms and protocols become outdated and deprecated by their standards body (such as SHA-1 or TLS 1.1)l, which can cause your entire network to be running on insecure standards. Before deployment and initial key provisioning, it’s essential to fully ascertain what the most appropriate standards are and which direction they’re likely to be heading in the future.
5. Poor certificate and key lifecycle management
What happens to your certificates and keys when they’re no longer needed? Decisions need to be made at a PKI’s deployment and key provisioning phase around how long certificates, such as x.509 certificates, will last and how they will be destroyed after use. Short-term certificates and keys generated may only be valid for a couple of months, or they will have even shorter lifecycles, but will require more work to be regularly decommissioned and replaced. Long-term certificates can last indefinitely but pose a greater security risk if they’re compromised or become outdated. Certificate lifecycle management is a critical part of a healthy PKI.
6. Inappropriate use of self-signed certificates
Self-signed certificates can work fine for internal PKI deployments with a proper certificate authority (CA) hierarchy. In these cases, the root CA and subordinate CA’s can all recognize the validity of each other when it comes to authentication. However, for public-facing web domains, any browser or user attempting to communicate will recognize it as a self-signed certificate and flag up the potential security risk. Even though that risk may not be real, the other party won’t know. In addition to shutting down communications, this can portray a bad image of your organization being insecure.
Conclusion
PKI deployments are an effective system for securing communications and authenticating IoT devices. Unfortunately, attackers seek to circumvent these measures by stealing private keys and compromising certificates. To avoid an insecure PKI deployment, an organization can take several steps. Among these is deploying a tried and tested third-party PKI that can easily scale to meet your business needs and has clear key and certificate lifecycle management policies.
Intertrust’s iPKI has already provisioned secure identities to billions of devices worldwide. Furthermore, as a trusted certificate authority (CA), Intertrust is completely in control of both the deployment and secure maintenance of our PKI. This improves time-to-market for our customers’ devices, but it also significantly reduces costs associated with PKI deployment and key provisioning.
To find out more about how Intertrust its secure provisioning service can keep your networks secure and improve your ROI through our iPKI, you can read more here or connect with our team.