# HG changeset patch # User Christian Urban # Date 1414592600 0 # Node ID 0079db1a1c9d5a0450bb6acd6ce3838642113e26 # Parent 8a42736cce27be6f9c52ca1316d8670751b65e5c updated diff -r 8a42736cce27 -r 0079db1a1c9d handouts/ho05.pdf Binary file handouts/ho05.pdf has changed diff -r 8a42736cce27 -r 0079db1a1c9d handouts/ho05.tex --- a/handouts/ho05.tex Wed Oct 29 13:08:11 2014 +0000 +++ b/handouts/ho05.tex Wed Oct 29 14:23:20 2014 +0000 @@ -117,13 +117,15 @@ in is in which order the messages are sent. For the SYN-ACK protocol we will therefore use the notation -\begin{center} -\begin{tabular}{l@{\hspace{2mm}}l} -$A \to S$: & $SYN$\\ -$S \to A$: & $SYN\_ACK$\\ -$A \to S$: & $ACK$\\ -\end{tabular} -\end{center} + +\begin{equation} +\begin{array}{l@{\hspace{2mm}}l} +A \to S: & SYN\\ +S \to A: & SYN\_ACK\\ +A \to S: & ACK\\ +\end{array}\label{SYNACK} +\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 @@ -164,21 +166,91 @@ \{\{msg\}_{K_{AB}}\}_{K_{BC}} \] +\noindent The idea is that even if attacker Eve has the +key $K_{BC}$ she could decrypt the outer envelop, but +still do not get to the message, because it is still +encrypted with the key $K_{AB}$. Note, however, +while an attacker cannot obtain the content of the message +without the key, encrypted messages can be observed +and be recorded and then replayed at another time, or +send to another person! + +Another very important point is that the notation for +protocols such as shown in \eqref{SYNACK} is a +\underline{schema} how the protocol should proceed. +It could be instantiated by an actual protocol run +between Alice, say, and the server Calcium at King's. In this +case the specific instance would look like + +\[ +\begin{array}{l@{\hspace{2mm}}l} +\text{Alice} \to \text{Calcium}: & SYN\\ +\text{Calcium} \to \text{Alice}: & SYN\_ACK\\ +\text{Alice} \to \text{Calcium}: & ACK\\ +\end{array} +\] + +\noindent But a server like Calcium of course needs to +serve many clients. So there could be the same protocol +also running with Bob, say + +\[ +\begin{array}{l@{\hspace{2mm}}l} +\text{Bob} \to \text{Calcium}: & SYN\\ +\text{Calcium} \to \text{Bob}: & SYN\_ACK\\ +\text{Bob} \to \text{Calcium}: & ACK\\ +\end{array} +\] + +\noindent And these two instances of the protocol could be +running in parallel or be at different stages. So the protocol +schema shown in \eqref{SYNACK} can be thought of how two +programs need to run on the side of $A$ and $S$ in order to +successfully complete the protocol. But it is really just a +blue print how the communication is supposed to proceed. + +This is actually already a way how such protocols can fail. +Although very simple the $SYN\_ACK$ protocol can cause +headaches for system administrators where an attacker +starts the protocol, but does not complete it. This looks +graphically like + +\begin{center} +\includegraphics[scale=0.4]{../pics/synflood.png} +\end{center} + +\noindent The attacker sends lots of $SYN$ requests which the +server dutifully answers, but needs to keep track of such +protocol exchanges. So every time a little bit of memory +resource will be eaten away on the server side until all +resources are exhausted and when Alice tries to contact the +server then the server is overwhelmed and does not respond +anymore. This kind of attack are called \emph{SYN +floods}.\footnote{\url{http://en.wikipedia.org/wiki/SYN_flood}} + +After reading four pages, you might be wondering where the +magic is. For this let us take a closer look at authentication +protocols. + +\subsubsection*{Authentication Protocols} + +The simplest authentication protocol between principals +$A$ and $B$, say is + +\begin{center} +$A \to B: K_{AB}$ +\end{center} -Note, however, -while an attacker cannot obtain the content of the message -without the key, this encrypted message can be observed -and be recorded and then replayed at another time. +\bigskip\bigskip Keyfobs - protocol +\subsubsection*{Further Reading} + {\small \url{http://www.cs.ru.nl/~rverdult/Gone_in_360_Seconds_Hijacking_with_Hitag2-USENIX_2012.pdf}} -attack such protocols because they use weak ciphers (Oyster -card) - \end{document} %%% Local Variables: