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.