“Managed Keys” as an open source project

MOTIVATION

While working on a client-server project at my employer, the client software we were building in-house needed appropriate standards compliant Server software. The technology being built is to enable specific industry standards.

Our original plan was to rely on third-parties to supply the server side software. However, we quickly found out these companies were either going bankrupt or had unreliable support. Even if you are willing to pay an additional cost, these variations were occasionally throwing a monkey wrench into our project schedules.

MAKING A BUSINESS CASE

Realizing that this requires a long-term solution, I proposed that we build the server software in-house. My manager was not jumping with joy at the idea. He knows that endorsing this takes a commitment of resources on his part. Besides, he remembered to point out, there were already people working on that side of the equation.

However, at close examination the server software being built appeared to be patch jobs on previously built server software. They sometimes cost avoidable delays, as spurious bugs showed up and was costing time and money to debug and fix.

This got me thinking in terms of creating an open source project. My employer was neutral on the idea, as they knew it can be useful. However, they were too busy to weigh in on the effort and project its potential impact on the longer-term success of the client-server project.

So far, we discussed making a business case for the open source project. Now, you might have a legitimate question as to what in the world does this client-server software do?

WHAT CAN BE OPEN SOURCED?

Revealing projects that are not in the public domain will certainly irk my employer and that cannot be my intent, either. After some careful thought , I came to a resolution.

The server software in question requires software building blocks that can be widely applied to a variety of use cases. This blog will analyze and design these software building blocks in great detail.

SOFTWARE BUILDING BLOCKS

How to Secure your data?

The need to maintain confidential data in ecommerce applications and databases is not a new requirement. The following use case diagram paints a partial picture of some of the applications that have a need to protect sensitive data,



However, the art of protecting data can do with the availability of well thought out security frameworks, such as this one, presented by Kevin Kenan's work on "Cryptography in the Database - The Last Line of Defense".

If you scour the industry for such standard frameworks, it is hard to find an open source robust solution that you can build upon.

The apparent lack of security building blocks for safe and simple use of cryptography in applications has invoked a response from industry heavy weight google, as they cameout with a Toolkit known as keyzcar.

However, as we'll see here, these solutions generally tend to fall short in their support for a comprehensive Key Management strategy, as outlined by Symantec's Kevin Kenan in his well-written book.

Hands-on with Google's Cryptographic Toolkit

---

Providing a brief and efficient introduction to google's safe cryptographic library here, Keyczar: A Cryptographic Toolkit are the authors of the toolkit, Arkajit Dey and Stephen Weis.

You may also read about a hands-on approach that puts the toolkit through a few basic use cases.

Managed Keys

---

JUSTIFY THE PROJECT (ANALYSIS)

The lack of free and open source security building blocks to support use cases such as information assurance in an enterprise, or to monitize digital content, is a motivation for the "Managed Keys" project. Business databases need to be protected and digital data needs security.

While google's keyzcar and similar toolkits such as openssl are available for applications to perform cryptographic operations, the management of cryptographic keys used in these operations is a problem left for the applications to handle.

This is a non-trivial excersise for an application to handle on its own. If it does, the application must either dedicate its own resources to do so or the application's risks compromising on an effective content protection.

There is ample evidence from reading symantech's Kevin Kenan's "... last line of defense" book, you need an effective "Key Management Systems" as part of your enterprise information assurance infrastructure.

REQUIREMENTS BASELINE

The high-level functional requirements for our key management system is baselined as follows,

Purposeful Generation

1. Each generated key shall be assigned an application purpose tag that shall be used for selecting the key on a cryptographic application request.

Key Types

2. The key types supported include symmetric and asymmetric keys.
3. The default length for symmetric keys shall be 128 bits.
4. The default length for asymmetric keys is 1024 bits.
5. Key Lengths for symmetric keys shall be a subset of { 128, 256 }
6. Key Lengths for Asymmetric keys shall be a subset of { 1024, 2048}

Key Formatting

7. Keys shall be formatted as JASON strings for export.

Key Integrity and Protection

8. Keys shall have their HMAC values computed on their generation and stored and made available to assure integrity.
9. Keys shall be optionally encrypted themselves while at Rest in the Key Store.

Life Cycle

10. The life of a Key shall start with a status of "Pending" on birth and goes through "Live", "Retired" and finally the "Expired" stage collectively known as a key Life cycle.

Key Storage

11. Key store access interface shall remain independent of the specific storage used.
12. Key backup shall be available.

Access Control

13. Access to Key store shall be provided only to registered users.
14. All registered users shall have read-only access privileges to the Keys in the key store.
15. Administrative users shall have privileges to generate New Keys, modify and remove them.

PLANNING THE ARCHITECTURE