Open Stack

Glad to hear from you Oleg!

Intel is interested in building encryption support for object storage.
Our initial exploration resulted in catching the Mirantis blog!  Establishes it is an important feature and the time is right.


1)      Would the Mirantis prototype be open source? Looking forward to its debut.

Intel's special interest - achieving encryption speed up using the AES_NI Intel  hardware instructions for encryption speed and
                                            its open source libraries fast encryption that exploits parallelism and function stitching, and HW register width increases.
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html
http://www.intel.com/content/www/us/en/communications/communications-ia-cryptographic-paper.html



2)      More specifically - what algorithm will you be using for encryption? Will it be user configurable?

The data in motion AES approaches to encryption typically use an initial vector (random for the session) and the key
And anything that has chaining will result in large changes in the byte stream for a small change in the plain text object, which
would result in more network traffic to move the object using rsync. Or are you dismissing the initial vector, and keeping chaining or dismissing it too.

Or are you using a data at rest encryption method?  The Intel library of XTS encryption is in use by True Crypt which offers storage encryption.
        http<http://download.intel.com/design/intarch/PAPERS/324310.pdf>://<http://download.intel.com/design/intarch/PAPERS/324310.pdf>download.intel.com/design/intarch/PAPERS/324310.pdf<http://download.intel.com/design/intarch/PAPERS/324310.pdf>


3)      Do you see any use cases not covered? Would like to collaborate.

4)      To provide an additional layer of protection, along with the key mentioned in the Mirantis article, a secondary random-key could be used with each object, possibly XOR-ed with the account or container key, to encrypt objects. Thus should result in key-loss/compromise not exposing the data unless the Key Manager is also compromised and these secondary keys get exposed.

5)      Am sure you have thought of this .. but the key manager itself could use the encrypted storage system to back up its vital data.

6)      From your design looks like the key manager is  a separate service from the authentication system (Keystone or other).  Was this to partition functionality and increase availability?

7)      We believe the encryption component with key management could be used in other places within Open Stack, for example booting from encrypted boot volume.

8)      Also believe the Keystone enhancements under discussion- "Trust"/delegation http://wiki.openstack.org/keystone/Delegation

would be useful for handing off access to encrypted objects, say for a one time  use, or limited period (use case: pay-per-view video) to an application that would stream the media content.


Regards
Malini



From: Oleg Gelbukh [mailto:ogelbukh at mirantis.com]
Sent: Thursday, December 06, 2012 2:20 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Encrypted Objects in Swift

Hello,

Yes, we have the prototype implementation of this feature waiting for publication. I believe we'll be able to publish it in a week or so.

Do you have some specific interest in this development? We greatly appreciate any feedback, including questions and example use cases.

--
Best regards,
Oleg Gelbukh
Sr. IT engineer
Mirantis Inc.

On Thu, Dec 6, 2012 at 7:07 AM, Bhandaru, Malini K <malini.k.bhandaru at intel.com<mailto:malini.k.bhandaru at intel.com>> wrote:
Hello All!

Is there development effort associated with http://www.mirantis.com/blog/openstack-swift-encryption-architecture/
in OpenStack?

Regards
Malini

_______________________________________________
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/20121207/47eba6c8/attachment.html>