Open Stack

Hello Robert!

Oleg's (Mirantis) patch to Swift would support encryption. But we still need a key manager to hold keys and
Work is afoot on building one.  There was a presentation from a Korean company whose customers wanted object encryption and I believe they are using Mirantis's solution.

Regards
Malini 

-----Original Message-----
From: Clark, Robert Graham [mailto:robert.clark at hp.com] 
Sent: Wednesday, April 24, 2013 2:24 PM
To: OpenStack List; Oleg Gelbukh
Subject: Re: [openstack-dev] Encrypted Objects in Swift

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>://<htt
>p:/ 
>/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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev