Open Stack

If I understand your concern with option 2, it is that cloning will be used as a form of mass distribution, and that therefore
hundreds of volumes will all require access to the same key.

That can be easily addressed by simply forcing re-encryption on at least some cloning operations, especially when cloning
on a peer-to-peer basis between users.

A far more common pattern would be for an IT department or a Service Provider to create volumes/objects would 
be cloned by all users in the company (a clone of the Windows C: drive, or of a specific application). For those deployments,
Efficiency of the cloning operation, and the ability to share a master reference image on a virtualization host as a form of
Deduplication would far outweigh the security concerns.

But if we include an option to clone with new encryption keys the users will be more than capable of determining when
this step is justified.


-----Original Message-----
From: Nate Reller [mailto:rellerreller at yahoo.com] 
Sent: Wednesday, March 27, 2013 8:48 AM
To: Bhandaru, Malini K; OpenStack Development Mailing List; Caitlin Bestler
Subject: Re: [openstack-dev] encrypted volume snapshot question

I think a light weight clone operation like option (2) is possible. I could be wrong, but I feel confident that it should be ok.

However, I feel like option (2) does introduce some security risks. This is why I like option (3).  If we do a clone with the same key then the original and clone will use the same key going forward.  The content of the disks will change over time, but the key used to provide the encryption will be the same.

My concern is that if we use option (2) then there will be many clones using the same key. Consider a user that creates a new encrypted volume. The user then clones the volume and makes it available for other members to use. Each member that uses a cloned volume will have an encrypted drive, but they will all be using the same key. 

If an attacker can find the key then they can read the data for all of the volumes. It also makes administration much slower and more difficult in the instance of a key compromise because now all of the drives must be rekeyed instead of just one. 

> My concern is with option (2) above, given Nate’s description of a 
> logical block device, so the sector numbers would be 0, 1, 2 in the copy and original.
> Say one uses an encryption scheme that builds in a tweak using the 
> sector address, and for argument’s sake we have a single physical 
> device and on that we save the original and a snapshot of the same. 
> Would the physical disk have a string of bits that looks identical 
> (because the sector numbers and hence tweak are the same, and the 
> encryption key is the same). Meta data could look different by making a copy of the key and saving it against a new key-id.
> 
> The above is ideal for de-duplication efforts.
> But would it introduce a security vulnerability?

-Nate