Overview
Not every company is large enough to hire their own PKI expert to make sure their website is secure for customers to visit, but with nearly every business communicating and handling transactions online, all those businesses requires that expertise.
Frequently, the professionals that companies get to handle the keys and certificates necessary for PKI are a little out of their depth. It's like having the electrician show up at a construction project and asking them to do the plumbing.
It’s like having the electrician show up at a construction project and asking them to do the plumbing. That’s not to say they’re not capable or qualified—it’s just difficult to master an entire field of PKI cyber security when it’s not your specialty. They may have some basic understanding, and they may have seen some of it done, but that’s not what they were trained to do.
That doesn’t mean you can ignore PKI management, though. Not knowing PKI best practices doesn’t exclude you from needing to follow them. It’s easier said than done, though, when you don’t know what those best practices are. To help you bridge that knowledge gap, let’s discuss the biggest mistakes that can be made in PKI management, and how to avoid them.
How is trust determined in PKI?
A public key infrastructure is nothing without trust. The chain of trust is a term that refers to the working relationship between different vital components of a PKI, such as the Certificate Authority (CA) and the Registration Authority (RA). Without a trustworthy CA and RA, the PKI is at risk of being compromised.
It begins with the Certificate Authority (CA). The CA signs off on a root digital certificate, which is the foundation for all intermediate and server certificates that follow. In other words, the entire chain of trust depends on the Certificate Authority.
What are the most common PKI mistakes?
1. Using outdated security protocols
Since the creation of HTTPS by Netscape back in 1994, there have been a lot of changes to the cryptography. HTTPS started with the SSL (Secure Sockets Layer) protocol to encrypt communications. Exploits and weaknesses in the protocol mandated something more secure, however, and after widespread adoption of HTTPS, we began migrating from SSL to TLS (Transport Layer Security). Since then, there have been several iterations of TLS protocols, from 1.0 to 1.3 (which is currently a draft).
That’s not the only way the security of HTTPS has changed since its inception. Over the past half a dozen years, nearly every protocol or system used to secure HTTPS transmissions has been compromised or outdated. Here are some best practices regarding these protocols:
- Migrate from SSL to at least TLS 1.1 or better
- Ditch RC4 and use one of the more secure alternatives
- Use SHA-2 or better
2. Using keys that are too short
In PKI, keys are used to encrypt and decrypt information, so that interlopers can’t steal the data passing between two parties. PKI is asymmetric encryption, which means that there’s a public key and a private key, and what’s encrypted by one key must be decrypted by the other. This setup effectively protects information from prying eyes. That is, if malicious users don’t have a way to get the private key.
There are two ways for a hacker to get their hands on a private key: steal it (which we will discuss later) and guess it. Because these keys are just mathematical algorithms, it’s feasible for a hacker with adequate hardware to reverse the algorithm and determine the base values. It’s not easy, but sometimes it’s possible.
The difficulty of guessing (i.e., cracking) a given private key is dependent on how long the key is, and how many bits it takes to store the key. The longer and more complicated the key, the harder it is to crack. The problem is, as technology and methods improve, it becomes easier and easier to guess private keys, necessitating an increase in the size and complexity to maintain key security.
In 2002, 1024 bit keys were the bare minimum for security. Before the decade was over, that minimum already wasn’t enough. 2048 bit keys are now the standard, but will also be defunct by at least 2030. If you’re using 1024-bit encryption keys your PKI is vulnerable, and you need to upgrade quickly.
3. Using self-issued keys and certificates
Normally, keys and certificates (numerical identifiers that prove a website is who they say they are, and not a hacker disguised their system) are obtained from a trusted third party, called a Certificate Authority (or CA). Sometimes, though, an organization might issue its own keys and certificates.
The most common reason for this is for testing purposes. Developers will issue themselves a certificate or use a key to test software, intending to replace it later with a more secure one from a certificate authority. It’s a common practice, and it doesn’t cause any harm by itself. The problem arises when those certificates and keys are used externally, and provided to the end user. Once they go into circulation and regular use, they can prove very dangerous, for several reasons.
First, test certificates aren’t usually as robust as ones issued by a CA (see our previous section on key length), making them easy to crack, and then fake. Second, they aren’t usually stored securely, either (more on this later). Third, because they’re self-issued, they can be difficult to discover after the fact when you want to address PKI security, leaving you vulnerabilities that hide in your blind spot.
4. Not storing keys and certificates securely
Now, about the stealing of keys we mentioned. In many cases, it’s easy to just steal the original keys and certificates directly. This is because not every company stores all of their sensitive PKI data securely. Frequently, they’re kept in a spreadsheet in plaintext and stored on a flash drive, normal hard drive, or another easily accessible storage medium, without so much as a Hardware Security Module (HSM) to protect it.
And, unless you have policies in place determining who can obtain keys and certificates, and who has access to them, they’re easy to copy or otherwise smuggle out. With something as valuable as keys and certificates, you’re facing both internal and external theft, and either threat can do serious damage.
If a malicious user gets their hands on that PKI information, they can easily steal sensitive information from other users when they go to the website, or they can trick people into downloading malware by making their browser think the company made the software. It puts the customers at risk and can severely damage a company’s reputation.
5. Not rotating PKI certificates and keys frequently
If you’re worried someone has stolen your password, it’s a good idea to change it. If you to ensure the security of your login, you’ll change it regularly regardless. The same goes for certificates and keys. Changing them frequently helps to counteract their theft or cracking, meaning that even if a hacker has gotten access to them, what they have will be outdated soon.
It’s a common practice to rotate certificates. CAs often enforce it by setting an expiration date for certificates, so that they have to be renewed every so often. Many companies only renew them when they have to, though, which is not nearly as frequently as they should. To achieve optimal security, certificates should be changed out in intervals less than six months long.
Even if certificates are being switched out, very few will similarly rotate their keys. Keys don’t have expiration dates, like certificates, so their replacing is not enforced. The problem with this is that if a hacker has the key, the certificate is somewhat irrelevant—they can build their own certificate and successfully fool devices into thinking the hacker is the actual website that they stole the key from. Changing keys regularly can prevent this, but it’s a best practice that’s not often followed.
6. Not using an automation tool
Automation, in any application, is intended to improve efficiency and decrease human error. It’s no different in PKI management. Automation can help you renew your certificates and keys. It can also track, and store data related to them, like how many keys and certificates you have, what they are, who requested them and for what purpose, who has access to them and when they use that access, and more.
Best of all, automation limits how many times an actual human must interact with the keys and certificates, cutting down on human error. The problem is that very few organizations use this automation in their PKI management. That may be because they don’t know what it is, or what it can be used for, or because they don’t think it will be necessary. The fallback option is to have a human run the system, and that tends to result in defaulting to unsecured and unreliable practices.
Does Venafi have a PKI Solution?
Designing a public key infrastructure is a little like building a house—if you want it to be structurally sound and dependable, you need to plan it out, and adhere to codes. Like any industry, PKI design has best practices, and to make the infrastructure secure they need to be treated like law. Company policies then need to be set regarding things like who is responsible for PKI management, who is allowed to request keys and certificates, where they are stored, and how frequently to renew them. Then those policies need to be followed and enforced.
Centralizing PKI management this way (especially for larger organizations, who may have thousands of certificates to manage) is the only effective way to ensure the security of a given system. Disorganization and lack of accountability only breed vulnerabilities, and it’s only a matter of time before someone (internally or externally) exploits them.
You don’t have to understand hashing algorithms or elliptic curve cryptography to realize that a mismanaged system is a liability. And, with the average cost of a cybersecurity breach reaching as high as $3.62 million, it’s a liability that few businesses can afford.
Are you ready to get serious about your PKI management? Talk to the pros at Venafi. We can help you identify weaknesses in the system and build an infrastructure that maintains the privacy of your users.