Jump to: navigation, search

Difference between revisions of "KeyManager"

(Key API)
(Key Manager)
Line 3: Line 3:
malini.k.bhandaru "at" intel.com
malini.k.bhandaru "at" intel.com
== History ==
March 06, 2013:  Initial version
April 14, 2013: Added reference to Rackspace session at OpenStack Summit
April 18, 2013: Added pointer to etherpad from Key Manager design session at OpenStack Summit
April 23, 2013: Added section on "Post summit discussion" changes/clarifications

Revision as of 07:13, 23 April 2013

Key Manager

malini.k.bhandaru "at" intel.com https://etherpad.openstack.org/havana-key-manager


March 06, 2013: Initial version




Server side encryption with key management would make data protection more readily available, enable harnessing of any special hardware encryption support on the servers, make available a larger set of encryption algorithms and reduce client maintenance effort. Amazon and Google’s object storage systems provide transparent data encryption. Encryption is no longer prohibitive with newer chips available that carry hardware support for AES-NI, and implementations that harness possible parallelisms in data and processor architecture. The popular wisdom today is increase security [1]

Recently interest has grown in [[1]] to provide server side encryption in Cinder ( Volume ) [2], Swift ( Object ) [3], Glance ( Snapshot ).



Security Model


different keys.

Design Considerations

High Availability




Opaque Keys


Protecting Master Keys


Restricting Service Access


Restricting Key Access



Key Attributes / meta-data

Keys could have attributes such as no-cache, number-of-uses. KMIP has a notion of usage-mask, who can use for what purposes (encryption/decryption etc).

Key Caching



Need to log all access to keys,<who, what, when> CRUD: creation, read, update, delete actions should be logged as important events. This would meet regulation/audit needs such as HIPAA, Sarbanes Oxley etc.

Invalid/autherized attempts shpuld also be logged including IP address, time etc that may indicate hacking attempts and need for action.

Life Cycle Management: Background Tasks

  1. archiving, re-keying
  2. API for life cycle management
  3. Plug-in solutions/implementations (open source and proprietary)

Side Benefits


Key Manager in OpenStack


  create <authorization-token>
        Key manager will create a random key and save the same, and return a tuple  <key-id, key-string>
       The communication between requester and key-manager should be secure to ensure that the key is not compromised.
  get <key-id>   <authorization-token>
  delete<key-id> <authorization-token>
  update<key-id> <authorization-token>

By supporting key delete, we essentially render any stored data associated with it inaccessible. It will not be necessary to "wipe" clean / shred for instance a block device. Just necessary to update that they area is free and can be re-used.

Key Scope:

  • Per user
  • Per project (within a domain)
  • Per domain


Key Size



Key Manager in OpenStack

The master keys would be held in TPM Storage TPM Close-Up

OpenStack Service and Key Manager Internals





enc-object-x, meta_data: <enc:true, algorithm:aes-cbc, key-id: 1234567899 >

Similarly, an encrypted Cinder volume might be represented as



Key Flow


Encrypted saving of an object

Decrypted retrieval of an object


  1. Another failure point: With another service, Key Manager, in the picture, we have another component that could fail. But encryption need keys, maintained by either the end user or the server. This is a feature cost. Caching keys mitigates some of the problems that arise from network latency and server failure. Using the TPM to protect the encryption master keys makes the cache less of a security hole.
  2. KMIP: Do we need to support KMIP [7] in OpenStack? If the keys are not for end user direct consumption, KMIP is not mandated. However if we desire to use the key manager to save private and public keys of the OpenStack services, then KMIP would be useful to exchange information across cloud boundaries.
  3. Encryption data transfer overhead: Keys typically are not updated, except on master key re-keying. Swift uses Rsync for replication, and for objects of size keys, it is not a performance criterion. However, strong encryption requires Initialization Vectors (IV)/Salts/and cipher chaining. Thus a small change in a document towards the beginning will generate a totally different encrypted object, which is what we desire, but in the context of Rsync, it implies a full data payload needs to be transferred. But data protection overrides all else here. Further, use cases may establish that this is an unwarranted concern if typically there are few updates to an object.
  4. Unauthorized key deletion: If we use a Swift based system for the Key Manager backend store, a hijacked server with spurious insertions of tombstone records to mimic a legitimate deletion Swift storage nodes would result in key loss by way of a background reaper task periodically deleting such objects. This would not be a new security hazard, and has to be handled as today. Perhaps key deletion could be turned off to prevent such havoc.
  5. Fear of Key Loss: Key Manager back end storage should ideally be distributed in geographically disparate locations.
  6. Salts/IV: A key per object/entity behaves like a salt/IV, especially when used in conjunction with a user/project/domain (wider scope) key

Phased Implementation

Key Manager implementation could be in phases along the lines below. Double locking could even be part of phase I.

Phase I

  1. Stub Key Manager, could pull out JHU-APL or Mirantis Key Manager implementation or Rackspace's (*) key manager as a service solution(added April 14, 2013), and float as either a new OpenStack Service ( or a sub-service of KeyStone). Essentially establish all the plumbing flows. Define a KeyManager_client that the other services use, via the KeyManager API. The key manager back end could initially be a file or mysql or sqlite database. The default could be mysql backend for devstack like single machine deployments for developer/testing.
  2. Master keys stored on Python key ring or using mechanisms similar to private key protection on the various OpenStack service host machines.
  3. Encryption algorithm and parameters could initially be defaults in a nova conf file (JHU-APL approach for volume encryption) or defaults per user/project/domain, going up the generalization chain till something specifc is found else use a domain level default.

Phase II

Make Key Manager a separate Swift instance, with multiple zones for storage. This would support true HA and fault tolerance.

Phase III

  1. Support multiple encryption algorithms via encryption library querying. Provide user interface support to select preferences and store as part of user/project/domain profile.
  2. Reaper routine to change a master key for a service, aka re-keying.
  3. Support dual locking, a feature that uses KeyStone Identity V3 API's trust feature.

Phase IV

Introduce true TPM support for master keys. For instance, volume encryption may prefer XTS, an encryption strategy that uses sector address. We have expertise on TPM within Intel, and attestation service support already in OpenStack, which is currently being used to verify goodness of compute nodes. This would extend to the OpenStack service nodes.

Phase V

Chef puppet support for transferring symmetric keys to the various service host machines, particularly to scale horizontally in as automated a fashion as possible.





TPM: Trusted Platform Module


  1. http://blog.dustinkirkland.com/2012/10/encrypt-everything-everywhere-in.html
  3. http://www.mirantis.com/blog/openstack-swift-encryption-architecture
  4. http://opensecuritytraining.info/IntroToTrustedComputing_files/Day1-7-tpm-keys.pdf
  5. http://en.wikipedia.org/wiki/Trusted_Platform_Module
  7. http://en.wikipedia.org/wiki/Key_Management_Interoperability_Protocol