encrypted volume snapshot question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

encrypted volume snapshot question

Bhandaru, Malini K

Greetings Nate, Caitlin!

 

With volume snapshots, if a second physical copy is to be made, and an algorithm such as

AES-XTS is used, how can one escape “decryption followed by re-encryption” give than AES-XTS

uses the sector address to generate the tweaks for encrypting each sector.

 

Regards

Malini


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: encrypted volume snapshot question

Nathan Reller
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.

I must point out that I am no Linux kernel guru. I only have a very limited
experience. Let me know if this makes sense or not.

-Nate

> Greetings Nate, Caitlin!
>
> With volume snapshots, if a second physical copy is to be made, and an
> algorithm such as
> AES-XTS is used, how can one escape "decryption followed by re-encryption" give
> than AES-XTS
> uses the sector address to generate the tweaks for encrypting each sector.
>
> Regards
> Malini
_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: encrypted volume snapshot question

Caitlin Bestler
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.


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: encrypted volume snapshot question

Bhandaru, Malini K

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:[hidden email]]
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.


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: encrypted volume snapshot question

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

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: encrypted volume snapshot question

Caitlin Bestler
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:[hidden email]]
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
_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: encrypted volume snapshot question

Bhandaru, Malini K
Adding an argument to clone/snapshot that specifies re-key (true/false)  meets security (when true, no key sharing, no bit pattern on physical device that is common) and de-duplication (when false, bit pattern common, key same, quick) needs.
Regards and thank you!
Malini


-----Original Message-----
From: Caitlin Bestler [mailto:[hidden email]]
Sent: Wednesday, March 27, 2013 9:19 AM
To: Nate Reller; Bhandaru, Malini K; OpenStack Development Mailing List
Subject: RE: [openstack-dev] encrypted volume snapshot question

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:[hidden email]]
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
_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: encrypted volume snapshot question

Nathan Reller
I agree.  I like the user specifying the option as well.

-Nate




----- Original Message -----
From: "Bhandaru, Malini K" <[hidden email]>
To: Caitlin Bestler <[hidden email]>; Nate Reller <[hidden email]>; OpenStack Development Mailing List <[hidden email]>
Cc:
Sent: Wednesday, March 27, 2013 2:11 PM
Subject: RE: [openstack-dev] encrypted volume snapshot question

Adding an argument to clone/snapshot that specifies re-key (true/false)  meets security (when true, no key sharing, no bit pattern on physical device that is common) and de-duplication (when false, bit pattern common, key same, quick) needs.
Regards and thank you!
Malini


-----Original Message-----
From: Caitlin Bestler [mailto:[hidden email]]
Sent: Wednesday, March 27, 2013 9:19 AM
To: Nate Reller; Bhandaru, Malini K; OpenStack Development Mailing List
Subject: RE: [openstack-dev] encrypted volume snapshot question

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:[hidden email]]
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


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev