Analysis: Enterprise Key Management

Posted by Jordan Wiens on April 27, 2007

CIOS don't roll out of their beds and think, "Hey, let's sink a few hundred grand into a cohesive enterprisewide encryption infrastructure." Instead, the process is a slow creep, starting with backup tapes and spreading as compliance issues bubble up or we realize that specific applications represent financial liabilities. The result? Layer upon layer of encryption management, replete with multiple key-management challenges.

It's time to stop and think: Will a piecemeal approach to encryption and key management cost us big? Maybe, but you have little choice.

"The bad news is that regulatory pressure is causing us to turn on security from the bottom up," says Benjamin Jun, VP of technology at Cryptography Research. Jun adds that key management is where identity management was five years ago--waiting for the industry to decide on common standards.

Don't hold your breath. Even though large enterprises have been fighting this problem for years, the hard truth is, there are no standards to enable unified management of keys from disparate systems.

RSA's Public-Key Cryptography Standard 11 and Microsoft's CryptoAPI are helpful, but they're not standards. The OpenSSL project is a standards-based toolkit for crypto implementation, but it doesn't address key management. Java JCA/JCE (Java Cryptography Architecture/Java Cryptography Extensions) is akin to Microsoft's CryptoAPI: If you're using Java and JCE, it might meet EKM (enterprise key management) requirements for those apps only. Sun's SKIP (Simple Key Management for Internet Protocols) provides key sharing only, no management.

Our analysis of available key-management offerings, at nwc.com/go/0430review, revealed that even without settled standards, a few vendors are taking baby steps in the right direction. For the most part, though, vendors using encryption are keeping the R&D close to home, focused on improving key management for their own offerings.

And, of course, we should be careful what we wish for. Convenience rarely comes without risk, and putting all your eggs in one basket demands hardware redundancy, secure backup and recovery capabilities, and strong authentication policies for system access.

Companies just starting on the road to ubiquitous encryption should launch an EKM project before the number of disparate systems is overwhelming, and ensure new products are compatible with their strategies instead of trying to bolt on support later. Those who've adopted encryption on an ad hoc basis must realize that security is only as strong as its weakest link: If we can't handle our keys, eventually we will lose access to sensitive data, or worse, turn it loose and suffer the consequences.

Continue Reading This Story...

RELATED LINKS Review: Enterprise Key Management Software Architecting for Data Security Data Breach Notification Laws: A State-by-State Perspective Full-Disk Encryption Suites Study: Encryption Is Needed But Few Are Doing It	IMAGES Click image to view image
NWC REPORTS Download a PDF of this article at NWC Reports. Encryption's buzzword status only grows with each revelation of sensitive corporate information gone missing. Are vendor's products keeping pace with their products? We analyze several key management offerings	AROUND THE WEB Host Intrusion Prevention How does host IPS compare with conventional antivirus solutions? What's the difference between network IPS and host IPS? Examine host IPS in this report based on an exclusive survey of enterprise users and in-depth lab analysis.

The State We're In

Given recent harrowing data breaches, we expected most enterprises would be working hard to build cohesive encryption plans. Not so, according to a recent Ponemon Institute study, which found that though 66 percent of 768 U.S. IT pros surveyed have some encryption strategy, only 16 percent are taking an enterprisewide approach.

That's partly because encryption drivers are diverse, from government and industry regulations, to contractual obligations, to auditor demands, to internal policies that too often cast a cynical eye toward the safe-harbor provisions written into mandatory disclosure laws. What should not be diverse, however, is your strategy for managing encryption keys. Key management is important not just because compliance officers want to know how keys are generated, stored and destroyed, but because data may be irretrievably lost if keys are mishandled. The need for a centralized key-management strategy will grow in importance as a company's encryption needs increase.

Let's examine the problem from the bottom up.

Drivers for encryption fall into three general buckets: intangibles, laws and standards. Intangibles include maintaining a good brand reputation and honoring privacy policies and customer trust. Just 7 percent of respondents to the Ponemon study cited ensuring that privacy commitments are honored as a top reason to encrypt sensitive or confidential data. Self-preservation in the form of protecting brand or reputation fared better, at 40 percent.

Laws--especially mandated disclosure laws--intersect with intangibles. In the almost four years since California enacted Senate Bill No. 1386, 30 additional states have pushed through similar legislation stating that organizations must notify residents whose unencrypted personal information may have been disclosed as a result of a security breach ... emphasis on the loophole. Federal regulations like Gramm-Leach-Bliley, HIPAA and Sarbanes-Oxley are perceived as recommending or requiring encryption.

Security vendors don't hesitate to use these regs, along with e-discovery scare tactics, to sell product; we discuss these drivers further in "Prescription for Encryption," below. But one mandate that few can afford to be noncompliant with is the Payment Card Industry Data Security Standard. PCI DSS is set by the PCI Security Standards Council, which represents American Express, Discover, MasterCard, Visa and international credit issuer JCB.

PCI DSS 1.1, which became the standard for all credit-card processors on Jan. 1, mandates encryption before cardholder data is transmitted across public networks. Details go beyond that one broad imperative--the standard is explicit and covers many other situations where encryption may be required to limit data access.

Key-handling requirements in PCI DSS are extensive as well: Key custodians and locations must be limited. All key-management processes must be documented and include generating strong keys as well as securely storing, transmitting, destroying, aging and revoking keys.

Why is it, then, that most stats we've seen on encryption don't seem to mesh with the number of organizations that handle credit-card transactions? Is the amount of encryption being under-reported? Our guess: Security pros are running into the biggest problem with the encryption market: too many solutions, too few standards.

Showstoppers

At this year's RSA conference, it was obvious that encryption is a growth industry. Of the 381 vendors exhibiting, one in five focused on data encryption or key management. That's a high percentage given the sheer number of categories represented. We saw companies exhibiting encryption for data at rest on tapes and hard drives, for data in motion with all flavors of VPNs, and for automatic transparent encryption as data travels through the network. Even the keynote from Microsoft's Bill Gates and Craig Mundie highlighted how IPsec can encrypt data automatically as it travels among network devices.

Let's look for a moment at how all these solutions work together--or don't, as the case may be.

As we increase the amount of encryption occurring on our infrastructures and have keys deployed pervasively on multiple applications, the current model of letting each app manage its own keys becomes untenable. Sure, smaller organizations with relatively modest encryption needs will be able to juggle a few independent encryption silos, but for how long? Encryption requirements certainly aren't going away.

As far as cross-platform capabilities go, in the absence of an open key-management interface, switches, storage systems and tape drives that use encryption keys can cooperate only by publishing their key-management APIs for third-party use. No vendor presently provides a purpose-built key manager that can support the wide range of systems used for encrypting data in flight for network, disk and database applications, as well as data at rest on tape or disk.

Currently, most key-management vendors are emphasizing data at rest, because this represents one of IT's greatest challenges. Tape and backup applications require that a huge number of keys be generated, then securely maintained for decades. Keys may also be needed at remote locations to make data accessible for disaster recovery or e-discovery.

It's All About The Policies

Besides consolidating management overhead of multiple independent systems, the biggest indicator for EKM success is consistent policy application. Microsoft demonstrates a potential solution for this problem in its Windows Rights Management Services for Windows Server 2003. Of course, Windows RMS works only in homogeneous Microsoft environments; see "Going the All Microsoft Route" page 45. But for our purposes, it's the principle behind RMS that's important: Microsoft says RMS "augments an organization's security strategy by protecting information through persistent usage policies that remain with the information, no matter where the information goes."

The magic word there? Policies.

The key to encryption (pun intended) is to protect access to data. It doesn't make sense to allow different people access to the same data based on its location. Why should network engineers have access to keys when data is traversing the VPN, the mail-server administrators have access while data is encrypted in the mail server, and the user have access when it's encrypted on his laptop?

The security industry is pushing policy compliance and policy-driven security hard--NAC demonstrates this trend--and products that follow directly from corporate policies are needed for data encryption too. Data security standards must be written first, and then we need security mechanisms to implement consistent protection measures based on those standards, no matter where the data resides.

Unfortunately, that's impossible with a silo approach, where every product or piece of the network has its own encryption mechanisms.

So What's The Solution?

We want EKM products that can speak to encryption devices and software from different vendors and manage all our keys. Key management would be a tough enough nut to crack with one über suite, never mind integrating dozens of products of different types.

To be effective, an EKM suite must at a minimum address this wish list:

» SECURE KEY CREATION. This is actually harder than it sounds and should be accomplished using purpose-built, FIPS 140-2 Level 3 encryption hardware to defend against so-called side-channel attacks against cryptographic implementations (see more on FIPS 140-2);

» KEY REVOCATION, including re-encrypting old data as necessary, and key aging;

» AUTOMATIC INTEGRATION with identity management systems, where new account equals new key, deleted account equals revoked key;

» KEY ESCROW, where the system stores keys on behalf of a third party--for example, so that an employee who abruptly quits or is terminated can't leave the employer high and dry; and

» SPLIT KEYS, often used to divvy up a master recovery key among executives of an organization, such that a certain majority of individuals must be present to recover the master key. Decru's Lifetime Key Management product uses split keys for emergency key access, though the product was developed for key management with the company's own DataFort systems.

And those are the easy problems. Once they're solved, there are still tough issues to address, like how to turn human-language data-security standards into technical policies for each encryption mechanism. A product must be aware of not just where each device is and how to manage its keys, but how to configure a device with an appropriate policy for the data it will handle.

One big impediment to this ideal EKM reality is a lack of interface standards. Sure, there are many standards for proper implementation of encryption, for example, FIPS 140-2, and even for how keys can be encapsulated for transmission, like RFC3852. But there are no standards for how such a proposed EKM device could speak to multiple encryption products without learning APIs for each vendor's platform.

Public-Key Cryptography Standards 11 (PKCS#11) seems like a near-solution; it specifies an API called "Cryptoki," pronounced "Crypto-key" and meant for doing key management on devices that hold keys or perform cryptographic operations. PKCS#11 was built specifically to allow for enterprise management of cryptographic tokens, but it doesn't solve the whole problem. First, it's not a network API, and it requires higher-level wrappers to be made available over the network. Yes, there are ways of doing that, but none is based on a standard that ensures interoperability among different implementations.

Additionally, PKCS#11 may not address the entire range of mechanisms and keys needed for complete EKM. Key management interoperability on an enterprise scale is not a problem PKCS#11 was meant to solve.

Microsoft's CAPI (CryptoAPI) is another potential piece of the puzzle in that it lets Windows apps be developed for a standard cryptographic interface and have their underlying mechanisms modified by modules. These modules let Windows apps integrate their key management into an EKM platform, but using CAPI solves the problem for Windows-based applications only, and it requires that a piece of the management application be installed on each end point that will use cryptographic features, making for a potentially onerous deployment scenario.

PKI (Public Key Infrastructure) initiatives deal with many issues core to EKM. Indeed, PKI seeks to solve key handling for many current forms of encryption that are identity-based, including secure e-mail and instant messaging, user authentication, and some forms of document rights management. However, PKI technologies aren't built to handle encryption keys not tied to a particular user, as in the case of tape backups, for example.

Almost, But Not Quite

Despite a lack of standards to unite different approaches to key management, several vendors provide tantalizing glimpses of what EKM needs to look like. NeoScale's CryptoStor KeyVault, nCipher's keyAuthority Solution Suite and RSA's Key Manager are all good starts, but they suffer from a lack of a unified industry-standard key-management interface, and none can be dropped into an existing enterprise environment and easily begin managing all the different applications currently doing encryption.

And without an industry-accepted standard--or considerable customer pressure--point-solution encryption vendors have little motivation to change this reality. Key-management products will remain limited to one vendor's products or will demand major institutional efforts to integrate into existing encryption products.

For now, an enterprise could purchase one of the products we discuss in nwc.com/go/0430review and put pressure on its encryption vendors to integrate. Alternately, there are APIs for use with nCipher's and RSA's products for companies that want to develop their own encryption managers. The one universal truth is that, even without a complete solution, enterprises cannot wait until they have too many secrets and too many keys to keep track of. Start planning now so you'll be ready when standards finally arrive. n

Good Crypto, Bad Crypto

One of the great scenes from the movie "Sneakers" unfolds as the security consultants are split into two groups, one playing Scrabble and the other hacking on a faux answering machine they'd been coerced into "recovering." The only thing known about the black box is the code name, "Setec Astronomy." As the Scrabble players realize the code name is an anagram and not an acronym, the hackers begin to probe the special chip hidden in the device, eventually discovering an algorithm able to crack any encryption scheme. Suddenly, the true code name is spelled out on the Scrabble table: "too many secrets."

Quantum computers have a long way to go before they can process enough bits to divine modern cryptography keys, so the likelihood of our encryption suddenly unraveling remains comfortingly small. But the number of secrets we're encrypting is indeed growing at a tremendous rate, and choosing a crypto scheme can be tricky. "Good Crypto" and "Bad Crypto" sometimes look the same, but don't be fooled ... you definitely don't want Bad Crypto guarding your secrets. Here are some tips to help you tell the good from the bad.

Good Crypto: Has a long history of being vetted by the cryptography community.

Bad Crypto: Says, "I'm secure because nobody understands how I work!"

Good Crypto: Is validated by well-respected standards like FIPS 140-2

Bad Crypto: Says "I use FIPS cryptography too!" ... without mentioning that there's a difference between FIPS 140-2 module validation and using FIPS cryptography.

Good Crypto: Uses the right tool for the right task, much as BitLocker was carefully designed to use AES CBC with the Elephant Diffuser. See Microsoft's explanation of its choice of algorithms for a surprisingly understandable and easy-to-read guide to choosing cryptography protocols.

Bad Crypto: Uses whatever sounds good in the marketing materials--the more familiar the name, the better--regardless of applicability.

Going The All-microsoft Route

With many technology problems, if you implement only related applications from a single vendor, the number of headaches you're likely to run into drastically decreases. Although this isn't always feasible for political, technical or other reasons, going whole hog with Microsoft can meet your enterprise encryption needs.