1
KEY MANAGEMENT SYSTEMS
PHILIP HUYNH
University of Colorado at Colorado Springs
Abstract
Key Management System is having an important role in the enterprise environment. Many
applications need encryption keys for data encrypting, or digital certificates for authentication. This
paper provides a survey about Key Management standards such as the P1619.3 standard - Key
Management Infrastructure for Cryptographic Protection of Stored Data, and the Key Management
Interoperability Protocol (KMIP) standard. I also discuss about a Symmetric Key Management System
that is the open source code in the Java language.
I.
Introduction
Encryption has traditionally been both expensive and difficult to use. This limited its
widespread use to little more than SSL, the protocol that’s used to authenticate Web servers
and encryption connections to them. The recent proliferation of data security and privacy laws,
however, has made the use of encryption attractive in many other cases.
The rest of the paper is organized as follows. In session II, I discuss about the Key
Management System. In session III, I discuss about the IEEE P1619.3 standard for protection of
data storage. Session IV is about the Symmetric Key Management System from the StrongKey. In
session V, I discuss about the OASIS Key Management Interoperability Protocol. I conclude in the
session VI.
II.
Key Management Systems
Key Management Functionalities
 Key Generation
 Key Distribution
 Key Storage
 Key Replacement / Exchange
 Key Usage
 Key Destruction
Key Management System Security
 Prevent intruder from obtaining a key
 Avoid unauthorized use of keys, deliberate modification and other forms of
manipulation of keys
 Once the reliability of a key is impaired, its use must be terminated immediately
III.
IEEE P1619.3 Standard
Storage devices are a particularly attractive target for hackers because they concentrate the
sensitive data that they want – one backup tape can easily hold more credit card numbers than
2
a hacker could obtain in a lifetime of intercepting online payment information. To defense
against such attack, security experts’ adoption of technologies that encrypt data in storage has
outpaced the adoption of most other encryption uses. This has resulted in an entirely new set of
difficult problems related to key management, but the Security in Storage Working Group
(SISWG) is looking to solve them with the P1619.3 standard, “Key Management Infrastructure
for Cryptographic Protection of Stored Data”.
There are some problems for storage protection in the Figure 1. We can’t always expect a
tape drive to be able to get keys from an encryption appliance’s key server, or for an encryption
appliance to be able to get keys from a tape drive’s key server because there is very little
interoperability between vendors’ key management systems.
We can’t expect a storage device to be able to get keys from a distant key server. If we
encrypt a backup tape in New York data center and send the tape to an offsite backup facility we
can’t always expect that the data can be decrypted at the backup facility because the storage
device there may be unable to reach the key server that provide the decryption key.
The P1619.3 standard’s ambitious goal is to eliminate all these problems and make
interoperable key management possible. The standard abstracts the components of a
cryptographic system into a key management server, key management client, and a
cryptographic unit. The interaction between these components is shown as in the Figure 2.
3
The function of each abstract component as following:
Key management server creates and distributes keys as well as the policies covering their
use.
Key management client get keys and policies from a key management server on behalf of a
cryptographic unit.
Cryptographic unit performs actual encryption and decryption operations with the keys the
key management clients manage.
Any product that complies with the P1619.3 standard will support a standard set if
operation between these components.
In addition, the P1619.3 standard also defines operations between key management
servers. Any compliant implementation will also support a standard set of operations that let
key management servers work together by securely exchange both cryptographic keys and
policies.
IV.
Strongkey Symmetric Key Management System
Symmetric encryption key management has traditionally been buried in applications
performing encryption. These applications primarily focused on business functions, but
managed encryption keys as an ancillary function. Consequently, there was no reason to
emphasize key management. But there are changes in the key management at the enterprise
level. Applications are typically purchased from multiple vendors, each vendor, focusing
primarily on its own business application, implements encryption and performs key
4
management functions using its own design. As a result, the IT Operations staff ate forced to
manage at least 8 to 10 distinct symmetric key management infrastructures, each with its own
technology, training, documentation, procedures and audits. More importantly, it raises the
total cost of ownership (TCO).
A client/server system has introduced as a solution for symmetric key management. The key
management functions in the applications have been abstracted and consolidated on one or
more centralized Symmetric Key Services (SKS) server on the network. Using a client side API,
applications on most platforms can make requests for symmetric key services.
An SKMS consists of at least two centralized SKS server – a primarily and a disaster recovery
server, and any number clients using the Symmetric Key Client Library.
Figure 3. The Client/Server Architecture
Each SKS server consists of:
 A server-class computer running an OS – Linux, UNIX, or Windows that has JVM
available for it
 A relational database for storing the symmetric encryption keys.
 A J2EE compliant application server to response to the requests over the network
 A JCE-compliant cryptographic provider to perform the cryptographic operations of key
generation, key protection, digital signing, verification,…
 An optional, Hardware security module (HSM) or Trusted Platform Module (TPM) for
securely storing the cryptographic keys that protect the database’s content
 The SKS server software, consisting of an Enterprise Archive (EAR) and a Web archive
(WAR) file for administration console
Each SKCL client platform consists of:
 A client computer running an OS – Linux, UNIX, Windows, and OS/400 that has JVM
available for it
 A JCE-compliant cryptographic provider to perform the cryptographic operations of key
generation, key protection, digital signing, verification
5


An optional, Trusted Platform Module (TPM), smartcard, or other USB-based
cryptographic token for securely storing the cryptographic keys that protect client’s
authentication credentials.
The SKCL software, consisting of an API callable by Java applications for communicating
with the SKS server and performing cryptographic functions. Non-Java applications have
the option of either using a JNI library to call the SKCL, or communicating with the SKS
server directly using the SKSML protocol.
The SKSML protocol consists of:

A call from the client to request a symmetric key – new o existing – from the SKS server.

A call from the client to request key-caching policy information from the SKS server.

A response from the SKS server containing the symmetric key and key’s use policy.

A response from the SKS server containing the key-caching policy.

A fault message from the SKS server, if either of the two calls doesn’t succeed.
When a client – be it a laptop, a DB application, or an e-commerce Web server – needs a
symmetric key to encrypt some information, it makes a request for a new symmetric key to
the linked-in SKCL.
The SKCL checks its key-cache to determine if it has any cached symmetric key that is
valid for use. If so, it retrieves the key, decrypt it, verifies its integrity, checks its
KeyUsePolicy and then hands the requesting application the symmetric key for use. If the
application chooses not to use the SKCL for the actual encryption/decryption operation, it is
expected to use the key in conformance with the embedded KeyUsePolicy.
If any of the local checks result in no valid symmetric key being available for use, the
SKCL creates a new symmetric-key request, digitally signs it with its authentication
credentials, and sends the request to one of its pre-configured SKS servers. All requests and
responses between the SKCL and the SKS servers are secured (digitally signed and
encrypted) at the message level.
The SKS server, upon receiving such a request, verifies the authenticity and integrity of
the request, determines the authorization and the symmetric key policy in force for the
requester, generates a new symmetric key based on this policy, assign it a Global Key ID,
escrow the key, encrypts the key with requester’s transport digital certificate, logs the
transaction details and responds to the client.
The SKCL client, upon receiving such a request, verifies the authenticity and integrity of
the request, catches the secured object if so configured decrypts the symmetric key and the
6
embedded KeyUsePolicy, and returns it to the calling application. The calling application at
this time may choose to have the SKCL perform the actual encryption, or perform it itself.
V.
OASIS Key Management Interoperability Protocol
The proliferation of key management system result in higher operational and infrastructure
costs of enterprise using encryption, certificates, asymmetric key pairs, and other encryption
technologies.
The proliferation of protocols, even when supported by a single enterprise key manager,
results in a higher cost for developing and supporting the key manager.
A single protocol for communication between enterprise key management server and
cryptographic clients.
7
By defining a protocol that can be used any cryptographic clients; KMIP enables enterprise
key management servers to communicate via a single protocol to all cryptographic clients
supporting that protocol.
Through vendor support KMIP, an enterprise will be able to consolidate key management in
a single enterprise key management system, reducing operation and infrastructure costs while
strengthening operational controls and governance of security policy.
VI.
Conclusion
Strongkey SKMS is open source in JAVA language. It is useful for IT staffs to study and SW
developers to customize their own SKM systems. P1619.3 Standard is for storage protection.
KMIP gives the encryption clients from different vendors or different technologies the ability to
talk to a single KM system by using a single protocol.
References
[1] Jan C.A. VAN DER LUBBE Basic Methods of Cryptography, Cambridge University Press, 1999.
[2] Arshard Noor Symmetric Key Management System, ISSA Journal, 01/2007.
[3] Key Luther Martin Management Infrastructure for Protecting Storage Data, Computer, 07/2008.
[4] Key Management Interoperability Protocol version 1.0, OASIS, 05/2009.