Public Key Infrastructure (PKI) is the backbone for enabling robust encryption implementations. A well-established PKI can manage anything from authentication to encryption to ensuring file and email integrity. PKI is facilitated by digital certificates and public/private key pairs. Managing PKI is a complicated task. Hence, many organizations are making certificate management mistakes that jeopardize the efficiency and effectiveness of the PKI structure.
Here’s a breakdown of the most common certificate management mistakes.
PKI must be scalable and viable. These attributes are enforced by selecting the correct and appropriate cryptographic ciphers and protocols. Public Key Cryptography is constantly evolving, algorithms might become outdated and ciphers change because of technological developments.
It is therefore critical to research and choose the correct algorithms and ciphers for the PKI implementation.
Keys are critical in PKI. They are used to encrypt and decrypt data, and they need to be adequately robust so nobody can guess their value, copy them, or decipher the encrypted data. Key length defines an algorithm's security since it is “associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system.”
Encryption systems are often grouped into families. Common families include symmetric systems (such as AES or 3TDEA) and asymmetric systems (such as RSA or Diffie-Hellman). As each of these is of a different level of cryptographic complexity, it is usual to have different key sizes for the same level of security, depending upon the algorithm used.
But as technology evolves, keys need to adapt, otherwise, they could break in just a few seconds. For instance, a standard RSA private key is 2,048 bits long. Back in 2002, 1024-bit keys were sufficient, today they’re not. In another ten years, 2048-bit keys will likely be obsolete, too. This where we need to be careful. As asymmetric keys get larger, the processing power required to use them increases at a much greater rate than the actual key strength does.
Before making the final decision, you will need to consider security needs against the performance costs and also factor in any regulatory or compliance requirements.
Improper storage of keys and certificated can wreak havoc to organizations.
Bruce Schneier wrote about key security and we should pay attention to his words:
“One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it? You almost certainly don’t own a secure computing system with physical access controls, TEMPEST shielding, “air wall” network security, and other protections; you store your private key on a conventional computer. There, it’s subject to attack by viruses and other malicious programs. Even if your private key is safe on your computer, is your computer in a locked room, with video surveillance, so that you know no one but you ever uses it? If it’s protected by a password, how hard is it to guess that password? If your key is stored on a smartcard, how attack-resistant is the card? [Most are very weak.] If it is stored in a truly attack-resistant device, can an infected driving computer get the trustworthy device to sign something you didn’t intend to sign?”
I don’t know if this sounds dystopian, but it is a huge mistake not protecting and securing keys and certificates. The best way to do that is by harnessing the features of HSMs.
Determining the suitable certificate lifecycle is critical for managing these certificates. It is far more than having visibility into the expiration date of each certificate. It is about determining revocations, recovery, archival and other related management activities.
The following factors should be drivers for your decision.
Rotating certificates and keys regularly is good practice. How frequently is related to corporate policies. Either way it is advised to rotate at regular intervals, with GDPR suggesting that every six months or less is considered best practice.
Security researcher Scott Helme suggests, don’t wait until expiry to rotate keys:
“This is bad hygiene and the longer a given cryptographic key is in use the more likely it is to face compromise; I’d much rather see a push towards ephemeral keys than static keys wherever possible.”
The use of ephemeral or “session” keys is also a good practice, minimizing risk. Even if there were some sort of compromise, the certificate and key would be obsolete within a few weeks.
For large enterprises, the use of self-signed certificates might be the best choice. But one of the most common certificate management mistakes is organizations using a self-signed certificate on production systems or a public-facing domain. Anyone outside of your organization that tries to access that domain is going to get a connection error, sending the wrong signals about your organization.
Additionally, improperly secured self-signed certificates can be leveraged by cyber-criminals to conduct man-in-the-middle (MitM) attacks to impersonate banking, e-commerce, and social media websites.
Automation is no longer a nice-to-have option. It is a necessity, a must-have. As with any form of automation, automating certificate management improves efficiency and reduces the potential for human mistakes. Automation helps with the renewal of certificates and keys. It can also identify and store data related to your certificates and keys like:
Without automation, trying to keep information organized across spreadsheets maintained by humans is a source of headaches and nightmares.
Lack of visibility is one of the most serious mistakes. You need to be able to see all the certificates you have issued, who they were issued by when they expire. You need a complete inventory.
This is really the only way you can guard against rogue certificates. Attackers may leverage these compromised certificates to impersonate people and businesses and cause financial and reputational damage. It is only through complete visibility that organizations can minimize the risk of rogue certificates or reduce the outages caused by expired certificates.
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 as law.
Centralizing PKI management this way (especially for larger organizations, which 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.
Learn more about how the Venafi TLS Protect machine identity management solution can help with certificate management, to identify weaknesses in the system and build an infrastructure that maintains the privacy of your users.
Related posts
The rise of IoMT
Read More