Open Stack

Hello Nate and Caitlin!

I do not know enough about the other block encryption algorithms, just AES-XTS (and assuming other XTS variants) and wondering if a light weight clone is possible for block storage (note: not concerned about object storage, image storage etc) and am concerned at the physical layer.

My question stems from an early message from Nate(Th 2/14/2013)  excerpted below:
One item we have yet to tackle is cloning.  I think there are a few options for this.

1) Don't support clone operations for encrypted volumes.  This is easy to implement and prevents key reuse, but it limits functionality.
2) Support clone with same key.  This should be easy to implement as well.  We could use the metadata key-id and set it to the same value for the clone.  The drawback to this is that the key has multiple uses, and it could be used to decrypt many different volumes.  I don't like the idea of that.  If the key is compromised then what do you do?
3) Support clone with different key.  You could do this by decrypting the bytes from the original volume and encrypting them with a new key.  If we are going to support cloning then I think I like this approach the best.  The drawback on this is time.

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?

A design criteria behind block encryption is that the same data stored in different sectors looks different.

Regards
Malini

From: Caitlin Bestler [mailto:caitlin.bestler at nexenta.com]
Sent: Tuesday, March 26, 2013 4:39 PM
To: Nate Reller; OpenStack Development Mailing List
Subject: Re: [openstack-dev] encrypted volume snapshot question

On 3/26/2013 2:55 PM, Nate Reller wrote:
I do not think decryption and re-encryption will be necessary. I will do my
best to describe why via email.

The image file is used to setup a loop device, which looks like a normal block
device. The loop device size is limited to the size of the file backing the
loop device. It maps its idea of sectors to locations in the file backing the
device. Hence sector 0 will be bytes (0, 511) in the file backing the device.
Where those bytes are on the physical disk are unknown.

Normal block device functions are used to read and write data from a loop
device.  Hence in Linux this will be a request call. This will tell the block
device where to write the data. For example a call could be made to write data
to the first sector. The first sector is relative to the loop device and not
the physical device.  Therefore data written to the first sector of the loop
device will be to the first 512 bytes of the file backing the loop device.

Now when dm-crypt is used I believe it is setup as another block device that
sits above the block device to be encrypted. It will simply encrypt the data
before it is sends the request call down to the lower level driver. Consider
the example write above again. Now the dm-crypt block device will receive a
request to write to the first sector. It will encrypt the data using the sector
number as the IV, and then call the lower block device using the same
parameters (i.e. send this data to the first sector). The bytes will then be
written to the first sector of the loop device, which is the first 512 bytes of
the file backing the device, and who knows where on the physical device.

Since the physical sector is not used in the encryption then I do not see why
the disk would need to be decrypted and then re-encrypted. You could test this
by creating a file backed loop device, putting dm-crypt on top, writing data to
it, unmounting it all, copying the file, putting dm-crypt on top, and reading
the data from it.

Just ignore all issues with the local OS. I have an encrypted entity (volume,
swift partition, object, whatever) on server X that I want to replicate to
server Y.

If I replicate the encrypted content, I need to transfer the decrypting key
to server Y (unless we are working with user-held keys, which is a wonderful
idea, but would be a totally separate blueprint and project). How do I do that
safely? This is where I see a key manager as playing a useful role. It lets
Server X know that it is ok for it transfer key Z to server Y, and provides
either a Session Key or the Public Key of Server Y to facilitate this transfer.

If I don't transfer the key, then I need to transfer the content in a form where
Server Y can re-encrypt it. That would require decrypting it, and then encrypting
it for transport so that Server Y could decrypt it from transport before re-encrypting
it for storage.

All of that is true no matter what involvement any kernel has in the whole process.

These factors also drive your key granularity. If I am only replicating part of a physical
drive I do not want to transfer the key for the entire drive to the receiving server.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130327/d6b15b2a/attachment.html>