Open Stack

Perhaps we can imagine a pool of intermediate keys (between master keys and object keys) :
- 1000 (for example) intermediate keys are stored in the key manager and saved somewhere else, encrypted by a unique master key
- Each service can load and store in memory all the intermediate keys from the key manager
- Each object is encrypted by an unique object key randomly generated
- The object key is encrypted by intermediate key, randomly selected, and is stored with the object as a metadata
- The intermediate key id is stored as a metadata with the object

My major focuses :
- avoid the loss of association object + object key
- avoid the SPOF effect of the key manager

----- Original Message -----
From: Bhandaru, Malini K
Sent: 03/12/13 07:48 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] key manager proposal

Yes Paul, it could be stored as you suggest, but the idea behind having a separate key manager is to make things more difficult.
Say someone stole a disk with a bunch of 
Enc-obj-1, enc(key-1, master-key>
Enc-obj-2, enc(key-2, master-key>
Enc-obj-3, enc(key-3, master-key>
The moment that master-key is cracked, obj1, 2, 3 become accessible.
Object-store/volume-store key-manager
Enc-obj-1, key-id-1 key-id-1: enc(key-1, master-key>
Enc-obj-2, key-id-2 key-id-2: enc(key-2, master-key>
Enc-obj-3, key-id-3 key-id-3 enc(key-3, master-key>
Even with a TPM, the master-key would be saved encrypted in the TPM storage. Should the object host computer get stolen, and the
Master-key extracted, the data would still be safe through a chain of actions (disabling access to the key-manager, changing master key, and
re-encrypting all the key-strings associated with the service with a new master) .
On the note of making things harder to crack, one could have another layer of protection, encrypting key-id with a master-key-id …
Regards
Malini
From: Paul Sarin-Pollet [mailto:psarpol at gmx.com]
 *Sent:* Tuesday, March 12, 2013 3:44 AM
 *To:* OpenStack Development Mailing List
 *Subject:* Re: [openstack-dev] key manager proposal
Hi Malini,

Do you agree that instead to store the key-id and the key in a key manager, the key itself could be stored, encrypted by master key, as a metadata with the object ?

Thanks

Paul

----- Original Message -----
From: Bhandaru, Malini K
Sent: 03/09/13 01:41 AM
To: Nate Reller, OpenStack Development Mailing List
Subject: Re: [openstack-dev] key manager proposal

Thank you Nate for detailed comments. Please do send your UML diagrams.
-----Original Message-----
From: Nate Reller [ rellerreller at yahoo.com ]
Sent: Friday, March 08, 2013 12:16 PM
To:  openstack-dev at lists.openstack.org 
Subject: Re: [openstack-dev] key manager proposal
Malini,
Sorry for the long reply, but I have a lot of thoughts on this. I like the proposal overall, but I have some concerns and suggestions.
*** Master Key and Access for Compute Hosts ***
My biggest concerns are with regards to the master key and preventing access to the compute hosts. In our proposal, encrypt-cinder-volumes, the compute host is encrypting the cinder volume data after it leaves the VM and before it is sent to the cinder host. Clearly we would like for compute hosts to have access to the Key Manager to allow them to encrypt the data.
Yes, understand that you want compute host to do the encryption.
Just as easy to establish trust-worthiness of compute hosts as normal service hosts.
Currently VMs can be deployed on “trusted” and “untrusted” compute hosts.
Likewise volumes can be attached to trusted and untrusted compute hosts, and the volumes themselves 
Encrypted or plain text. 
==================
Host | Volume
Untrusted | plain
Untrusted | encrypted è “Mixed Bag”
Trusted | plain
Trusted | encrypted
The issue then becomes “untrusted” compute host dealing with an encrypted volume.
The “volume” master key only encrypts the key-string, just so key-strings are not in lying around as plain text on the key-manager node.
Having the master key without the actual key is not useful.
A volume is attached to a VM only after establishing that they all belong to the same user/project/domain. This is standard keystone token access
Control after establishing authorization credentials.
The encrypted key string is only released to Cinder/Compute host, after trust is delegated from the above authorization. 
We could deliver the key to decrypt the volume to such a compute host encrypted with the host-PKI public-key because we do not want to
Trust it with a master key because it has no TPM secure storage.
May be I am missing something, and thus do not understand your concern.
Volume = V
Key to volume V = k-v
Master = m
If compute host has a/the master key == m, it still needs k-v and V (the encrypted volume) to get to the secrets.
We are controlling access to k-v.
The key manager holding the set of keys {k-v} will not have access to the master, and in so doing protects all the keys it has.
do not want to just save as plain text a symmetric key (one of your interface related suggestions if I understand correctly)
The common master, versus special handling is so that
Volume = NateV
Compute-node-host-A Compute-node-host-B Compute-node-host-C
Your VM should be technically able to run on the above A, B, or C and attach volume NateV.
If master encryption key lives only on compute-node-host-A, then you can decrypt the volume only on A.
Alternately if VM runs on compute-node-host-B, need to retrieve the master from compute-node-host-A or elsewhere.
After retrieving master, then retrieve the volume specific key NateV-k.
My other concern is with the master key idea. The compute hosts will be responsible for encrypting and decrypting the data for cinder volumes. If the keys for doing this are encrypted by a master key then the master key must be shared by all compute hosts that will use the cinder volume. That would require copying the master key to multiple platforms and that makes me nervous. This is my biggest concern with master keys encrypting other keys. It forces the master key to be shared with all entities that will use the key.
I propose changing the interface to operate on generic Key objects. Then we can have classes of Key objects for different types of keys. One Key class may be a SymmetricKey class for storing AES keys and the like. Another Key class may be an EncryptedSymmetricKey class that stores a symmetric key that is encrypted by a master key. This way the interface can support the use cases for master keys and plain old symmetric keys. It would also support split keys. I can send a UML diagram or two with my thoughts if you like. Let me know.
*** Authroization Token ***
Certainly want to pass in other information, including encryption preferences (algorithm, key-size etc)
I like that your API takes in an authorization token. Do you have more details on what that would be? Our prototype right now takes in the context of the caller (i.e. the user). I would like to extend that to have the interface take in a security context that not only provides an authorization token from the user, but it may include other information as well. I am thinking about information specific to the platform. For instance, I may want to have the compute host provide a signed TPM quote, so the Key Manager can verify that the caller is from a particular platform. I would be interested in brainstorming more ideas on this. I'm also not sure what the Keystone group is working on in this area. I also think it would be cool to integrate TNC into this, but I'm not sure how to do that.
*** Miscellaneous Thoughts ***
I would like to see the Key Manager as its own service. I think many different services have a need for a Key Manager and making it its own service would be useful.
TPM could be used to encrypt all keys on Key Manager platform. Then you could lock the keys down unless the platform is in a specific state.
I don't think we should limit key scope. I imagine there will be many different use cases for keys, and the key scope will be different for each one. It may also be different per deployment.
This topic is of interest to the OpenStack Security Group (OSSG). You may want to join the meetings on Thursdays.
Link to encrypt-cinder-volumes blueprint:
https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes 
-Nate
> When you get a chance we checkout
> https://wiki.openstack.org/wiki/KeyManager  > I hope I have captured ideas and addressed concerns we have discussed on this mailing list.
_______________________________________________
OpenStack-dev mailing list
 OpenStack-dev at lists.openstack.org 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130313/1e90c982/attachment.html>