--- a/handouts/ho05.tex Fri Nov 07 22:13:26 2014 +0000
+++ b/handouts/ho05.tex Sat Nov 08 01:53:08 2014 +0000
@@ -50,10 +50,10 @@
wirelessly transmits them to the ``colleague'' who followed
you. This thief silently enquires what the key fob answers.
This answer is then send back to the thief at the car. If done
-properly the car will dutifully open and possibly start. No
+properly, the car will dutifully open and possibly start. No
need to steal your keys anymore.
That this is an attack one needs to reckon with is
-demonstrated by the fact that certain dodgy
+demonstrated by the fact that dodgy
websites\footnote{\url{http://autokeydevices.com/product/wave/}
\ldots{} funnily this webpage says ``not intended for illegal
use'', but I have a hard time finding any legal purpose for
@@ -70,22 +70,22 @@
\end{figure}
-But there are many more such protocols we like to treat.
+But there are many more such protocols we like to study.
Another example is Wifi---you might sit at a Starbucks and
talk wirelessly to the free access point there and from there
talk to your bank (see The Guardian article cited at the very
-end of this handout). Moreover, even if your have to touch
-your Oyster card at the reader each time you enter or exit the
-Tube, it actually operates wirelessly and with appropriate
-equipment over some quite large distance (several meters). But
-there are many, many more examples (Bitcoins, mobile
-phones,\ldots).
+end of this handout). Moreover, even if you have to touch in
+and out your Oyster card at the reader each time you enter or
+exit the Tube, it actually operates wirelessly and with
+appropriate equipment over some quite large distance (several
+meters). But there are many, many more examples for protocols
+(Bitcoins, Tor, mobile phones,\ldots).
The common characteristics of the protocols we are interested
in is that an adversary or attacker is assumed to be in
complete control over the network or channel over which we
exchanging messages. An attacker can install a packet sniffer
-on a network, inject packets, intercept packets modify
+on a network, inject packets, intercept packets, modify
packets, replay old messages, or fake pretty much everything
else. In this hostile environment, the purpose of a protocol
(that is exchange of messages) is to achieve some security
@@ -149,13 +149,13 @@
\end{equation}
-\noindent The left-hand side specifies who is the sender and
-who is the receiver of the message. On the right of the colon
-is the message that is send. The order from top to down
-specifies in which order the messages are sent. We also
-have the convention that messages, like $SYN$ above, are send
-in clear-text over the network. If we want that a message is
-encrypted, then we use the notation
+\noindent The left-hand side of each clause specifies who is
+the sender and who is the receiver of the message. On the
+right of the colon is the message that is send. The order from
+top to down specifies in which order the messages are sent. We
+also have the convention that messages, like $SYN$ above, are
+send in clear-text over the network. If we want that a message
+is encrypted, then we use the notation
\[
\{msg\}_{K_{AB}}
@@ -271,10 +271,10 @@
$B$ to infer it is talking to $A$. But this is of course too
naive in the context where the message can be observed by
everybody else on the network. Eve, for example, could just
-record this message $A$ just sent, and next time send the same
+record this message $A$ just sent, and next time sends the same
message to $B$. $B$ has no other choice than believing it
talks to $A$. But actually it talks to Eve, who now clears
-out $A$'s back account assuming $B$ had been a bank.
+out $A$'s bank account assuming $B$ had been a bank.
A more sophisticated protocol which tries to avoid the
replay attack is as follows
@@ -529,11 +529,12 @@
The cryptographic ``magic'' of public-private keys
seems to offer an elegant solution for this, but as we shall
see in the next section, this requires some very clever
-protocol design.
+protocol design and does not solve the authentication
+problem completely.
\subsubsection*{Averting Person-in-the-Middle Attacks}
-The idea of public-private key encryption is that one can make
+The idea of public-private key encryption is that one can
publish the key $K^{pub}$ which people can use to encrypt
messages for me and I can use my private key $K^{priv}$ to be
the only one that can decrypt them. While this sounds all
@@ -560,9 +561,9 @@
The problem we want to study closer here is that protocols
based on public-private key encryption are susceptible to
-person-in-the-middle attack. Consider the following protocol
-where $A$ and $B$ attempt to exchange secret messages using
-public-private keys.
+simple person-in-the-middle attacks. Consider the following
+protocol where $A$ and $B$ attempt to exchange secret messages
+using public-private keys.
\begin{itemize}
\item $A$ sends public key to $B$
@@ -606,14 +607,16 @@
\noindent where in steps 6 and 8, $E$ can modify the messages
by including the $E$ in the message. Both messages are
received encrypted with $E$'s public key; therefore it can
-decrypt it and repackage it with new content. $A$ and $B$ have
-no idea that they talking to an attacker. To them all messages
-look legit. Because $E$ can modify messages, it seems very
-difficult to defend against this attack.
+decrypt them and repackage them with new content. $A$ and $B$
+have no idea that they talking to an attacker. To them all
+messages look legit. Because $E$ can modify messages, it seems
+very difficult to defend against this attack.
-But there is a clever trick\ldots{}dare I say some magic.
-Modify the protocol above so that $A$ and $B$ send their
-messages in two halves, like
+But there is a clever trick\ldots{}dare I say some magic which
+makes this attack very difficult to perform on people who know
+each other---but not necessarily have a shared key. Modify the
+protocol above so that $A$ and $B$ send their messages in two
+halves, like
\begin{center}
\begin{tabular}{ll@{\hspace{2mm}}l}
@@ -650,7 +653,7 @@
encrypted with $A$'s public key. The message in step 5. $A$
receives this message, decrypts it and only when the $H_1$
matches with its first half it send out earlier, $A$
-will send out the second half. See step 6. For this $A$
+will send out the second half; see step 6. For this, $A$
adds the received $M_1$ and encrypts both parts with $B$'s
public key. Finally $B$ checks whether the received $M_1$
matches with its first half, and if yes sends $A$ its
@@ -741,7 +744,7 @@
$B$ will be in the possession of $H_1$ and $H'_2$. But
after joining both halves it will not be able to
decrypt the resulting message---the two halves simply
-do not fit. So it can only send out the original $H_2$
+do not fit. It can send out the original $H_2$
as follows:
\begin{center}
@@ -767,13 +770,19 @@
$A$ a message. It could try to build the message
$\{E, m'\}_{K^{pub}_A}$, but like above $A$ would not be able
to make sense out of the two halves (which again do not fit
-together). So the only option is to send $M_2$.
+together). So one option is to send $M_2$.
With this the protocol has ended. $E$ was able to decrypt all
messages, but what messages did $A$ and $B$ receive and from
whom? Do you notice that $A$ and $B$ will find out that
something strange is going on and probably not talk on this
channel anymore? I leave you to think about it.
+\footnote{\rotatebox{180}{
+\begin{minipage}{10cm}
+Consider the case where $A$ sends
+the message ``How is your grandmother?'' to $B$, and $B$
+send the message ``How is the weather in London today'' to $A$.
+\end{minipage}}}
Recall from the beginning that a person-in-the middle
attack can easily be mounted at the key fob and car
@@ -796,7 +805,7 @@
\noindent The assumption is that the key $K$ is only known to
the car and the transponder. The claim is that $C$ and $T$ can
authenticate to each other. Again, I leave it to you to find
-out the magic why this protocol is immune from
+out if this protocol is immune from
person-in-the-middle attacks.
@@ -809,10 +818,11 @@
\url{http://www.cs.ru.nl/~rverdult/Gone_in_360_Seconds_Hijacking_with_Hitag2-USENIX_2012.pdf}
\end{center}
-\noindent is quite amusing to read. Obviously an even more amusing
-paper would be ``Dismantling Megamos Crypto: Wirelessly Lockpicking a
-Vehicle Immobilizer'' by the same authors, but because of the court
-injuction by VW in this case, we are denied this entertainment.
+\noindent is quite amusing to read. Obviously an even more
+amusing paper would be ``Dismantling Megamos Crypto:
+Wirelessly Lockpicking a Vehicle Immobilizer'' by the same
+authors, but because of the court injunction by VW,
+we are denied this entertainment.
Person-in-the-middle-attacks from the ``wild'' are described
with real data in the blog post