<span style='font-family:Verdana'><span style='font-size:12px'>Hi Malini,<br /><br />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 ?<br /><br />Thanks<br /><br />Paul<br /><br /> <p style="margin:0px; padding:0px;" > </p><blockquote style="border-left: 1px solid rgb(204, 204, 204); padding-left: 5px; margin: 0px 0px 0px 5px;" type="cite"><p style="margin:0px; padding:0px;" ><span style="font-family: Verdana;"><span style="font-size: 12px;">----- Original Message -----</span></span></p><p style="margin:0px; padding:0px;" ><span style="font-family: Verdana;"><span style="font-size: 12px;">From: Bhandaru, Malini K</span></span></p><p style="margin:0px; padding:0px;" ><span style="font-family: Verdana;"><span style="font-size: 12px;">Sent: 03/09/13 01:41 AM</span></span></p><p style="margin:0px; padding:0px;" ><span style="font-family: Verdana;"><span style="font-size: 12px;">To: Nate Reller, OpenStack Development Mailing List</span></span></p><p style="margin:0px; padding:0px;" ><span style="font-family: Verdana;"><span style="font-size: 12px;">Subject: Re: [openstack-dev] key manager proposal</span></span></p> <div link="blue" vlink="purple"><div class="WordSection1"><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Thank you Nate for detailed comments. Please do send your UML diagrams.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">-----Original Message-----<br />From: Nate Reller [mailto:rellerreller@yahoo.com]<br />Sent: Friday, March 08, 2013 12:16 PM<br />To: openstack-dev@lists.openstack.org<br />Subject: Re: [openstack-dev] key manager proposal</p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">Malini,</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">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.</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">*** Master Key and Access for Compute Hosts ***</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">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.</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Yes, understand that you want compute host to do the encryption.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Just as easy to establish trust-worthiness of compute hosts as normal service hosts.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Currently VMs can be deployed on “trusted” and “untrusted” compute hosts.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Likewise volumes can be attached  to trusted and untrusted compute hosts, and the volumes themselves </span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Encrypted or plain text.  </span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">==================</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Host              |  Volume</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Untrusted    |   plain</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Untrusted    |   encrypted     </span><span style="font-family: Wingdings; color: rgb(0, 112, 192);">è</span><span style="color: rgb(0, 112, 192);">   “Mixed Bag”</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Trusted        |    plain</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Trusted        |   encrypted</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">The issue then becomes “untrusted” compute host dealing with an encrypted volume.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">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.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Having the master key without the actual key is not useful.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">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</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Control after establishing authorization credentials.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">The encrypted key string is only released to Cinder/Compute host, after trust is delegated from the above authorization. </span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">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</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Trust it with a master key because it has no TPM secure storage.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">May be I am missing something, and thus do not understand your concern.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Volume = V</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Key to volume V = k-v</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Master = m</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">If compute host has a/the master key == m, it still needs k-v and V (the encrypted volume) to get to the secrets.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">We are controlling access to k-v.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">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.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">do not want to just save as plain text a symmetric key  (one of your interface related suggestions if I understand correctly)</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">The common master, versus special handling is so that</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Volume = NateV</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Compute-node-host-A    Compute-node-host-B Compute-node-host-C</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Your VM should be technically able to run on the above A, B, or C and attach volume NateV.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">If master encryption key lives only on compute-node-host-A, then you can decrypt the volume only on A.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Alternately if VM runs on compute-node-host-B, need to retrieve the master from compute-node-host-A or elsewhere.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">After retrieving master, then retrieve the volume specific key NateV-k.</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: rgb(0, 112, 192);"> </span></p><p class="MsoPlainText">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.</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">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.</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">*** Authroization Token ***</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><span style="color: rgb(0, 112, 192);">Certainly want to pass in other information, including encryption preferences (algorithm, key-size etc)</span></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" ><span style="color: black;"> </span></p><p class="MsoPlainText">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.</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">*** Miscellaneous Thoughts ***</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">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.</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">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.</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">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.</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">This topic is of interest to the OpenStack Security Group (OSSG). You may want to join the meetings on Thursdays.</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">Link to encrypt-cinder-volumes blueprint:</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><a href="https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes"><span style="color: windowtext; text-decoration: none;">https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes</span></a></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">-Nate</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">> When you get a chance we checkout</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">> <a href="https://wiki.openstack.org/wiki/KeyManager"><span style="color: windowtext; text-decoration: none;">https://wiki.openstack.org/wiki/KeyManager</span></a> > I hope I have captured ideas and addressed concerns we have discussed on this mailing list.</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"> </p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">_______________________________________________</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText">OpenStack-dev mailing list</p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><a href="mailto:OpenStack-dev@lists.openstack.org"><span style="color: windowtext; text-decoration: none;">OpenStack-dev@lists.openstack.org</span></a></p><p style="margin:0px; padding:0px;" > </p><p class="MsoPlainText"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><span style="color: windowtext; text-decoration: none;">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></a></p><p style="margin:0px; padding:0px;" > </p></div></div></blockquote></span></span>