Best Practices for Securing Private Keys
When you leave home do you lock the front door but leave the key in the lock? That’s the same thing as creating a private key but not protecting it. Access to a private key can let an attacker fraudulently sign application content or impersonate a site’s identity. Common sense would indicate that locking your front door and taking the key with you is a good thing so have you asked yourself if your private keys are secure?
Protecting private keys is vital if you run Linux (Red Hat Enterprise Linux, Ubuntu Linux), Apple MacOS, UNIX (Solaris, AIX, HP-UX), Microsoft Windows, or any other platform.
Introduction
Creating Code Signing Certificates, Server Authentication (Web Server) Certificates, or any other X.509 certificate requires a private key. The private key is used to sign a Certificate Signing Request (CSR) which is sent to a Certificate Authority which creates the certificate.
The application which uses the certificate requires access to the private key used for the CSR. Without the private key the application is unable to use the certificate for Code Signing or SSL/TLS (Web Server).
Best Practices for Securing Private Keys
Securing your private keys is not rocket science, but it does take an understanding of best practices and the discipline to build and operate the right processes.
Let’s examine best practices for protecting private keys.
#1 – Hardware Storage
The best way of securely storing private keys is to use a cryptographic hardware storage device such as:
- USB Token
- Smart Card
- Hardware Storage Module (HSM)
Using such a physical device means that attackers most first gain access to the physical device which can be difficult if the device has restricted access.
If the storage device is portable, such as with USB Token and Smart Cards, then don’t leave the device connected.
HSMs are intended to have a very narrow and protected connection intended for persistent access. They usually offer the best protection but are often cost prohibitive or impractical.
#2 – Local Filesystem
In some applications it’s impractical to use a Hardware Storage. One example would be for web servers which are numerous and physical or virtually distributed where the cost of Hardware Storage is prohibitive. In such a situation the best solution is to generate and store the private key on a local filesystem.
It’s crucial that the generation of the key be done on the same system and the same local filesystem as the storage location. Generating the key on a server and then transferring the key back to the local system and storing it just adds multiple points of vulnerability. Why would you want to increase the chance of your private key being compromised?
Well, many products on the market today are based on private keys being generated AND stored on a server. This means that the keys are vulnerable to snooping when the are transmitted to the client. The server also becomes a single point of compromise because all the private keys are stored in one place.
Why do these products take this approach? They do this because it’s easier, not because it’s more secure.
CertAccord Enterprise is designed to follow this best practice. It generates and stores private keys on the local filesystem. They are never sent over the wire and never stored on another system.
#3 – Limit User Access
Whether you are using hardware or local filesystem to store your private keys, you should restrict access only to the minimal number of users who require access.
For Hardware solutions this typically is controlled by who is issued Hardware devices (USB Token, Smart Card). Make sure there is a clear and consistent process for issuing, verifying, and collection the devices.
For Local Filesystem storage use filesystem protections such as Access Control Lists (ACLs). Make sure there is a clear and consistent process for who is granted access and how/when access is removed when a user leaves the project or company.
#4 – Verification Monitoring
Having a process is not always enough protection. You need to monitor and verify that the process is working. It’s important that you periodically verify who has access to private keys. Sometimes people leave projects or the company but their user accounts still have access to private keys. It’s also possible for an attacker to compromise your process for granting access. If you have verification monitoring in place, you can catch these types of unexpected events.
Use software to automate the verification monitoring whenever possible. When that’s not possible, use an independent party to verify or audit current private key access. This can be done through existing SOX Compliance testing or a new dedicated process.
Summary
The best thing you can do to protect private keys is to use a Hardware Storage solution in combination with the right control processes. When that is not practical, use Local Filesystem with local key generation in conjunction with the right control processes.
Keys are a vital component of X.509 certificates. You can follow best practices for managing certificates and keys by using CertAccord Enterprise to automate and extend your existing Microsoft PKI certificate authorities to Linux and Mac. To learn more: