Risk
6/25/2008
07:30 PM
50%
50%

Tech Road Map: EKMI

Oasis' open Enterprise Key Management Infrastructure initiative promises less-complex encryption. But will vendors get on board?

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.

InformationWeek Reports

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.

DIG DEEPER
KEY OVERLOAD
If you don't manage encryption well, data will be compromised. To find out how to corral keys while we wait on EKMI,
Ensuring the confidentiality, integrity, and availability of keys is a primary concern for any encryption technology, and complexity is a long-standing problem that has put a drag on comprehensive data encryption. Ask people with experience managing encryption systems about deterrents to large-scale deployments, or use across various systems, and they'll often point to the proprietary nature of these applications and the diverse methods they use to address management functions.

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.

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-2808
Published: 2015-04-01
The PRNG implementation in the DNS resolver in Bionic in Android before 4.1.1 incorrectly uses time and PID information during the generation of random numbers for query ID values and UDP source ports, which makes it easier for remote attackers to spoof DNS responses by guessing these numbers, a rel...

CVE-2014-9713
Published: 2015-04-01
The default slapd configuration in the Debian openldap package 2.4.23-3 through 2.4.39-1.1 allows remote authenticated users to modify the user's permissions and other user attributes via unspecified vectors.

CVE-2015-0259
Published: 2015-04-01
OpenStack Compute (Nova) before 2014.1.4, 2014.2.x before 2014.2.3, and kilo before kilo-3 does not validate the origin of websocket requests, which allows remote attackers to hijack the authentication of users for access to consoles via a crafted webpage.

CVE-2015-0800
Published: 2015-04-01
The PRNG implementation in the DNS resolver in Mozilla Firefox (aka Fennec) before 37.0 on Android does not properly generate random numbers for query ID values and UDP source ports, which makes it easier for remote attackers to spoof DNS responses by guessing these numbers, a related issue to CVE-2...

CVE-2015-0801
Published: 2015-04-01
Mozilla Firefox before 37.0, Firefox ESR 31.x before 31.6, and Thunderbird before 31.6 allow remote attackers to bypass the Same Origin Policy and execute arbitrary JavaScript code with chrome privileges via vectors involving anchor navigation, a similar issue to CVE-2015-0818.

Dark Reading Radio
Archived Dark Reading Radio
Good hackers--aka security researchers--are worried about the possible legal and professional ramifications of President Obama's new proposed crackdown on cyber criminals.