Open Stack

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.org>>
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.org>>
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-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<http://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<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