[openstack-dev] Encrypted Objects in Swift

Bhandaru, Malini K malini.k.bhandaru at intel.com
Thu Dec 13 03:12:28 UTC 2012

Greetings Oleg!

Much thanks for your reply! If I do not hear from you, will await blog updates.

1.      Would you keep the IV fixed for an object /container once created fixed?
Or change on each update? The latter would be more secure, but result in more rsync traffic.

2.      As opposed to  modifying container, would it be simpler to maintain encryption related information in a separate encrypt-middleware, such as

<key-string, encryption-alg, IV, ..>

But this may mean one more entity to duplicate and ensure availabilty.

3.      Where do you use salt?


From: Oleg Gelbukh [mailto:ogelbukh at mirantis.com]
Sent: Wednesday, December 12, 2012 5:51 AM
To: OpenStack Development Mailing List; Bhandaru, Malini K
Subject: Re: [openstack-dev] Encrypted Objects in Swift

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<mailto: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.

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.

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.


From: Oleg Gelbukh [mailto:ogelbukh at mirantis.com<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


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?


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

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/20121213/a74b91eb/attachment.html>

More information about the OpenStack-dev mailing list