Public Key Infrastructure is the backbone of most organizations’ encryption implementations. A well-constructed PKI can handle a range of responsibilities for your organization, from authentication to encryption to ensuring file and email integrity. Your overall device and network security is related to your PKI design and certificate policy.
Implementing the right security measures in your PKI takes effort, but making the proper preparations will help you mitigate future security risks. Consider this: If a certificate on your network was compromised, what risk would it pose to your security? Could that certificate be used to authenticate into a server? Could it be used in a man-in-the-middle attack against your users?
Securing your organization’s certificates and corresponding private keys should be the cornerstone of your PKI management strategy. There are many good practices to use, which we will cover in a while, but first we need to understand the implications of not storing securely your certificates and keys.
SSL/TLS Certificates and Their Prevalence on the Dark Web
What are the implications of compromised certificates and keys?
Information protected by cryptographic mechanisms is secure only if the algorithms remain strong, and the keys have not been compromised. According to NISP SP 800-57 part1, rev.4 “Key compromise occurs when the protective mechanisms for the key fail, meaning the confidentiality, integrity or association of the key to its owner fail, and the key can no longer be trusted to provide the required security.”
Many organizations are not confident they are able to secure keys and certificates throughout all stages of their lifecycle from generation to revocation. However, it seems that these companies are still aware of the consequences of poor PKI management and certificate compromise. Most are aware that failing to secure keys and certificates undermines the trust their organization relies upon to operate.
In addition, according to NISP SP 800-57 part1, rev.4, “The unauthorized disclosure of a private signature key means that the integrity and non-repudiation qualities of all data signed by that key are suspect. An unauthorized party in possession of the private key could sign false information and make it appear to be valid. If attackers can steal a private key, they can impersonate the device, decrypt and read data, and authenticate to a network.”
In other words, if malicious actors gain access to private keys:
- They can pose as the keys’ legitimate owner and steal sensitive information.
- They may engineer the trust of innocent clients by reaping the benefits of fraudulent phishing attacks.
- They can sign nefarious software so as to overcome browser filters blocking malware. Code signing malware is a very effective attack vector tricking people into downloading malware by making their browser think the software comes from a trusted source.
Best practices for securely storing certificates and keys
Above points have highlighted the importance of securely storing your certificates and associated private keys. NIST SP 800-57 parts 1, 2, 3, and FIPS 140-2 (or FIPS 140-3, effective on 22 September 2019) describe in great detail the procedures to be followed in order to store in a secure manner the certificates and keys.
The first and foremost measure is physical security. Certificates and keys should be housed in a hardened location which includes physical access controls, fire safety, structural integrity to protect from natural disasters, such as flooding or earthquakes, and utilities failure options.
The next domain of protection is the logical segmentation of the different cryptographic components housing the keys from the rest of the larger network. Network segmentation is also a good practice to use for separating development from production networks. In addition, actual development systems should be connected to a separate network with separate credentials from those used for ordinary corporate computing, such as e-mail.
Once you have covered the physical and logical domains, the next level of defense is the human. Develop and enforce roles and privileges. The core concept promulgated by NIST is the concept of least privilege: where you restrict “the access privileges of authorized personnel (e.g., program execution privileges, file modification privileges) to the minimum necessary to perform their jobs.” In addition, NIST provides guidance on the access controls and privileges necessary to properly manage user access to the key management system, how to document and implement which roles within the organization will be authorized and to what level, what functions will the role be able to execute on (i.e. generation, handling, distribution, storage, deletion), and the means of user authentication.
The next issue to consider, is the actual storage of certificates and keys. Keys stored in software on general-purpose computers are susceptible to compromise. It is more secure, and a best practice, to store keys in a secure, tamper-proof, cryptographic hardware device. These devices are less vulnerable to compromise and, in many cases, theft of the key requires theft of the physical device. Three types of such devices are typically used:
- Smart cards and smart card-like devices such as USB tokens. With this type of cryptographic hardware, the key is generated on the hardware itself and is not exportable. This means the private key never leaves the device, making it much more difficult for someone to access and compromise. Another reason to use cryptographic tokens is compliance and they are recommended by CAB Forum. The downside of using tokens is that they do not support automation.
- Hardware security modules (HSMs). A HSM is typically a server with different levels of security protection or “hardening” that prevents tampering or loss. HSMs use APIs and can support automated workflows and builds. They can also help meet FIPS compliance and generally offer a higher rating than tokens. Traditionally, HSMs are physical appliances located on-premises, requiring internal resources to manage and ensure baseline requirements and SLAs are met. This can get costly and resource-intensive, which has hindered adoption in the past. Fortunately, recent years have seen the emergence of cloud-based HSMs, which offer many of the same benefits as on-premises HSMs without requiring internal maintenance. HSMs have several important advantages, such as dedicated cryptographic processors with high performance, automation features, and internal-key destruction.
Last but not least, when all is said and done, you must also consider business continuity, the “capability of the organization to continue delivery of products or services at acceptable” levels after a “disruptive incident.” If an intruder does comprise your data or your production server(s) are taken offline for a variety of reasons, you must be able to bounce back in a relatively short time with pre-prescribed steps.
Conclusion
Managing effectively your certificates and keys is a complicated task which can be very costly. Cost is a factor that prevents organizations from improving their certificate and key management practices. It is true that effective PKI management comes with some hidden costs but your driving factor should be what Bruce Schneier and Carl Ellison wrote in a paper about PKI risks: “One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it?” Cost shouldn’t be the driving factor behind your company’s security and reputation.
If you can’t afford to develop and maintain an effective certificate and keys management program, place your trust (and less) money on companies like Venafi, which have the expertise and the solutions to safeguard your valuable digital assets.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts