<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: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;}
@font-face
{font-family:Verdana;
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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
.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 Paul 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 think a Swift like storage backend is good for key management, it really is a dictionary, nothing fancy, with access controls, replication, horizontal
scaling etc. The containers could be “cinder”, “swift”, “ceilometer”, “logs” whatever, to partition the keys and regulate their access.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">This is what I proposed in the original blueprint. I am glad Paul you independently think the same.<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">But I was thinking of a separate instance of a swift storage cluster to avoid the issue<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">of the key and the object ending up on the same device (which Caitlin also pointed out in her response .. “how to steer them away from each other”). But coming
to your point Paul of a swift based storage being complex, this would make it even more complex. The difference here is that<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">the storage for keys would be significantly less than regular swift object storage demands. Key strings and their ids would both be random.<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">Further, to protect the key-strings I was thinking of encrypting the key-strings with the public-key of their “owner” aka service-end-point, that is, Swift/Cinder/Ceilometer
etc. This can get expensive. But with keystone we have PKI and each service end-point has its own public-private key-pairs.<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">Another idea is once the key has been retrieved from the key manager, it can be saved at the service end-point in a lockbox. The lockbox key would be provided
to the service host machine once it has established that it is trust-worthy, using the Trusted-Platform-Module (TPM). Currently OpenStack has support for establishing if compute node hosts are trust worthy. We can extend this to the other hosts. The encryption
keys are then distributed to these end-points. <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">Were we to roll out this feature in phases, phase-1 could use the public-key for encryption, and thus be accessible to only the designated end-point consumer.<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>
<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 [<a href="mailto:caitlin.bestler@nexenta.com">mailto:caitlin.bestler@nexenta.com</a>]
<br>
<b>Sent:</b> Tuesday, February 26, 2013 9:43 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] Volume Encryption<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 2/26/2013 9:00 AM, Paul Sarin-Pollet wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:.5in;margin-bottom:12.0pt;margin-left:0in">
<span style="font-size:9.0pt;font-family:"Verdana","sans-serif"">Hi Malini,<br>
<br>
Do you think that swift could be a good storage backend for a key manager instead of a database ?</span><span style="font-size:9.0pt;font-family:"Verdana","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:9.0pt;font-family:"Verdana","sans-serif""><br>
It could provide the replication principles and a control over key and key owner.<br>
A (big) negative point could be performances... and complexity.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
There are three separate issues here:<br>
<br>
* How the keys are physically stored and indexed.<br>
* How the stored keys are secured.<br>
* How to steer storage away from the same device.<br>
<br>
A database is not necessarily better at providing an id-->value mapping than an object storage system.<br>
As long as the Key ID is suitable for an Object Name (or a file name for that matter) indexing from an<br>
Object Storage (or file) system should perform well. I cannot think of any scenarios where more general<br>
queries that a database might support would make sense. Every retrieval is for a single key.<br>
<br>
If the keys were all placed in a single container, the key needed to decrypt the specific objects could be<br>
an attribute of the Container itself. Special logic would be required to handle this Container metadata,<br>
an important design goal is for this data *not* to be available if someone steals an entire server.<br>
<br>
The bigger issue is how to ensure that Swift objects are not stored on the same physical devices that<br>
Cinder is trying to encrypt. Storing the keys in Swift Objects would make it difficult to use the same<br>
mechanism to support both Swift and Cinder encryption.<br>
<br>
My proposal for per-storage-server lockboxes was presuming that they would be stored in a local<br>
file system, most typically a *small* file system such as the persistent storage in a TPM. However,<br>
the internal sturcture of a specific lockbox would actually be up to the storage server vendor.<br>
<br>
<o:p></o:p></p>
</div>
</body>
</html>