Comment: Tips for private key management

In the world of security there are many crimes of omission that companies can commit. They can assume that their suppliers will always embrace best practice with care and diligence. They can assume that their service level agreements will always be honoured, and they can assume, if they are really naïve, that their supplier will not quibble about compensation if the service is below par.

However, last week, I was on a conference call with one of the premier analysts in this industry when the subject of private keys came up. I have always taken for granted that everyone in the industry understood that, as part of certificate management, we also manage the private keys associated with those certificates.

This analyst made it clear to me that we couldn’t make this assumption, for two reasons: 1) very few realize that managing certificates also requires the management of private keys; and 2) not many understand how critical the security of private keys is in protecting sensitive data. It just proves, once again, that assumptions are very fragile things.

If you’ve ever heard me present, you’ve heard me use the phrase, “the key is the data” – which is a concept that comes directly from my friend, Marc Massar, who knows more than a little bit about encryption. The point is that if you protect data by encrypting it with a certificate, the private key becomes the data you have to protect (i.e., that encrypted data is effectively useless without the key, but if the wrong person gets that key, your data is at risk).

At this point, you may be asking yourself: ‘Thanks for sharing, Paul, but why should I care?’ Let’s see if I can relate this to a topic you may have already spent some time thinking about – symmetric keys.

Here’s an example. Based on PCI or some other regulation, you decide to encrypt the columns that contain personally identifiable information (PII) in your database using symmetric keys. That’s great. But what about when you retrieve that data from the database? The database is going to decrypt the data using the symmetric key(s) and pass it across the network.

So, assuming you’re still worried about the security of that data, how do you ensure the data is secured as it travels across the network? You encrypt it using a certificate and private key. So it stands to reason that you want to implement the same security procedures for your private keys as you do for your symmetric keys.

Then you might say, ‘we’re not subject to PCI because we don’t process credit cards’. Well, let’s see what other types of data you’re passing across your network and the internet that you might want to assure are properly protected based on the industry you’re in:

• Bank account information
• Insurance information
• Patient healthcare records
• Employee salary and benefits information
• Corporate financial information
• Stock account information
• Corporate trade secrets

So how are you managing your private keys today? If you’re like most organizations, you’re doing it manually with no dual control. Here are the typical steps an administrator goes through to generate a key pair (which includes a private and public key) and get a certificate:

• Create a keystore, if one doesn’t already exist
• Assign that keystore a password to protect its contents, including the private key(s)
• Generate a key pair (public and private key)
• Generate a certificate signing request (CSR)
• Submit the CSR to the certification authority (CA)
• Retrieve the certificate from the CA
• Install needed CA certificate(s) in the keystore
• Install the certificate in the keystore
• Backup the private key (if deemed necessary)
• Extract the private key and certificate so they can be placed on other systems (e.g., for load-balanced configurations)

The problem with administrators performing these steps manually is that it opens you up to several potential security problems, either because they’re not following best practices or because they’re malicious. Here are some security challenges that present themselves:

1. Administrators normally use the same keystore password on multiple systems (sometimes hundreds) so it is easy to remember them.
2. Administrators usually have to share keystore passwords with other administrators because they’re all sharing in the work managing a group of systems.
3. Administrators rarely comply with corporate password rotation policies (e.g., change every 90 days) for keystore passwords and will often use the same password for years. (One administrator at a very large bank told us they call keystore passwords “passphrases” so that they don’t have to comply with the corporate “password” rotation policy. If you can believe it, this practice actually got them in compliance with their auditors.)
4. Administrators who have direct access to keystores and the passwords that protect them can make copies of private keys that can be used to decrypt the data you’re trying to protect. This is a big problem if those administrators leave the organization.
5. Most organizations don’t make it a practice of replacing private keys when the administrators who have had access to them are reassigned to a different department or leave the organization.

Given the typical re-use of the same password across multiple systems, the fact that passwords aren’t changed for years, and the sharing of passwords amongst multiple administrators, you can imagine the risks organizations are exposing themselves to.

If you have these challenges within your organization or department, here are some best practices I recommend implementing to better protect the private keys that safeguard your most critical data:

• Automate: Use an automated key and certificate management system that removes the need for administrators to access keystores directly and the passwords that protect them
• Rotate Passwords: Change keystore passwords regularly
• Separate Duties and Roles: Have a different set of administrators manage keystore passwords than the administrators who manage the systems where the keystores reside
• Proactively Change Keys: Change private keys (and the corresponding certificates) each time an administrator who has had access is reassigned or leaves the organization

You may be wondering at this point how you are going to accomplish this without clearing your diary for the next six months. The management of private keys and certificates is central to the security of all data. It is only by following best practice, and not making assumptions, that system administrators can be assured that all data is safe.

Without policy-based management capabilities in place, there will continue to be high-profile data breaches and system outages on mission-critical applications with increasing frequency and cost. Never make assumptions.

Paul Turner is the vice president of product and customer solutions for Venafi, where he is responsible for planning and management of the company’s products, solutions and professional services. Prior to joining Venafi, Turner was VP of marketing and product management for resource management at Novell. While at Novell, he also held leadership positions in collaboration, secure identity management, content distribution, and internet products and was responsible for driving market and revenue growth in each of those businesses. During the late nineties, Turner served as VP of product management at CertCo, a spinout from Bankers' Trust delivering PKI and secure electronic commerce solutions to the financial services industry. Turner holds a BS in electrical engineering from the University of South Florida.