%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentstyle[12pt,twoside,alltt]{article}
\textwidth=6in
\oddsidemargin=0.25in
\evensidemargin=0.25in
\topmargin=-0.1in
\footskip=0.8in
\parindent=0.0cm
\parskip=0.3cm
\textheight=8.00in
\setcounter{tocdepth} {3}
\setcounter{secnumdepth} {2}
\sloppy

\newenvironment{proof}{\noindent{\bf Proof:}}{\qed\bigskip}
\newenvironment{proof_sketch}{\noindent{\bf Sketch of 
Proof}\hspace*{1em}}{\qed\bigskip}

\newtheorem{theorem}{Theorem}
\newtheorem{corollary}{Corollary}
\newtheorem{lemma}{Lemma}
\newtheorem{claim}{Claim}
\newtheorem{fact}{Fact}
\newtheorem{definition}{Definition}
\newtheorem{assumption}{Assumption}
\newtheorem{observation}{Observation}
\newtheorem{example}{Example}
\newcommand{\qed}{\rule{7pt}{7pt}}

\newcommand{\lecture}[4]{
\pagestyle{headings}
\thispagestyle{plain}
\newpage
\noindent
\begin{center}
\framebox{
\vbox{
\hbox to 5.75in { {\bf 6.857 Computer and Network Security
\hfill Fall Term, 1996}  }
\vspace{4mm}
\hbox to 5.75in { {\Large \hfill Lecture #1 : #2 \hfill} }
\vspace{2mm}
\hbox to 5.75in { {\it Lecturer: #3 \hfill Scribe: #4} }
}
}
\end{center}
\markboth{Lecture #1 : #2}{Lecture #1 : #2}
\vspace*{4mm}
}

\begin{document}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Lecture command takes 4 arguments:
%		ordinal number of the lecure
%		date of the lecure
%		lecturer
%		scribe---that is you
%
\lecture{15}{October 29, 1996}{Ron Rivest}{Michael Duff} 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% For theorems, lemmas, definitions, remarks, etc. use commands
% \begin{theorem} .... \end{theorem} 
% \begin{definition} ... \end{definition} 
% \begin{proof} ... \end{proof}
% and so on ...
%
% If you want to insert figures in your notes do the following: 
% 1) Prepare your figures using your favourite graphic editor
% 	for example idraw or xfig
% 2) Save your pictures in PostScript form using the following convention
% 	notes-nn-fig-mm.ps where nn is the number of the lecture you 
% 	are scribing and mm is the sequential number of the picture in the 
% 	notes
% 3) Insert the following block in your LaTeX code in the place you 
% 	want to insert the figure BUT LEAVE IT AS A COMMENT (with the %
% 	at the beginning of the line) since it will not work on athena: 
%
% \begin{figure}[h]
% \begin{center}
% \mbox{\psfig{figure=notes-nn-fig-mm.ps}}
% \caption{A very nice picture.}
% \label{fig:mm}
% \end{center}
% \end{figure}
%
% 	of course the picture will not show up when you compile and 
% 	print your notes, but don't worry the TA will take care of it. 
% 4) When you mail the TA the LaTeX code mail him/her the PostScript
%	files for the figures as well 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Your notes start here!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\underline{4 Handouts} \newline
\hspace*{.25in}Lecture notes 12, 13, and 14 \newline
\hspace*{.25in}Reading for Lecture 15 ({\em Authentication and authenticated key exchanges} by Diffie, Oorshot, and Wiener)

\underline{Other Announcements} \newline
\hspace*{.25in}Midterm exam will be handed out Thursday, October $31^{st}$ (take-home exam)

\hspace*{.25in}New book:
{\em Handbook of Applied Cryptography} (Menees et al, CRC, 1997) \newline
\hspace*{.5in}- may be helpful for term papers \newline
\hspace*{.5in}- more technically correct than Schneier's {\em Applied Crytography}

\vspace*{.5in}

Topics covered in this lecture:
\begin{itemize}
\item Establishing keys (continuing from previous lecture)
\item Basic Dillie-Hellman and modifications to patch vulnerabilities
\item Message freshness and replay attacks
\item Random challenges and random numbers
\item Station To Station (STS) protocol
\end{itemize}

\section{Establishing Keys}

The goal is to establish an authenticated and secure channel between two
parties.  For this lecture, we suppose that each party knows something about
the other (e.g. a public key).  With this premise, we begin with a simple
protocol and modify it to achieve this goal.

At the beginning, there is no shared secret key, and Alice and Bob can
communicate over an insecure channel.  At the end of the process, both sides
should have the same secret key and be confident that they are communicating
with the desired party.  For the protocols discussed today, public key
cryptography is allowed.


\subsection{Key Transport Protocol}

The simplest way to exchange a shared secret key is to use public key
cryptography as a ``key transport protocol''.

Given that two parties, Alice and Bob, want to communicate, such a protocol
generally proceeds as follows:
\begin{enumerate}
\item Alice obtains and verifies Bob's certificate.
\item Alice encrypts a message containing the random session key with
Bob's public key and sends it to him.
\item Bob responds to Alice's message by encrypting a confirmation message
with Alice's public key.
\end{enumerate}

This protocol works because an eavesdropper knows neither Alice's nor Bob's
private key and therefore cannot decipher the message from either. However,
there are drawbacks to this method.  By exploring these drawbacks, we can
identify goals that must be achieved:

\begin{itemize}
\item An eavesdropper could record the conversation and decrypt it at a later
time.  A cryptographic ``break'' of a long-term public key system should not
disclose the recorded ciphertext (yielding plaintext). \newline
$\Rightarrow$ Goal: Perfect forward secrecy

\item The approach doesn't protect against replay attacks.  Must ensure that
the messages received by Alice or Bob are not replays of old messages. \newline
$\Rightarrow$ Goal: {\em Freshness} of keys and messages

\item Doesn't protect against injected messages.  An active adversary could
simply encrypt messages with Alice's and Bob's public keys in order to
establish the session key of his choice. \newline
$\Rightarrow$ Goal: Authentication of sender and contents of the message
\end{itemize}


How can these goals be achieved?

The idea behind perfect forward secrecy is to establish a session key in
such a way that this key cannot be revealed or computed via a later
analysis of the messages.

In general, there are two uses for public key systems: encryption and
signatures.  If the session key is transmitted encrypted via a public key
system, however, then the protocol is in the same trouble as before.  If a
party's secret key is compromised, then an adversary could decode the key
establishment messages of a previously-recorded conversation to reveal the
session key.  Then this session key can be used to decode all subsequent
messages.  Therefore, a public key encryption system should not be used for
key transport protocols.

$\Rightarrow$ Key idea: {\em If a public key system is not used for key
transport or encryption, but only for signatures, then we are more likely
to achieve perfect forward secrecy.}

Note that an issue with signing messages is anonymity.  If one signs a
message using a private key, then the message is no longer anonymous.


\subsection{Diffie-Hellman Approach: A Review of the Basic Protocol}

Let $p$ be a large prime publicly known and $g$ a generator modulo $p$. 

1.   Alice picks a random number mod $p-1$, which we will call $x$.  This
number is kept secret from the adversary.  She then sends Bob $g^{x}$.

           \[   A \stackrel{g^x}{\longrightarrow} B \]  

2.  Bob picks a random number mod $p-1$, which we will call $y$.  This
number is kept secret form the adversary.  He then sends Alice
$g^{y}$.
          
          \[   A \stackrel{g^y}{\longleftarrow} B \]  
    
3.  Now both Alice and Bob can use $g^{xy}$ as their session key.
Note that Alice gets $g^{y}$ from Bob.  She already knows $x$.  Symmetrically
for Bob.  

Notice that if Alice and Bob's public keys are $g^{x}$ and $g^{y}$,
respectively, then the process is non-interactive.


\subsection{Vulnerabilities of the ``Bare-Bones'' Diffie-Hellman Approach}

One attack that can be used against the above protocol is a ``man in the
middle'' attack.  This, of course, is only a concern when the adversary is
active and can inject messages into the system.

To patch this vulnerability, cryptographic signatures can be used to
authenticate the source of each message.  This way, the "man in the middle"
cannot resign messages as Alice or Bob.

Using signatures, the key exchange protocol is modified to become the
following:

1. Alice sends $g^x$ and signs $g^x$ with her secret key (which gives
$S_A(g^x))$:

           \[   A \stackrel{g^x, S_A(g^x)}{\longrightarrow} B \]  

2. Bob can now verify that the message was sent from Alice and that the
quantity $g^x$ was not changed.  He then responds with a symmetric message:

           \[   A \stackrel{g^y, S_B(g^y)}{\longleftarrow} B \]  

Once again, at the end of the protocol, Alice and Bob can use $g^{xy}$ as
their session key.  And, they can be confident that the messages were signed
by the desired party.  However, vulnerabilities still exist in this modified
protocol and will be discussed next.



\section{Message Freshness and Replay Attacks}

With the above protocol, the problem of message {\em freshness} still exists
(i.e. there is no mechanism to prevent a replay attack).

Mechanisms for preventing replay attacks:
\begin{itemize}
\item Add a serial number to each message.  A serial number is one which
never repeats, so each message is unique.  Note that such a serial number
must also be authenticated or an adversary could simply append any number he
wishes.  One disadvantage to using serial numbers is that they require
maintaining state.  Also, be weary of overflow (which would cause the numbers
to repeat).

\item Add a timestamp to each message.  Timestamps require clock
synchronization (at least roughly), which is generally difficult to do.
Another issue with timestamps is how to decide on a cutoff for old timestamps
(i.e. how old of a message will be accepted?).  One possible solution here is
to remember all of the messages during the allowed time window and check each
new message for a repeated time stamp.

\item Random challenge or {\em nonce}.  A {\em nonce} is something that never
repeats and is unpredictable.

How are nonces used?  In order for B to verify a message from A:

\begin{enumerate}
\item Bob asks Alice to respond to a random challenge (e.g. a random number)
\item Alice responds with the signed version of the challenge.
\end{enumerate}

Since Bob generates the random number (which shouldn't repeat), Alice cannot
predict the challenge.  And Bob can verify that the response came from Alice
because he knows Alice's public key.  This protocol can be carried out
symmetrically so that Alice is also confident that the messages are fresh.
\end{itemize}



\subsection{Random Challenges and Random Numbers}

For the random challenge approach, it is important to be sure that the
generated numbers are random.  Poor random number generation is the
downfall of many crypto system implementations, regardless of how good
the system designs are.

Random bits can be generated in a number of ways - some are good, some are
not so good.  For example, good random bits can be obtained from the
environment, such as a microphone, cosmic ray events, or timing a person's
key strokes.

Questions one should consider about random bits and numbers:
\begin{itemize}
\item How does one classify a string of bits as random or not?
\item How to test the randomness of the generated numbers?
\item How to test the reliability of the random number generator?
\end{itemize}

One way to determine the randomness of a set of bits or numbers is to check
the statistical distribution of the numbers.  If the numbers are random, then
the distribution should be even across the possible range of numbers.

For a long string of random bits or numbers, it may be difficult to determine
if the generator is working correctly or not since the device may work for some
time, then start producing bad random numbers.  One method suggested in class
for dealing with this scenario is to use a sliding window (of length $n$ bits
or numbers) to divide up the long string for analysis.  The window can be
shifted one bit or number at a time to consider a new set.


\section{Augmenting the Diffie-Hellman Approach}

For now, assume that the random number generator being used is a good one.
A random challenge will now be added to the Diffie-Hellman approach.
$r_A$ and $r_B$ are random numbers generated by Alice and Bob respectively.

1. Bob initiates the protocol by sending his identification, B, his random
challenge, $r_B$, along with the same two signed with his secret key:

           \[   A \stackrel{B, r_B, S_B(B, r_B)}{\longleftarrow} B \]

2. Alice verifies that the message is from Bob and responds to the random
challenge by signing it with her secret key.  She also sends her own random
challenge, $r_A$ as well as her identification, A, and $g^x$ which she
generated:

           \[   A \stackrel{A, r_A, g^x, S_A(A, r_B, g^x)}{\longrightarrow} B \]  

3. Bob will now verify that the message is from Alice and that it is fresh.
He then responds to Alice's random challenge by signing it with his secret
key, and sends $g^y$ to Alice to complete the shared key establishment
protocol:

           \[   A \stackrel{B, g^y, S_B(B, r_A, g^y)}{\longleftarrow} B \]  

4. Finally, Alice can verify that Bob's message is fresh and use $g^y$ to
construct the shared secret key.

The above protocol may still contain vulnerabilities.  A careful analysis
is needed to identify them if they exist.


\section{Station To Station (STS) protocol}

The following protocol is taken from today's reading.  Note that in the
reading, $\alpha$ is used in place of $g$:


1.  Alice sends Bob $g^{x}$. (Note $x$ is a random number mod $p-1$ chosen
by Alice.)

           \[   A \stackrel{g^x}{\longrightarrow} B \]

2.  Bob sends Alice back $g^{y}$ along with $E_k(S_B(g^{x}, g^{y}))$
(Note $y$ is a random number mod $p-1$ chosen by Bob.  $k$ is the session
key, $g^{xy}$.)

           \[   A \stackrel{g^y, Cert_B, E_k( S_B(g^x, g^y))}{\longleftarrow} B \]

3.  Alice is now assured that Bob has $g^{x}$ and that the $g^{y}$ she
received is from Bob since it contains Bob's signature.  Alice then sends 
Bob a confirmation.

           \[   A \stackrel{Cert_A, E_k( S_A(g^x, g^y))}{\longrightarrow} B \]

4.  Bob now knows that Alice received $g^{y}$ and that the $g^{x}$ that
he received is from Alice.  

STS eliminates the middle man while retaining perfect forward secrecy.

In this scheme, $g^x$ and $g^y$ are used as the random number challenges.
This is an example of one mechanism accomplishing multiple goals at the same
time.  Some protocol designers prefer to use separate mechanisms for
achieving each separate goal.


There is a potential vulnerability with this protocol.  The vulnerability can
be exploited when a party who will sign anything (``Dave'') is used by the
adversary:

1. Alice sends $g^x$ to Dave, but the message is intercepted by Charlie:

	\[   A \stackrel{g^x}{\longrightarrow} C \]

2. Charlie generates his own $y$ and sends $(g^x, g^y)$ to Dave to be signed:

	\[   C \stackrel{sign\_ g^x, g^y}{\longrightarrow} D \]

3. Dave signs the message and returns it to Charlie:

	\[   C \stackrel{S_D(g^x, g^y)}{\longleftarrow} D \]

4. Charlie then passes the message on to Alice and includes $g^y$ (for key
confirmation) and Dave's signed message fragment encrypted with $k$
(= $g^{xy}$):

	\[   A \stackrel{g^y, Cert_D, E_k( S_D(g^x, g^y))}{\longleftarrow} C \]

5. Finally, Alice confirms the key (and the message is again intercepted by
Charlie):

	\[   A \stackrel{Cert_A, E_k( S_A(g^x, g^y))}{\longrightarrow} C \]

At the end of this scenario, Alice believes she is talking to Dave (who
doesn't actually know the key).  Alice should be {\em convinced} that the
party she is talking to knows the key.  Thus, the stated goals were not met
by this protocol.

It is also important to note that the above protocol assumes that the
encryption function is {\em non-malleable} - that is, you cannot easily
change the encrypted valid signature to another valid one by changing the
encrypted message.

There is an entire field dedicated to protocol analysis.  This will be
introduced in the next lecture.  In general, when analyzing a protocol, one
must describe the goals carefully.  Then, using a special {\em protocol
logic}, one must prove that the protocol satisfies the goals.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Your notes end here!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}



