-
Notifications
You must be signed in to change notification settings - Fork 30
/
Lecture02.tex
239 lines (200 loc) · 10 KB
/
Lecture02.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
%!TEX root = InfoSec.tex
% Lecture 2: 19 September 2012
\sektion{2}{Randomness}
Best way to get a value that is unknown to an adversary is to choose a random
value, but it's hard to get this in practice. Randomness (or a lack thereof) is often a weakness in a security system.\\
Recall from last lecture that a PRF works as a MAC.
\sidenote{
{\bf What is a PRF?}\\
Two views:
\begin{enumerate}
\item family of functions $f_k(x)$
\item function $f(k,x)$. This is the view we'll be using for this class.
\end{enumerate}
}
{\bf True randomness}:
\begin{itemize}
\item outcome of some inherently random process
\item assume it ``exists'' but it's scarce and hard to get
\end{itemize}
{\bf In security, "random" means unpredictable}:
\begin{itemize}
\item to whom? E.x., in a PRF, the result can be considered random with respect to someone who does not know the secret key.
\item when?
\end{itemize}
{\bf Pseudorandom generator (PRG)}:
\begin{itemize}
\item takes a small ``seed'' that's truly random as input E.x. a few coin flips, instead of flipping a coin each time
\item generates a long sequence of ``good enough'' values, i.e. unlimited pseudorandomness.
\item maintains ``hidden state'' that changes as generator operates
\item output is indistinguishable from truly random output in the practical sense, i.e. an efficient party can not distinguishs
\item the generator needs to be deterministic, because if it is not it must be driven by some kind of randomness, and the reason we are doing this is because randomness is scarce
\end{itemize}
{\bf Randomness service}:
\begin{itemize}
\item OS service, callable by application
\end{itemize}
\begin{definition}
PRG is {\bf secure} if its output is indistinguishable from a truly random
value/string.\\ This is based on the game versus Mallory (can Mallory
tell real randomness from prg? similar to prf game from lecture 1),
where secure means that Mallory wins 50\% ($+\epsilon$) assuming
Mallory has limited resources, where $\epsilon$ is negligible.
\end{definition}
\begin{tabular}{cccccccc}
&&&&&&& \\
Seed & $\xrightarrow{init}$ & $ S_0 $ & $\xrightarrow{advance}$ & $ S_1$ & $\xrightarrow{advance}$ & $S_2$ & etc.\\
& & $\downarrow$ & & $\downarrow$ & & $\downarrow$ &\\
& & $output_0$ & & $output_1$ & & $output_2$ &\\
&&&&&&&
\end{tabular}
Another desirable property is {\bf Forward Secrecy} (backtracking resistance):\\
If Mallory compromises the hidden state of the generator at time $t$, Mallory
can't backtrack to reconstruct past outputs of the generator.\\
Note that if an adversary breaks in at time $t$, they \textit{can} play it forward and see the outputs at time $t + x$
Most PRGs are made up of an \textbf{init} function to initialize state
$S$ and an \textbf{advance} function to step to a new state.
\begin{example}{A PRG that is \underline{not} FS but is secure:}
\begin{itemize}
\item Let $f$ be a PRF
\item init: $(seed, 0)$
\item advance: $(seed, k) \rightarrow (seed, k + 1)$
\item output: $f(seed, k)$
\end{itemize}
If Mallory knows the counter $k$ at any point, she can decrement it and run the function forwards again.
\end{example}
\begin{example}{A PRG that is FS and secure:}
\begin{itemize}
\item Let $f$ be a PRF
\item init: $seed$
\item advance: $S \rightarrow f(S, 0)$
\item output: $f(S, 1)$
\end{itemize}
This resists backtracking because the advance function relies on the PRF, and the seed is overwritten
NOTE: The advance function should be performed after generating an output, and not the other way around. If you do not advance after generating the output, the hidden state that was used to generate the most recent output stays in memory. If at any time between this and the next time you generate a new output the adversary is able to compromise your system, they would learn the hidden state and are able to reconstruct the last output (not backtracking resistant!).
\end{example}
\subsektion{Randomness as a system service}
Hard parts: getting seed, recovering from compromise, even if we don't know whether the state has been compromised. We want to be continuously recovering because we might not notice a compromise.\\
Create a new function, $recover(S, random data) \rightarrow state$\\
Getting a good seed: want true randomness
\begin{itemize}
\item special circuit
\item ambient audio/video: lava lamps! (lavarand)
\end{itemize}
problems: physical random processes are difficult in practice, not \emph{truly} random (correlations)\\
Alternate view: \textbf{collect} data unpredictable to adversary
\begin{itemize}
\item exact history of key presses
\item exact path of mouse
\item exact history of packet traffic
\item periodic screenshot
\item internal temperature
\item ambient audio
\end{itemize}
Then: process to \textbf{extract}, or distill down to ``pure''
randomness - feed it all into a PRF. If there's enough randomness in
input, output will be ``pure random''. Can, for example, use
SHA256(all the data). SHA256 consumes data one block at a time, so we don't
need to collect and store all the data; we can get/use the data iteratively.\\
Use this to:
\begin{itemize}
\item seed the system PRG
\item recover/renew the state (mix fresh randomness in with hidden state) using PRF,
to re-establish secrecy of hidden state\\
NOTE: Mistake to add a single bit at a time since Mallory can keep
up with 2 possibilities at a time, but if we wait until have a
lot, say 256 bits of randomness, then Mallory can't keep up ($2^{256}$
possibilities), even if she knows the algorithm used.
\end{itemize}
Hard to estimate actual amount of entropy in pool, so wait for too
much randomness before mixing to remain conservative.\\
There's also a problem with ``headless'' machines, like servers, that don't have
enough areas of randomness to draw from.
{\bf Linux}:
\begin{itemize}
\item {\tt /dev/random} gives pure random bits, but have to wait
\item {\tt /dev/urandom} is output of PRG, renewed via ``pure'' randomness
\end{itemize}
The boot problem: At startup,
\begin{itemize}
\item least access to randomness (system is clean)
\item highest demand for randomness (programs want keys)
\end{itemize}
Solutions (with their problems):
\begin{itemize}
\item save some randomness only accessible at boot:\\
hard to tell that this hasn't been observed, or used on last boot
\item connect to someone across network to give pseudorandomness:\\
want secure connection but don't yet have key (okay if have just enough
for that key, or semi-predictable and hope Mallory doesn't guess)
\end{itemize}
\subsektion{Message Confidentiality}
Now may have a (passive) adversary/eavesdropper Eve who can only listen:\\
\makebox[5cm]{\ovalbox{Alice} $\rightarrow$ \ovalbox{Bob}}\\
\makebox[5cm]{$\downarrow$}\\
\makebox[5cm]{\ovalbox{Eve}}\\
Message processing:\\
\makebox[1.5cm]{$\xrightarrow{\text{plaintext}}$}
\framebox[2.5cm]{$E$ (encrypts)}
\makebox[1.5cm]{$\xrightarrow{\text{ciphertext}}$}
\framebox[2.5cm]{$D$ (decrypts)}
\makebox[1.5cm]{$\xrightarrow{\text{plaintext}}$}\\
\makebox[1.5cm]{}\makebox[2.5cm]{$\uparrow$}
\makebox[1.5cm]{}\makebox[2.5cm]{$\uparrow$}\\
\makebox[1.5cm]{}\makebox[2.5cm]{key $k$}
\makebox[1.5cm]{}\makebox[2.5cm]{key $k$}\\
Goal: ciphertext does not convey anything about plaintext. Bob can recover text, Eve cannot.
\textbf{Semantic Security}
\sidenote{
{\bf ``Encryption game'' against Eve:}\\\\
\hspace*{0.5cm} Allow Eve to pick piece of plaintext, we provide encryption $E_k(x_i)$ until she is satisified
\hspace*{0.5 cm} Eve chooses two pieces of plaintext\\
\hspace*{0.5cm} We flip a coin and encrypt one of them\\
\hspace*{0.5cm} Eve guesses which was encrypted: wins if right
We say that the encrpytion method is secure if Eve can't do
better than random guessing (50/50) + negligible $\epsilon$. This is known as
\textbf{semantic security}.\\
Note: if we were being more rigorous in our definitions, we would use a
stronger definition of security for encryption here so that it's easier to
combine later with integrity. However, the methods we are learning are
secure by any of the definitions.
}
{\bf First approach: one-time pad (known to be semantically secure)}
\begin{enumerate}
\item Alice and Bob jointly generate a long random string $k$ (``the pad'')
\item $E(k, x) = k \xor x$
\item $D(k, y) = k \xor y = k \xor (k \xor x) = (k \xor k) \xor x = x$
\end{enumerate}
Problems:
\begin{enumerate}
\item can't reuse key:\\
$(k \xor a) \xor (k \xor b) = a \xor b$\\
worst case, Eve knows one message, but even knowing that the messages
are say English text can give Eve information from character
distributions
\item need really long key -- needs to be as long as sum of message lengths
\end{enumerate}
Idea: use a PRG to ``stretch'' a small key (called a ``stream cipher'')
\begin{itemize}
\item Start with fixed-size random $k$, add a ``nonce'': unique, i.e. don't resue nonce value,
but not secret. Use PRF(k, nonce) to seed a PRG.
\item Alice and Bob run identical PRGs in parallel with same key
\item xor messages with PRG's output
\item Do not re-use (key, nonce) pair
\end{itemize}
This approach still does not provide integrity.
\subsektion{Confidentiality and integrity}
Few approaches.
\begin{enumerate}
\item Use E(x $||$ M(x)) \hspace{1cm}SSL/TLS
\item Use E(x) $||$ M(E(x)) \hspace{1cm}IPSec **This is the winner (because math).
\item Use E(x) $||$ M(x) \hspace{1cm}SSH\\
\end{enumerate}
\begin{theorem}
If E is a semantically secure cipher, and M is a secure MAC, then \#2 is secure.
\end{theorem}
Encrypt plaintext, then append MAC: Bob first integrity checks, then decrypts.
Note that we need to use separate keys for confidentiality and integrity, and a
separate set of two keys for reverse channel (Bob to Alice).\\
If we have only one shared key, we seed the PRG with the shared key and then use
four values it produces for the message sending.