Open Stack

Great observations Bryan. Thank you!

Bruce Benjamin and self were talking about the blueprint, it is time to figure out the details of a key manager.
Whether it work in conjunction with keystone, be a separate service entity or folded into keystone .. 

Definitely a key per volume is the minimum.  All volume operations would have to be intercepted programmatically with the compute node then
Using its credentials to request from the key-manager on behalf of the VM the corresponding key.
Would individual users using a volume want to protect their data from each other, possibly.
On interception, if we have associated with each account/user encryption algorithm preference, that would enable modify the encryption strategy, if first pass should just be AES_XTS, certainly still allow changing key-length.

 XTS takes a double length key, using the first half to encrypt across the whole volume
And the second half to encrypt the sector address, aka tweak. The beauty of XTS lies in being able to retrieve a sector with
 no dependencies on the data in the other sectors. This makes retrieval speedy.
Assume a sector on the storage device is 512 bytes, each AES block is 16 bytes, then there are 32 aes encrypted blocks within the sector.
Even if we have 512 bytes of a single character, the encrypted data locks different because the aes-block-id (0 -- 31) is used to modify the encryption key further. So there is some chaining but within a sector, preserving inter-sector independence.

I do not know enough about error correction solutions/implementations, if they happen first and then we encrypt, then decrypt would return the ecc data and one could verify tampering. But many times ecc is hardware implemented, and if that data is encrypted, it becomes opaque during the reverse read process ... (curious and will look into it).
To detect tampering, one could associate meta data with each file that captures its hash.

Regards
Malini

-----Original Message-----
From: Bryan D. Payne [mailto:bdpayne at acm.org] 
Sent: Thursday, January 31, 2013 9:15 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Volume Encryption

>> How do you plan to handle IVs?
>
> dm-crypt, which we use to transparently encrypt disks, provides 
> support for a variety of ways to generate initialization vectors 
> (IVs). AES modes of operation supporting robust IVs that are available 
> through Linux include Encrypted Salt-Sector Initialization Vector 
> (ESSIV) - Linux kernel version
> 2.6.10 - and Xor-encrypt-xor Tweaked-codebook Ciphertext Stealing 
> (XTS) - 2.6.24.  (Note the kernel release shown is the initial release 
> for each of
> these.)  XTS is specifically designed for use in volume storage
> applications: it minimizes the storage impact of encryption (no block 
> size
> increase) and addresses some data-dependent security vulnerabilities 
> where the encrypted data could provide hints about how the data could 
> be decrypted.  Liskov, Rivest, and Wagner (LRW) - 2.6.20 - is another 
> possible mode, but it is not considered sufficiently strong (as called 
> out by the developers of the IEEE P1619 standard.)

While I don't really want to turn this into a crypto discussion, I do have a few quick comments here...

If memory serves me right, XTS has some known issues (in particular data integrity issues and reply attacks).  I typically still prefer to use CBC as it is time tested and works nicely if you handle your IV's properly.  Which brings me back to my question from above.

You mentioned that you would let users select the encryption alg and key length.  Would users also be selecting the mode?  Typically, this
*is* what I've seen (e.g., aes-128-cbc).  However, the selection of different modes could require different handling of the IV.  Have you taking this all under consideration with your implementation?  For example, by limiting the available modes and/or ensuring that you are creating / using IVs in a way that works with all modes?

> The implementation would be rolled out in several phases.  The first 
> release would essentially be a proof of concept of the encryption 
> capabilities.  It would have a simple key management capability used 
> for testing the proof-of-concept implementation.  Initial versions 
> will not integrate fully with OpenStack's existing mechanisms for 
> authentication, which may limit their security.

I think that this first step is valuable, but you should be more clear about the security limitations when this implementation is available.

> A later version is planned that would be based on some basic key 
> management capabilities that would be compatible with the Key 
> Management Interoperability Protocol (KMIP).  The plan is to offload 
> the complexity of implementing key management by using a KMIP server 
> that will talk with the virtualization host to provide a secure link 
> that would deliver the proper keys when needed.  The KMIP server would 
> need to rely on Keystone to provide the authorization credentials 
> validating that the correct user is accessing the block storage device 
> and that the correct key is being accessed.

Is there a reference open source KMIP-compliant system that you will be using / suggesting?  What are the specific security gains here over the above, initial implementation?

And when the system is complete, what are the intended security benefits?  My understanding here is that the data would be encrypted on disk and transparently decrypted when used by an instance.  A control plan compromise could potentially reveal the encryption keys.
How are you isolating these concerns?  And, more generally, what are the specific attack(s) you are stopping with this work, and what attacks remain?

>> Are you linking the keys to specific users?  Or is this just a 
>> system-level encryption that has no
>
>> direct linkage to users?
>
> Key management is handled transparently to the user, with keys being 
> associated with only the volume they encrypt (or decrypt).  Keys will 
> be retrieved automatically when a user mounts a volume to which they 
> have access.  In a later version, key management capabilities (e.g. 
> KMIP) may allow keys to be linked to specific users or projects/tenants.

There are some interesting problems that happen if you use the same key for different users.  For example, an adversary could create a volume, put known data in it, and then steal the several disks from the data center (including one with their own data).  Then the encryption key, which was previously internal to the system, could be discovered by the attacker using since she would have the cipher and plaintext in hand.  If this key were to be reused for all of the data, then the other stolen disks would be compromised.

Using separate keys for separate users fixes this issue.  Using separate keys for each volume is even better, I would think.  As it would help to guard against a single key being used over a very long time.  In the end, this would all then require mapping multiple keys back to a single user account and ensuring that only the correct user has access to the keys.  An exchange that could be facilitated through KMIP / keystone, as you suggest.

Overall, this seems like an interesting new feature to me.  Glad to see you guys working on it!

Cheers,
-bryan

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