[openstack-dev] key manager proposal

Bhandaru, Malini K malini.k.bhandaru at intel.com
Wed Mar 20 22:00:51 UTC 2013


Paul,

You summarized your intermediate lockbox solution well .. and as Caitlin and Oleg mention it is similar to Caitlin’s design.

Here are my thoughts …

·        By replicating lockbox, yes, single point of failure eliminated. On each machine set-up, lockbox could be replicated.


·        For Swift storage this solution would work, because the storage nodes, would not have the 1000 odd intermediate keys.
These would be present say on the Swift proxy node, a disparate machine (unless on a toy development environment where everything resides on a single machine).


·        However, with Volume encryption, the intermediate keys would be in a lockbox ( or TPM), on the compute node, the same physical device
on which the encrypted volume would reside.
Caitlin had raised early on an important issue, if a thief stole the machine with its attached disks, they would then have everything they needed to crack open the secrets and with time on their side. By introducing another physical device to hold the random unique object key (in this case random unique volume key), we make this task more difficult.


·        Re-keying becomes more difficult, need to find on disparate storage devices the encrypted keys and decrypt/re-crypt them.


·        For that matter, even with my key manager solution, re-keying would need to take into consideration whether an object/volume etc was “checked-out”.


Regards
Malini

From: Paul Sarin-Pollet [mailto:psarpol at gmx.com]
Sent: Wednesday, March 13, 2013 5:50 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] key manager proposal

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 [mailto:rellerreller at yahoo.com]
Sent: Friday, March 08, 2013 12:16 PM
To: openstack-dev at lists.openstack.org<mailto: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<mailto: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/20130320/b22e5028/attachment-0001.html>


More information about the OpenStack-dev mailing list