Open Stack

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