[openstack-dev] Encrypted Objects in Swift

Oleg Gelbukh ogelbukh at mirantis.com
Wed Dec 12 13:50:49 UTC 2012


Hello, Malini

Sorry for long delay, please see some answers inline. Thanks for your
interest and insightful questions and links!


On Fri, Dec 7, 2012 at 4:43 AM, Bhandaru, Malini K <
malini.k.bhandaru at intel.com> wrote:

>  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.
>
Yes, currently we're preparing the code and design description for
publishing. Please, follow our blog for updates later this week.

> ****
>
> ** **
>
> 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
>

We're focusing on data-at-rest encryption right now, and we're using
AES-128-CBC algorithm as a primary method. Thanks for the links, we'll look
how to integrate those libs in our work.


>  **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.
>
We're planning on storing IV/salt/secondary key in the container DB for
each object. This will help increase overall security of the solution, but
will require modification of container-server.

> ****
>
> **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.
>
This is an interesting idea, but it generally affects the key storage part
of the architecture, which is basically out of scope of our prototype.

> ****
>
> **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?
>
Key manager is a middleware in Swift that talks to the key storage system.
We implemented it as driver-based, which means we can easily integrate with
any key store, including one integrated into auth system. We want to
separate the key-manager from any particular auth system supported by Swift
to be able to work with all of them.

> ****
>
> **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.
>
This is also very interesting idea. It will probably require modifications
to the current prototype implementation of key manager, of course.

> ****
>
> **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> 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
> 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
>
>
--
Best regards,
Oleg Gelbukh
Sr. IT Engineer
Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121212/6ba0199a/attachment.html>


More information about the OpenStack-dev mailing list