<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2/14/2013 8:23 AM, Nate Reller
wrote:<br>
</div>
<blockquote
cite="mid:1360859015.12943.YahooMailNeo@web163804.mail.gq1.yahoo.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div style="color:#000; background-color:#fff; font-family:times
new roman, new york, times, serif;font-size:12pt">
<div><span>Malini, I was happy to learn about a key manager
discussion at the summit. Do you know what track this would
be under? I can't decide if this should be in Keystone or
maybe a whole new service. I like the idea of a whole new
service myself because I think it helps to have the
separation and prevent bloating of functionality for
components. On the other hand, I probably don't want a
dozen services.</span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><br>
<span></span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><span>I like the idea of the
key-id. I think we may end up using that idea. This will
help us to support snapshot operations.</span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><br>
<span></span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><span>One item we have yet
to tackle is cloning. I think there are a few options for
this.</span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><br>
<span></span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><span>1) Don't support clone
operations for encrypted volumes. This is easy to implement
and prevents key reuse, but it limits functionality.<br>
</span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><span>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?</span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><span>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.</span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><br>
<span></span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><span>There are similar
issues for snapshots, but I am not as opposed to option 2
for snapshots. Any thoughts on this?</span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><br>
<span></span></div>
<div style="color: rgb(0, 0, 0); font-size: 16px; font-family:
times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><span>-Nate<br>
</span></div>
<div><br>
</div>
<div style="font-family: times new roman, new york, times,
serif; font-size: 12pt;">
<div style="font-family: times new roman, new york, times,
serif; font-size: 12pt;">
<div dir="ltr"> <font face="Arial" size="2">
<hr size="1"></font><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Great outline, it zeroes in on the most critical issue.<br>
<br>
Nexenta favors option 2, which shouldn't be surprising since we
on-the-fly snapshotting and cloning<br>
is one of the key strengths of ZFS.<br>
<br>
When you have to decrypt and re-encrypt a volume the process is no
longer a "snapshot", but something<br>
that resembled Civil War era photography.<br>
<br>
However, I do not see Keystone as being a key repository that is up
to supporting distributed keys.<br>
Any would-be attacker would immediately target the encryption of
communicating with keystone<br>
as being a far more vulnerable target than the encryption used on
the volumes themselves.<br>
<br>
I believe what we need is to allow the encryption keys to be stored
by the storage servers themselves<br>
in secure lock boxes, and the role of OpenStack should be to
authorize secure transfers between those<br>
lockboxes (which could be encrypted by far more than SSL).<br>
<br>
<br>
</body>
</html>