Jun 27, 2008 (08:06 PM EDT)
Tech Road Map: EKMI
Read the Original Article at InformationWeek
Information security pros do put stock in encryption--it was named the third-most-effective security practice in our most recent Strategic Security Survey, behind only firewalls and antivirus products. However, there have been obstacles along the path to ubiquitous encryption of data, including weak ciphers, deployment and integration issues, and, perhaps most notably, key management.
Public key infrastructure, or PKI, systems alone have simply failed to address the challenge of keeping encryption keys in order. Enter the Enterprise Key Management Infrastructure initiative, a promising program spearheaded by the Oasis consortium, with organizations including CA, Red Hat, the U.S. Department of Defense, and Wells Fargo represented on the technical committee.
The objective with EKMI is to create open standards for the interaction of various platforms, applications, and technologies that would benefit from the security of symmetric encryption with a central key management system, referred to as the Symmetric Key Management System, or SKMS. Combine SKMS with PKI--for strong authentication, message integrity, and key encryption; client software that includes an API designed to interact with Java-based applications, such as Web apps or middleware systems; and an XML-based protocol for communication between client and server--and EKMI becomes a single platform for managing what has, to this point, been a morass of cryptographic key management functions.
The EKMI design has been compared with that of a DNS or DHCP system, with a few similarities to LDAP--essentially, a client requests information from a central server that communicates with multiple back-end systems where keys are created or stored. In the EKMI model, the client application asks for a symmetric key through a digitally signed request; the key server verifies the client request, then encrypts, digitally signs, and escrows the key in a database. The back-end PKI system steps in to provide security for RSA signing and encryption keys. The EKMI server then responds to the client with a signed and encrypted symmetric key. The client interface verifies the response, decrypts the key, and hands it to the client application.
Clearly, EKMI is not a replacement for PKI but an enhancement to the interface between the key-generation process and those systems and applications that require access to keys.
EKMI holds a great deal of promise to solve these problems by combining essential elements into a holistic key management system. Creating a single interaction point for provisioning, escrow, recovery, caching, and destruction of symmetric keys will provide greater scalability to encryption deployments. If accepted and adopted, the standards would create a management platform that is independent of the technology applying the encryption, yet centralized in nature. Use of existing PKI systems for more extensive protection and establishing a single audit point for key management transactions are very attractive benefits of EKMI.
STRENGTH IN COMPLEXITY
There are, of course, obstacles that must still be overcome by EKMI proponents. For example, the proposed components are somewhat simple by design, which concerns some encryption purists who prefer more complex protocols, on the logic that they're more difficult to break into.
In addition, enterprises deploying an extremely sensitive system of this type that houses the keys to the kingdom will need to pay great attention to detail when hardening platforms and operating systems, a step strongly recommended by the Oasis technical committee. Failover and redundancy must also be considered during deployment to ensure availability.
Assigning these functions to an open set of protocols is asking for quite a big change in both technology and mind-set.
Then there are the problems associated with any open standard. Although published and commented on, some of the technological specifications that have been in use since the inception of the Internet aren't always implemented in, shall we say, strict adherence to their original guidelines. Integrating EKMI into the required clients for encryption of applications, endpoints, backup systems, and so on will require the cooperation of major application vendors. These entities--some of them fierce competitors--historically haven't been the most collaborative of groups. Not surprisingly, as of press time, there have been no large-scale public endorsements of EKMI, though Oracle is a member of Oasis.
Also working in EKMI's favor are recently publicized breaches and the trend for more statutory controls on the privacy of personal information, both of which are driving organizations to apply stronger data protection. We must now assume that all perimeter defenses are vulnerable, if not because of flawed technologies, then by way of the redefinition of the perimeter: The simple model of "inside, outside, and DMZ" is no longer viable as partner connectivity grows and customer-level access is increased.
Encryption represents a final level of protection. Even if data is lost or stolen, it's of no value to the holder without the decryption key. EKMI is a valuable component in the operational and management aspects of encryption, and organizations with complex encryption requirements ought to start putting pressure on their application and security vendors to support the initiative.
For now, we recommend following updates on the Oasis Web site or, if possible, joining the organization to provide input. As you purchase new security systems, those with less-proprietary interfaces will best lay the groundwork for EKMI.
David Brown is a managing consultant, security solutions, at Forsythe and has more than 20 years of experience in information security and related IT fields. Write to him at firstname.lastname@example.org.
Photo by Jupiterimages