Open Stack

Hello,

Object encryption proposal was discussed during Havana Summit as a feature
wanted by some deployers (esp. enterprises). Current status of
implementation is too early to consider inclusion in Swift core code.
Another thing that needs to be defined is key management system and API. We
have a roadmap ahead, inspired by Malini's specification and our own design
and QA efforts. Now we're assembling team to continue development.

--
Best regards,
Oleg Gelbukh


On Thu, Apr 25, 2013 at 1:24 AM, Clark, Robert Graham
<robert.clark at hp.com>wrote:

> Did the object encryption proposal (1.) ever move forward?
>
> On 08/02/2013 00:19, "Bhandaru, Malini K" <malini.k.bhandaru at intel.com>
> wrote:
>
> >Greetings Robert!
> >
> >I did not notice your post for a whole week! Glad you joined the
> >discussion chain.
> >
> >Since this message ..
> >1)  Mirantis brought out their prototype object encryption routine
> >2)  JHU-APL folks brought out their volume encryption support
> >3)  My focus has shifted to key management .. (will copy you on any
> >blueprints)
> >
> >*** I like your use case example of may be a tenant's data being seized
> >and by separate object encryption, the data from other tenants is not
> >exposed.
> >
> >Certainly the server has access to keys, so the protection is from stolen
> >disks. The keys will certainly be kept elsewhere and further encrypted
> >with a master key.
> >
> >You are correct, changing salt or for that matter any cipher block
> >chaining encryption will impact synchronization cost via rsync cost.
> >
> >Regards
> >Malini
> >
> >-----Original Message-----
> >From: Clark, Robert Graham [mailto:robert.clark at hp.com]
> >Sent: Tuesday, January 29, 2013 4:43 AM
> >To: OpenStack List; Oleg Gelbukh
> >Subject: Re: [openstack-dev] Encrypted Objects in Swift
> >
> >I can't speak to the original set of questions but I'd like to get
> >involved in this discussion so here's a few of my thoughts.
> >
> >I don't think it would matter either way. If the object changes by 1 bit
> >then the whole encrypted object would change, the impact on
> >replication/updates in an encrypted Swift is pretty high. Similarly
> >salting encrypted objects makes very little sense, salting is a useful
> >way to mitigate pre-computation attacks such as rainbow tables. These
> >aren't really applicable to object store.
> >
> >I'm interested as to what requirements Swift encryption really meets.
> >Certainly it doesn't make you trust your cloud provider any more, they
> >after all handle the keys for your objects so can decrypt/inspect at any
> >time. Swift object encryption would protect against data breaches through
> >physical disk theft or loss (so long as the disk/chassis/rack with the
> >keys on it wasn't also stolen) but of course you could just use full
> >disk-encryption to the same end, with stock Swift.
> >
> >There are possibilities for multi-tenant clouds where disks may be seized
> >by various agencies. In those situations keys for a specific tenant could
> >be released and the data of the other tenants on any seized hardware
> >would be protected.
> >
> >From: "Bhandaru, Malini K"
> ><malini.k.bhandaru at intel.com<mailto:malini.k.bhandaru at intel.com>>
> >Reply-To: OpenStack List
> ><openstack-dev at lists.openstack.org<mailto:
> openstack-dev at lists.openstack.or
> >g>>
> >Date: Thu, 13 Dec 2012 03:12:28 +0000
> >To: Oleg Gelbukh <ogelbukh at mirantis.com<mailto:ogelbukh at mirantis.com>>,
> >OpenStack List
> ><openstack-dev at lists.openstack.org<mailto:
> openstack-dev at lists.openstack.or
> >g>>
> >Subject: Re: [openstack-dev] Encrypted Objects in Swift
> >
> >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?
> >
> >Malini
> >
> >
> >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.
> >
> http://www.intel.com/content/www/us/en/communications/communications-ia-mu
> >lti-buffer-paper.html
> >
> http://www.intel.com/content/www/us/en/communications/communications-ia-cr
> >yptographic-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/de
> >sign/intarch/PAPERS/324310.pdf<
> http://download.intel.com/design/intarch/PA
> >PERS/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<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
> >
> >
> >_______________________________________________
> >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
> >
> >--
> >Best regards,
> >Oleg Gelbukh
> >Sr. IT Engineer
> >Mirantis Inc.
> >_______________________________________________ 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
> >
> >_______________________________________________
> >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/20130425/89c869bf/attachment.html>