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>