Open Stack

Paul,

This looks somewhat similar to 'lockbox' model proposed by Caitlin Bestler
in one of threads discussing volume encryption. 'Intermediate' keys storage
roughly maps to lockbox concept, in my understanding.

--
Best regards,
Oleg


On Wed, Mar 13, 2013 at 4:50 PM, Paul Sarin-Pollet <psarpol at gmx.com> wrote:

> 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 <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
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20130314/445e3d4e/attachment.html>