gdp / doc / gdp-encryption.html @ master
History | View | Annotate | Download (6.29 KB)
| 1 |
<!DOCTYPE html>
|
|---|---|
| 2 |
<html>
|
| 3 |
<head>
|
| 4 |
<meta content="text/html; charset=utf-8" http-equiv="content-type"> |
| 5 |
<title>Encryption in the Global Data Plane</title> |
| 6 |
<meta content="Eric Allman" name="author"> |
| 7 |
</head>
|
| 8 |
<body>
|
| 9 |
<p> </p> |
| 10 |
<h1>Encryption in the Global Data Plane</h1> |
| 11 |
<p>Eric Allman, Swarm Lab, U.C. Berkeley</p> |
| 12 |
<p><br> |
| 13 |
</p>
|
| 14 |
<p>This is a working document, more musing and request for comment than
|
| 15 |
tutorial. Nothing herein is definitive.</p> |
| 16 |
<p><br> |
| 17 |
</p>
|
| 18 |
<h2>Issues</h2> |
| 19 |
Need reasonable efficiency. Implies not doing public key operations on
|
| 20 |
a per-record basis, which in turn means using symmetric keys across multiple |
| 21 |
records.<br>
|
| 22 |
<br>
|
| 23 |
Need to handle revocation.<br>
|
| 24 |
<br>
|
| 25 |
How to retroactively grant permission? This is the flip side of
|
| 26 |
revocation: you want a new reader to be able to read data already |
| 27 |
written. Simple if you share the secret keys around, harder if you do
|
| 28 |
not.<br>
|
| 29 |
<br>
|
| 30 |
Two major options: might have key pairs associated with readers, and the |
| 31 |
writer grants permission to specific readers, versus sharing the secret key |
| 32 |
with all readers. Either way there are key management issues, but they
|
| 33 |
are different. This discussion attempts to discuss both options.<br> |
| 34 |
<br>
|
| 35 |
<h2>Operations</h2> |
| 36 |
Assumption: most of the Writing and Reading operations are amenable to |
| 37 |
caching. These algorithm overviews do not include caching to keep
|
| 38 |
things simple.<br>
|
| 39 |
<p>Nomenclature:<br> |
| 40 |
</p>
|
| 41 |
<ul>
|
| 42 |
<li>K = symmetric key</li> |
| 43 |
<li>P = public key</li> |
| 44 |
<li>S = secret key</li> |
| 45 |
<li>E<sup>K</sup>(m), D<sup>K</sup>(m) = encrypt or decrypt m using key K |
| 46 |
(also applies to P and S; E<sup>K</sup> ≡ D<sup>K</sup> for |
| 47 |
symmetric keys K)</li>
|
| 48 |
<li>L = a log</li> |
| 49 |
<li>G<sub>L</sub> = corresponding generational log (to store key |
| 50 |
information)<br>
|
| 51 |
</li>
|
| 52 |
<li>G<sub>L:g</sub> = information corresponding to generation g<br> |
| 53 |
</li>
|
| 54 |
</ul>
|
| 55 |
<h3>Creating a Log L<br> |
| 56 |
</h3>
|
| 57 |
<ol>
|
| 58 |
<li>Create a (symmetric) key K</li> |
| 59 |
<li>Create a key pair (S<sub>r1</sub>, P<sub>r1</sub>) [only if sharing |
| 60 |
secret key]<br>
|
| 61 |
</li>
|
| 62 |
<li>Encrypt K with P<sub>i</sub>, i ∈ { self, r<sub>1</sub>, r<sub>2</sub> |
| 63 |
...}, self is your own key, and r<sub>i</sub> are readers [only one if |
| 64 |
sharing secret key]<br>
|
| 65 |
</li>
|
| 66 |
<li>Create Generational Log G<sub>L</sub> unique to this log L<br> |
| 67 |
</li>
|
| 68 |
<li>Write E<sup>P<sub>i</sub></sup>(K) ∀i to G<sub>L</sub> (this is |
| 69 |
generation G<sub>L:1</sub>)<br> |
| 70 |
</li>
|
| 71 |
</ol>
|
| 72 |
<h3>Writing</h3> |
| 73 |
<ol>
|
| 74 |
<li>Writer reads G<sub>L:g</sub> from G<sub>L</sub>, where G<sub>L:g</sub> |
| 75 |
is the last entry in G<sub>L</sub></li> |
| 76 |
<li>Use S<sub>self</sub> to decrypt K from G<sub>L:g</sub></li> |
| 77 |
<li>Use K to encrypt data</li> |
| 78 |
<li>Prepend generation number g (unencrypted) before writing encrypted
|
| 79 |
data E<sub>K</sub>(m)<br> |
| 80 |
</li>
|
| 81 |
</ol>
|
| 82 |
<h3>Reading (Normal Case)<br> |
| 83 |
</h3>
|
| 84 |
<ol>
|
| 85 |
<li>Reader reads datum X and extracts generation number g<br> |
| 86 |
</li>
|
| 87 |
<li>Look up G<sub>L:g</sub> from G<sub>L</sub></li> |
| 88 |
<li>See if we have a secret key S<sub>rN</sub> that will decrypt one of |
| 89 |
the encrypted copies of K; if not, fail (but see Problem Case below)<br>
|
| 90 |
</li>
|
| 91 |
<li>Decrypt remainder of datum with K<br> |
| 92 |
</li>
|
| 93 |
</ol>
|
| 94 |
<h3>Revocation</h3> |
| 95 |
<p>Revocation looks very similar to creation.</p> |
| 96 |
<ol>
|
| 97 |
<li>Create new symmetric key K′</li> |
| 98 |
<li>Create new key pair (S′<sub>r1</sub>, P′<sub>r1</sub>) |
| 99 |
[only if sharing secret key]</li>
|
| 100 |
<li>Encrypt K′ with P<sub>self</sub>, P<sub>r1</sub>, P<sub>r2</sub>... |
| 101 |
(need not be the same set of readers)</li>
|
| 102 |
<li>Encrypt old key K with new key K′<br> |
| 103 |
</li>
|
| 104 |
<li>Write encrypted K and E<sup>P<sub>i</sub></sup>(K) ∀i to G<sub>L</sub> |
| 105 |
(this creates a new generation)<sub></sub></li> |
| 106 |
<li>Start using K′ as K</li> |
| 107 |
</ol>
|
| 108 |
<h3>Reading (Problem Case)</h3> |
| 109 |
<p>This could be because you have no access, or you do but you have to read
|
| 110 |
backwards through generations to find the K you need for the record.<br>
|
| 111 |
</p>
|
| 112 |
<ol>
|
| 113 |
<li>Reader reads datum and extracts g from datum, reads G<sub>L,g</sub> |
| 114 |
from G<sub>L</sub>, but does not have a valid secret key to decrypt it<br> |
| 115 |
</li>
|
| 116 |
<li>Read G<sub>L,n</sub> from G<sub>L</sub> where n is the most recent |
| 117 |
generation</li>
|
| 118 |
<li>If no access to that generation, give up (means your access has been
|
| 119 |
denied)<br>
|
| 120 |
</li>
|
| 121 |
<li>Use that access to decrypt K</li> |
| 122 |
<li>For k ∈ {n–1, n–2, ... i}, use K<sub>k+1</sub> to |
| 123 |
decrypt K<sub>k</sub></li> |
| 124 |
<li>Stop when you find a valid S</li> |
| 125 |
</ol>
|
| 126 |
<br>
|
| 127 |
<h2>Security Analysis/Discussion/Questions</h2> |
| 128 |
<p>Once a reader has access to any point in the log, they have access to all
|
| 129 |
points prior. This could be mitigated by not including E<sup>K′</sup>(K) |
| 130 |
in new G<sub>L</sub> records, but then granting backward access would be |
| 131 |
hard.<br>
|
| 132 |
</p>
|
| 133 |
<p>If each reader had its own key pair, then this looks like an ACL. |
| 134 |
"Reader" here could mean "application", "user", "administrative domain", |
| 135 |
or something else. Alternatively, each log could have its own key
|
| 136 |
pair, which would mean that somehow that secret key S<sub>L</sub> has to |
| 137 |
be distributed to all possible readers, and revocation becomes a matter of |
| 138 |
changing S<sub>L</sub> as well as K. The encryption key pair should |
| 139 |
probably <i>not</i> be the same one used for signing.<br> |
| 140 |
</p>
|
| 141 |
<p>This description ignores the step of signing the updates to G<sub>L</sub>. |
| 142 |
Clearly G<sub>L</sub> will need a key pair of its own, and it's not clear |
| 143 |
if that might be shared with the original log L.<br>
|
| 144 |
</p>
|
| 145 |
<p>If secret keys are are being created per log and distributed around, they
|
| 146 |
need to be encrypted themselves; at some point there has to be a |
| 147 |
decryption key <i>not</i> held on disk in encrypted form or the game is |
| 148 |
over. Q: could TPM help us here?<br> |
| 149 |
</p>
|
| 150 |
</body>
|
| 151 |
</html>
|