Project

General

Profile

Statistics
| Branch: | Tag: | Revision:

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.&nbsp; Nothing herein is definitive.</p>
16 
    <p><br>
17 
    </p>
18 
    <h2>Issues</h2>
19 
    Need reasonable efficiency.&nbsp; 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?&nbsp; This is the flip side of
26 
    revocation: you want a new reader to be able to read data already
27 
    written.&nbsp; 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.&nbsp; Either way there are key management issues, but they
33 
    are different.&nbsp; 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.&nbsp; 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> &equiv; 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 &isin; { 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) &forall;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&prime;</li>
98 
      <li>Create new key pair (S&prime;<sub>r1</sub>, P&prime;<sub>r1</sub>)
99 
        [only if sharing secret key]</li>
100 
      <li>Encrypt K&prime; 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&prime;<br>
103 e74a5b2b Eric Allman 
      </li>
104 
      <li>Write encrypted K and E<sup>P<sub>i</sub></sup>(K) &forall;i to G<sub>L</sub>
105 
        (this creates a new generation)<sub></sub></li>
106 5714b5e3 Eric Allman 
      <li>Start using K&prime; 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 &isin; {n&ndash;1, n&ndash;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.&nbsp; This could be mitigated by not including E<sup>K&prime;</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.&nbsp;
134 
      "Reader" here could mean "application", "user", "administrative domain",
135 
      or something else.&nbsp; 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.&nbsp; 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>.&nbsp;
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.&nbsp; Q: could TPM help us here?<br>
149 
    </p>
150 
  </body>
151 
</html>