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
In many cases, it’s easy to steal the original keys and certificates directly 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.
What are the Security Limitations of PKI?
With all the strengths of a Public Key Infrastructure, there is room for improvement. As it currently stands, PKIs rely heavily on the integrity of the associated Certificate Authority and Registration Authority, which aren’t always functioning at the ideal level of diligence and scrutiny.
Another current security limitation of Public Key Infrastructures today (or rather, a security risk) is the lack of multi-factor authentication on many of the top frameworks. Regardless of the world’s increasing ability to blow through passwords, PKIs have been slow to combat this threat with various levels of authorization before entry.
Lastly, PKI technology is known for its inability to easily adapt to the ever-changing advancements of the digital world. Users report being unhappy with their current PKI’s lack of ability to support new applications that are geared toward improvements in security, convenience, and scalability.
Learn more about machine identity security, and how it can benefit your organization!
