Published: 01 Jun 2007
If you plan on implementing PKI, take the following lesson learned the hard way from those who have gone before: Triple your proposed budget and double the implementation schedule.
The heart of the problem is that integrating and implementing key management takes more effort and energy than most organizations realize. These complexities and difficulties are why companies often steer clear of extensive use of data encryption.
Faulty key management renders encryption useless and is a prime reason organizations that say they are encrypting databases still get breached. It can also negate any exception encryption gives you under breach disclosure laws. Even though Califor-nia's SB 1386 requires organizations to report any disclosure of unencrypted data, improperly implemented encryption will put you back on the hook if the data may have been exposed.
The security of any encryption solution is based on the secrecy of the key, not the algorithm or cipher text. If the keys are not properly controlled, an attacker can acquire them.
The private encryption key is equivalent to your credit card, driver's license, Social Security number, and house and car keys all in one. If someone gets it, encryption is useless and they can get to the heart of your enterprise. The perennial problem is balancing functionality and security. An absolutely secure key is an inaccessible key, but if the key is built into database software so it can be used to decrypt database fields automatically on the fly, it's also accessible to an attacker--compare it to leaving your house key under the front door mat. This is the main reason many databases are not encrypted.
The conundrum is managing keys as securely as possible to mitigate risk, while keeping them reasonably accessible so your employees, partners and customers can conduct business.
Let's examine the major elements of key management, the potential pitfalls and what you can do to make it work for your organization.
Keys to the Kingdom
Every step of the key management process has an element of risk. You have to balance security and usability, weighing risk against reward as you plan your implementation.
Generation. Keys must be generated in a secure manner so that an administrator generating them does not actually have access to them. Private keys need to be generated in a similar manner to passwords, where no one but the user knows them.
Assignment. The key must be given to the user in a secure manner, guaranteed not to disclose the key. This can be accomplished through the use of third-party software. Typically, the key pair would be generated by the user clicking a link; only the public key is sent to a central repository, and the private key is kept by the user.
Accountability. Everyone understands the importance of protecting Social Security numbers and signatures, but doesn't realize that a key has the same impact. Users must be held accountable for the key and held liable for any damages if it is taken and used.
Exchange. Public keys must be exchanged so people can send and receive encrypted data. A public key does not need to be secure, but you must guarantee that it really belongs to a particular user. The best practice for distributing keys is through the use of certificates. A corporation should have a single key signed by a global CA (certificate authority). They use that key to self-sign subordinate keys, which, in turn, sign user keys so they can be validated with minimal cost.
Storage and access. Keys must be stored on a drive in some manner that makes it difficult for anyone but the owner of the key to get access to it. Generally, this means the user needs a password or pass phrase to use the key, which is long and complex and never entered directly by the user. Instead, the key is stored in an encrypted virtual safe on the hard drive, and the user only has to remember the combination--the password.
|5 Keys to Picking a Vendor|
Develop a checklist of important questions you should ask before choosing an encryption vendor. Here's a good place to start:
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.
Keys to Good Security
There is no magic bullet when it comes to key management. It is critical that organizations understand the risks, know where their exposures are and implement defense in depth to protect against possible compromise. Key management is a human problem as much as it is a technology problem. Take both into account as you deploy your encryption infrastructure.
Plan it well. Implementing key management is like building a house: If it is done correctly, all major problems should be identified during the design stage. Too many organizations rush their projects and identify problems after deployment or a compromise occurs.
Stress liability. If the keys are not properly protected and someone can gain access to the information, who is going to be liable when an improperly protected key results in identity theft or fraud? Consider having users sign an acceptance form, acknowledging their responsibility and liability.
Train your people. Don't underestimate this. Key management is not as user-transparent as some vendors may claim. In addition to stressing the risks and liabilities, and the need for establishing and protecting strong pass phrases, users often have to deal with technical issues, such as clearing their cache, since the key is unprotected in clear text. If you're thinking there is no way you'll get all your users to do things like this, you're beginning to appreciate some of the human difficulties. Software may do this, but it often has an option that says something like "Run with Optimal Performance," which may disable cache clearing.
Implement sound security policy. All encryption key exposure points need to be stated as policy, such as the level and complexity of pass phrases and prohibiting putting unprotected keys on portable drives.
|Click here for a sample of encryption vendors and their products. (PDF).|
Enforce password complexity. Be both proactive and reactive. Your systems should automatically check new pass phrases the first time they are entered, and force users to replace them if they are weak. You can also test existing passwords, using cracking tools, but this should be a backup, not your primary enforcement.
Use two-factor authentication. Pass phrases aren't enough. Protect your investment in encryption. It's expensive, but so is losing your data.
Defend the host. The keys are as safe as the system they are stored on. Invest in strong endpoint security that includes firewall, host IPS and strong patch management, in addition to antivirus and antispyware.
Look for integrated key management. For database encryption, the most robust key management must be implemented in the database itself, not added on later. Oracle, the leader in this regard, integrates key management into the database when you use their security options.
Validate before you go live. Perform end-to-end penetration testing against the solution to ensure that there are no unaddressed vulnerabilities. Many organizations do a solid job testing functionality but do not test security. Bring in an independent third party to find issues that developers missed. For example, a pen tester would look for alternative ways to access data without the key, such as attempting SQL injection attacks.
The message is don't take encryption lightly--if you cannot properly manage the keys, implementing encryption gains you nothing. Implement controls and secure distribution channels for the keys to reduce risk. Be particularly cautious if you're considering live database encryption. If the database vendor does not provide built-in key management, it might make sense to forego database encryption and use other methods of protection.