Open Stack

Bhandra, Malini K wrote:


Ø  Malini: True. I do not comprehend your lock-box analogy completely.



A lockbox is a) where you store the keys which are needed to decrypt the encrypted entities,

b) what needs to be unlocked (preferably once) when it is established that the components
are operating as intended in the intended environment, and c) preferably stored somewhere
other than on the same devices that the enclosed keys reference.



As I understand your proposal, the lockbox is a central database.



I think that this approach actually undermines security.



What you should do instead is have a lockbox on each encrypting storage server (Cinder, Swift
and who knows what other storage services).



The role of the key-manager is to a) approve unlocking each lockbox so that the contents
can be used, and b) approve and enable transfers of individual keys between lockboxes.



With what I am proposing a key is *never* saved on disk or put on the wire in plain-text format.

Each system generates as-close-to-truly-random-as-possible keys *inside* their own lockbox.



One critical issue with a lockbox approach is where it is stored. If you stick with partitions and volumes

The lockbox will fit on TPMs or on-motherboard non-volatile storage. If you have a key for every object

Then the lockbox will no longer be small enough to do that. The number of storage devices in a scale-out
storage server is not typically that great, having to use an external device to safely hold keys will reduce

the capacity of the storage server as a whole. Using a TPM or some other on-motherboard small device
is far more effective.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130123/0554a5dd/attachment.html>