<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hello Nate and Caitlin!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">My question stems from an early message from Nate(Th 2/14/2013) excerpted below:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">One item we have yet to tackle is cloning. I think there are a few options for this.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">1) Don't support clone operations for encrypted volumes. This is easy to implement and prevents key reuse, but it limits functionality.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">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?<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The above is ideal for de-duplication efforts.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">But would it introduce a security vulnerability?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">A design criteria behind block encryption is that the same data stored in different sectors looks different.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Malini<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Caitlin Bestler [mailto:caitlin.bestler@nexenta.com]
<br>
<b>Sent:</b> Tuesday, March 26, 2013 4:39 PM<br>
<b>To:</b> Nate Reller; OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] encrypted volume snapshot question<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 3/26/2013 2:55 PM, Nate Reller wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt;background:white">I do not think decryption and re-encryption will be necessary. I will do my<br>
best to describe why via email.<br>
<br>
The image file is used to setup a loop device, which looks like a normal block<br>
device. The loop device size is limited to the size of the file backing the<br>
loop device. It maps its idea of sectors to locations in the file backing the<br>
device. Hence sector 0 will be bytes (0, 511) in the file backing the device.<br>
Where those bytes are on the physical disk are unknown.<br>
<br>
Normal block device functions are used to read and write data from a loop <br>
device. Hence in Linux this will be a request call. This will tell the block<br>
device where to write the data. For example a call could be made to write data <br>
to the first sector. The first sector is relative to the loop device and not<br>
the physical device. Therefore data written to the first sector of the loop <br>
device will be to the first 512 bytes of the file backing the loop device.<br>
<br>
Now when dm-crypt is used I believe it is setup as another block device that <br>
sits above the block device to be encrypted. It will simply encrypt the data <br>
before it is sends the request call down to the lower level driver. Consider<br>
the example write above again. Now the dm-crypt block device will receive a<br>
request to write to the first sector. It will encrypt the data using the sector<br>
number as the IV, and then call the lower block device using the same <br>
parameters (i.e. send this data to the first sector). The bytes will then be<br>
written to the first sector of the loop device, which is the first 512 bytes of<br>
the file backing the device, and who knows where on the physical device.<br>
<br>
Since the physical sector is not used in the encryption then I do not see why<br>
the disk would need to be decrypted and then re-encrypted. You could test this <br>
by creating a file backed loop device, putting dm-crypt on top, writing data to<br>
it, unmounting it all, copying the file, putting dm-crypt on top, and reading<br>
the data from it.<o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
Just ignore all issues with the local OS. I have an encrypted entity (volume,<br>
swift partition, object, whatever) on server X that I want to replicate to<br>
server Y.<br>
<br>
If I replicate the encrypted content, I need to transfer the decrypting key<br>
to server Y (unless we are working with user-held keys, which is a wonderful<br>
idea, but would be a totally separate blueprint and project). How do I do that<br>
safely? This is where I see a key manager as playing a useful role. It lets<br>
Server X know that it is ok for it transfer key Z to server Y, and provides<br>
either a Session Key or the Public Key of Server Y to facilitate this transfer.<br>
<br>
If I don't transfer the key, then I need to transfer the content in a form where<br>
Server Y can re-encrypt it. That would require decrypting it, and then encrypting<br>
it for transport so that Server Y could decrypt it from transport before re-encrypting<br>
it for storage.<br>
<br>
All of that is true no matter what involvement any kernel has in the whole process.<br>
<br>
These factors also drive your key granularity. If I am only replicating part of a physical<br>
drive I do not want to transfer the key for the entire drive to the receiving server.<o:p></o:p></p>
</div>
</body>
</html>