How to manage encryption keys

The spectre of data loss is the biggest reason why encryption isn't implemented more widely. Most experienced system administrators are conservative when it comes to new technologies that could potentially lock them out of their own data. On the other hand, business requirements, legislation and liability for lost data are driving encryption forward. For the moment, centrally and securely managing encryption of all of the various types of data across the whole enterprise is only a dream -- unless you use the same vendor for all of your encryption tasks.

Many vendors are pushing for a single encryption-key management standard. Decru Inc., nCipher Corp. Ltd., NeoScale Systems Inc. and Vormetric Inc. all have, or will shortly have, open platforms that should be able to manage keys from other vendors. All of these systems control key access, even if the storage systems are compromised and the keys aren't available locally. Keys are associated with specific data repositories, ensuring that the key necessary for a specific directory or file can be readily identified. Once access requirements are fulfilled, keys are provided on demand; management systems also encrypt keys in transit and delete keys when they're no longer needed. Audit logs show who has accessed what data, and when that access occurred. In addition, these systems limit key generation and modification to specific authorized personnel.

Key management standards
The Federal Information Processing Standard (FIPS) 140-2 Level 3 standard requires that the systems used to store encryption keys be physically secure, use two-part authentication, produce audit logs showing all accesses and encrypt all communications between systems. But this may be excessive for many organizations. As with administrators who set a requirement for strong passwords that change every two weeks, you may find that such stringent measures simply encourage everyone to write their passwords on sticky notes so they can remember them.

Requiring two-part authentication, 128-bit key lengths or keys that change every few weeks may be overkill, depending on why you're encrypting data. If you use the same 56-bit key for every encrypted tape, key management will be much easier. But the problem with doing that, or with storing all of your keys in an Excel spreadsheet, is that one security lapse leaves the whole system vulnerable. When many administrators see internal security as a bigger problem than data loss from outside sources, it's probably better to opt for more secure key management.

If you don't think you need the full capability of FIPS 140-2 Level 3, nCipher's keyAuthority provides and manages keys based on other standard encryption standards, such as Microsoft Cryptographic API (MS-CAPI), RSA Laboratories' PKCS #11, Java JCA/JCE CSP and OpenSSL. While these standards aren't specifically designed for high-security storage encryption, they can certainly be used to encrypt hard disk storage, if not at the same level of "uncrackability."

• Will they be stored on each client that needs to access the information, on a central server that requires authentication to release the key, or in a hardware device such as a smart card or USB key?
• How will you ensure that keys will still be available in five, 10 or 50 years when access to archived data is required?
• Will an authorized staffer be able to access keys in a disaster when servers must be rebuilt from encrypted backups without the original backup software or tape drive that did the encryption?
• How do you track what data was encrypted with which key, and where the key is stored?

Most encryption-key management products from established vendors (see "Sampling of encryption-key management products," at right) offer substantial benefits compared to home-grown solutions (such as keeping the keys in an Excel spreadsheet or Access database), including:

• Automatic key management. Users don't create the keys themselves and can't inadvertently leak them because the keys are always encrypted.
• Strings to create keys are randomly generated.
• Keys used to encrypt backup keys are separate and distinct. Keys are never stored or transmitted in the clear.
• Keys are generated automatically and stored securely so they can be changed regularly.
• Provisions for distributed and clustered key management systems provide quick responses at any location when data needs to be accessed; if necessary, keys can be replicated so that the failure of one appliance won't result in data loss.
• Provisions for software-based recovery of encrypted data using keys stored on hardware (smart cards or USB keys).
• Reporting tools make it easy to associate keys automatically with specific backup tapes or encrypted stores.

There have been some attempts to enable interoperability among cryptographic engines. For example, Sun Microsystems Inc. has proposed the Simple Key Management for Internet Protocol (SKIP) to the Internet Engineering Task Force to enable secure distribution of information among devices, which could include encryption keys. Other standards are also under development by the National Institute of Standards and Technology, which created FIPS 140-2. Those standards will define acceptable key establishment, agreement and transport schemes based on ANSI documents, which will allow secure storage systems to exchange data. The ANSI documents are currently in draft form, but are expected to be approved shortly.

The biggest differentiator among the key management vendors profiled here isn't how they manage keys. Because none of the vendors currently has any real compatibility with other products, the primary differentiator is the type of encryption supported. If you require inline, wire-speed Fibre Channel encryption, consider Decru or NeoScale. If you only need to encrypt a few folders on a network share, rather than the whole file system, Vormetric may be your ideal candidate. If you want to implement a key management solution that covers more than just storage encryption keys, nCipher is the strongest candidate.