Tuesday, October 28, 2008

Key Vault Concept Application

Sometimes back came across a Google published Toolkit that aimed at safe and simple use of cryptography in their applications. That inspired this project namely, a key vault.

APPLICATION: KEY VAULT

This project also has relevance to an earlier discussion in an adjacent blog, studying the various building blocks of a DRM Server.

The following figure outlines what could be a high-level overview of modules present in a typical key management System.



KEY VAULT - STATEMENT OF THE PROBLEM

Enterprise applications store sensitive information in databases & there are Media applications that produce and manage content of considerable dolor value. A common problem faced by these applications is that they require a key vault to store and manage the cryptographic keys used for content protection.
Usage Scenarios

Expanding on the above problem statement,this link elaborates on the kind of users and usage models that we want our Key Vault application to satisy.


REQUIREMENTS

This section establishes some of the high-level goals of the key vault application. The scope is established by the requirements stated here for our application.

INTRODUCTION

"It's all talk until the code runs."— Ward Cunningham

In this section, we describe a rudimentery framework for a key management sub-system. The design we will consider is flexible enough to make use of any available crypto library as its engine. However, this discussion is based on a crypto library from google, namely keyczar.. The above KMS framework gets its roots from Kevin Kenan's work on "Cryptography in the Database - The Last Line of Defense". Readers are welcome to share your thoughts experiences on this subject in the comments section of this blog.


Consumer Interface:


This is an Application facing software interface and can be configured to use different keysets depending on the type of data. For e.g., if you are encrypting an XML snippet that is part of a larger message, you can configure the consumer to use a specific set of keys for this purpose.



...

try {

KeyConsumer kc = new KeyConsumer(); // API

// set Data identity, selects keyset to use for Crypto ops. userData udata = new userData(dataIdentity.IDMSG_ENC_A);

// setup the raw data in user object
udata.put( new String("Secret Message") );

// invoke crypto operation
kc.encrypt(udata);

System.out.println(udata.get());

// invoke another crypto operation
kc.decrypt(udata);

System.out.println(udata.get());
}
catch(Exception ex){
ex.printStackTrace();
}





Provider Interface:


A provider abstracts the consumer from the specifics of an engine used to perform the crypto operations. Provider uses the crypto engine to complete the requested operation and returns a receipt to the consumer. The receipt contains the resultant data and certain identification information. This level of abstraction allows us to plug-in different engines and key vaults, where it is desirable.


Key Manifest Interface:


The Key Manifest bridges the key aliases used by consumer to the actual keysetIds in the key vault. It also has the important function of managing Key Life Cycles.


Key Engine Interface:


This interface is used by the provider to satisy all the crypto operation requests from the consumer. Access to this module should be access restricted. The key engine reads the keysets from the key vault and transforms the user data.

In this implementation, we make use of keyczar, which uses a file system based key vault. The keyczar library is adopted to read the keys from a database instead.


Key Vault Interface:


The Key Vault stores all the keys used in the applications cryptographic operations. Hence, it must be access restricted. The IKeyVault interface, typically provides opertations to add/remove/update/read keys from the key vault.

Key Vault is utilized by the Engine and the Key Manager components.


Key Manager Interface:


This interface performs the administration of the keys as well as the configuration of the key vault and the key manifest. It is access restricted to cryptographic officers.

No comments: