ComputerWeekly.com

https://www.computerweekly.com/news/2240063160/How-to-manage-encryption-keys

How to manage encryption keys

By null

Encryption is pushing its way into more corners of the enterprise. From database fields for customer credit cards or social security numbers, to laptop hard drives with proprietary data, more storage is being encrypted more frequently. Every encrypted item needs a key to unlock the encrypted data, and managing the hundreds or thousands of keys used across an enterprise can be a big headache.

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."

Storing keys
There are a number of issues to consider when storing keys:

• 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?

Some enterprise-oriented backup products, such as Symantec Corp.'s Backup Exec and Veritas NetBackup, or CA Inc.'s BrightStor ARCserv Backup, can address these issues as long as you're not backing up platforms that aren't supported by the software or using different backup apps at other sites. Other specialized products, such as those from WinMagic Inc., provide enterprise-oriented storage of keys for encryption of workstation or server disk storage.

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.

All of these features are required by the FIPS standard. Systems from Decru, nCipher, NeoScale and Vormetric satisfy these requirements if you're using the vendor's product throughout your enterprise. As open APIs and other standards are adopted, the benefits derived from these standards should extend to management of all storage keys throughout the enterprise. For now, however, managing keys from other systems requires API-level support from storage product vendors that produce encryption keys, which could take a while. For example, Decru and Cisco Systems Inc. have announced a development relationship, but it may be years before all Cisco products that use keys can be managed through Decru's Lifetime Key Management (LKM) system.

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.

Click here to continue reading How to manage encryption keys, page 2.