Open Stack

>> 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