%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentstyle[12pt,twoside,alltt,psfig]{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{11}{October 10, 1996}{Ron Rivest}{Jered Floyd} 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% 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 nose starts here!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Announcements}
\subsection{Diffie Lecture on October 17}
   Dr. Whitfield Diffie will be lecturing on "Cryptology, Technology,
and Politics" at 3:30 on October 17th.  His lecture will be in 34-101,
and the class will be ending early enough so that we can attend.

\subsection{Midterm}
   The miderm will be a take-home test that will be handed out on
Halloween, October 31.  It will be due the following week. There will
be no additional homework for that week.

\subsection{Term Project Reminder}
   Reminder: It would be a good idea to form teams for the
term project soon. Some ideas for term projects:
\begin{itemize}
   \item A survey an area not studied in class
   \item The design, and possibly implementation of some relevant system
   \item A 'Study of security of laptops on airplanes'
\end{itemize}

\section{Digital Signatures}
   Digital signatures are a powerful idea, and a powerful security
tool.  There are a large number of potential applications, particularly
in the areas of electronic communication and commerce.  

   Some areas in which digital signatures could be used:
\begin{itemize}
   \item Driver's License; this could become a document on your
smartcard, signed by the DMV.
   \item Passports
   \item Electronic payments
   \item Message authentication, of both sender and contents
\end{itemize}

\section{Security of Signature Systems}
   What does it mean for a digital signature system to be secure?

   It means that there is security against forgery; forgery in the
signature system is extremely difficult.

\begin{description}
   \item[forgery] Coming up with a new valid message, signature pair 
(M,$\sigma$) different than any previously signed message.
   \item[existential forgery] The message M may be anything.
   \item[chosen-message forgery] The message M is chosen by the adversary.
\end{description}

To analyze the security of a signature system, let's list what an
adversary might already know. In increasing amounts of information:
\begin{itemize}
   \item Your public key
   \item $(M_i , \sigma_i)$'s you've signed
   \item Chosen M's signed by you.
   \item Adaptively chosen M's signed by you. (Chosen $M_{i+1}$ after
seeing $(M_i , \sigma_i)$)
\end{itemize}

So, for a secure signature system, one requirement is that the
underlying mathematics must be well thought out to protect against
forgery.

Another requirement to verify a signature is that you {\em need} to
know the sender's public key with confidence.


\section{Public Key Distribution}
   How can we get a public key with confidence? It could be passed out
on a handout, on a floppy, or some other physical medium.  A
secure hash of the key could be handed out, and the key retrieved via
less secure means.  While these direct approaches work, they don't
scale very well.  Something important to keep in mind when working on
this problem is that the key distribution channel doesn't need to be
secure, only authentic.

\begin{description}
   \item[certificate] A document that states "{\bf Ron}'s public key is
{\bf xyz}", signed by a certifying authority (CA).
   \item[certifying authority] An entitiy vouching for the
authenticity of the key.
\end{description}

Certificates allow us to back off one step, but now we need to know
the CA's public key, and we have to {\em trust} them. This also brings
up some new questions.
\begin{itemize}
   \item Who will be the CAs?
   \item How do they know who you are? (What your name is?)
\end{itemize}

{\em "Cryptography doesn't make the problems go away, it just makes
them smaller."}

\subsection{Hierarchical CAs}
    One set of answers for the above two questions is provided by this
method. With hierarchical CAs, we can deal with many users relatively
efficiently. 

 \begin{figure}[h]
 \begin{center}
 \mbox{\psfig{figure=notes-11-fig-1.ps}}
 \caption{A hierarchical CA system}
 \label{fig:1}
 \end{center}
 \end{figure}

   If someone wanted to verify Sam's public key, they would need MIT's
certificate for the Engineering school, the Engineering school's
certificate for the EECS department, the EECS certificate for Ron
Rivest, and Rivest's certificate for Sam.  In this situation, what
stops Rivest from certifying Sam as, say, Chuck Vest? In the above
scenario, we have to trust the root key (MIT), but nobody else should
get full MIT authority.  We resolve this by giving keys certifying
authority only within a certain part of a namespace.  In such a
system, names correspond to where you are on the tree. (There are some
standards, ISO X.500, X.509 that specify namespaces.)  For instance,
Sam's name might be:

    $school=engineering,dept=EECS,prof=Rivest,student=Sam$

In this system, a key at any point can only issue certificates for 
extensions of its name.  So,

    $school=engineering,dept=EECS,prof=Rivest$

can't certify a key with a name like

    $school=adminstration,name=cmvest$


However, there are some problems with this system.  What if a user
moves in the tree, by switching departments, or getting a new
advisor? In each case, the user needs a new key and certificate.  This
is a big problem with hierarchical systems.


\subsection{PGP}

   In PGP's key certification model, anyone can be a CA.  PGP chooses
to solve the naming problem by using names like 

    $"$Ronald L. Rivest $\langle rivest@mit.edu \rangle"$

Naming is still a problem, for instance, a user might want multiple
keys; one for business use, one for personal correspondence, etc.

   Here we still have the problem of determining how to verify keys.
We can verify keys face-to-face, as before.  We can also choose to
trust people to give valid information about people we haven't yet
met.  This forms a web of trust, with many possible paths between
keys.

\subsection{SDSI}

   SDSI is the Simple Distributed Security Infrastructure, another
proposed method for dealing with the key verification problem.  In
SDSI, as in PGP, anyone can be a CA.  In SDSI, however, there are
{\em no} global names. All namespaces are local to the CA.

   In other words, a CA associates a name with each key they
certify. If a CA names a key 'Bob', then that key has a relative name
of Bob from that CA.  If that CA is known to another CA as 'Fred',
then that key has a relative name of 'Fred's Bob', and so on.

   In the first example, Sam's name would be "MIT's Engineering's
EECS' Rivest's Sam", or "Rivest's Sam", or "Bob's Friend22"; whatever
a CA chooses to call Sam. 
 
   More information on SDSI is available from the course web page.

\section{Next Week}
   Next week, we will discuss:
\begin{itemize}
   \item Certificate Revocation Lists
   \item Revocation Certificates
   \item Changing Keys
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Your nose ends here!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}



