gdp / doc / gdp-encryption.html @ master
History | View | Annotate | Download (6.29 KB)
1 | e74a5b2b | Eric Allman | <!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 | 5714b5e3 | Eric Allman | <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 | e74a5b2b | Eric Allman | (need not be the same set of readers)</li>
|
102 | 5714b5e3 | Eric Allman | <li>Encrypt old key K with new key K′<br> |
103 | e74a5b2b | Eric Allman | </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 | 5714b5e3 | Eric Allman | <li>Start using K′ as K</li> |
107 | e74a5b2b | Eric Allman | </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 | 5714b5e3 | Eric Allman | points prior. This could be mitigated by not including E<sup>K′</sup>(K) |
130 | e74a5b2b | Eric Allman | 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> |