Encryption key management blunders can render deployments useless


This article can also be found in the Premium Editorial Download "Information Security magazine: How to tell if you need the help of security integrators and consultants."

Download it now to read this article plus other related content.

5 Keys to Picking a Vendor

    Requires Free Membership to View

Develop a checklist of important questions you should ask before choosing an encryption vendor. Here's a good place to start:
  1. How are keys managed? Are the keys managed independently or can they be integrated into an existing database structure or authentication scheme? Ideally, it is better to have key man- agement integrated into the system. Independent solutions allow you more flexibility in implementation, but if it is not done correctly it could be bypassed or compromised by an attacker.

  2. Are multiple keys supported? Can the solution allow multiple keys based on sensitivity and criticality of the information? The more sensitive the data, the more robust the key should be.

  3. Who can change keys? Can the keys be changed and modified by the user or does it require administrative actions? Can a user change a key without an administrator knowing what the key is? If the user thinks a key has potentially been compromised, can the user actually change their key pair at will or would they have to contact an administrator?

  4. Can you create a master key? Can your organization create a built-in master key that is transparently used by all encryption? This prevents a user from encrypting data and holding the organization ransom, and allows it to recover data if a key is lost or corrupted.

  5. Is there PKI integration? Does the encryption solution integrate with an existing PKI solution or does it require proprietary software in order to function? Managing the public keys is a potential problem. Any vendor solution should be able to integrate its public keys with an existing vendor's PKI solution to make it easy to validate.
--Eric Cole

We all know the problem with passwords: If they're too simple, they are easily guessed or cracked; if they're too hard, users either forget them or put them up on a note stuck up on their monitor. One approach is to require users to create a long (say 30 characters) but easy-to-remember pass phrase.

This password needs to be different than their account password and not stored anywhere on the system. All too often, organizations tie private key access to the user log-in password, making it all to easy for an attacker to gain access to it and negate the encryption.

Many organizations make the mistake of archiving private keys so they can decrypt information later. If more than one person knows a private key, its value is decreased, and user accountability is problematic. The proper way to handle this is with a master key that is embedded into all of the encryption. This will prevent a user from holding the company hostage, while allowing you to recover data if a key is lost or corrupted.

Protection. Once the key is unlocked with a password, it should be stored in a protected RAM drive so it is not accessible to any program. The drive should exist only as long as the key is needed to decrypt--no more than a few minutes. The RAM drive should be a function of the encryption software.

Retirement. This is actually one of the biggest key management security problems. When a key is no longer needed or the risk of compromise is too high, it must be retired in a way that assures no one can use it. This sounds self-evident, but it's not always the case. Keys that are no longer valid are put on a certificate revocation list (CRL) by the CA. The problem is that it is the responsibility of a site to pull down the latest CRL and make sure is the key is still valid before trusting it.

Since many sites skip this step, it is possible to have an expired key that sites still trust. This may be a problem with the encryption software, but is much more likely to be the result of poor implementation. Most organizations try to implement encryption by themselves, but don't understand the concept and don't configure it correctly.

This was first published in June 2007

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: