%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\documentstyle[12pt,twoside,alltt]{article}
\documentstyle[12pt,twoside,alltt,psfig]{article}
% is the line you should use IF you're using EPS images.
% make sure to copy the psfig.sty file into the directory with
% the latex document however.
\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, 1997}  }
\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{20}{November 13, 1997}{Ron Rivest}{Lydia Sandon} 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% 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.eps 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. HOWEVER, leave it commented or follow
%	  the instructions at the top if you want to latex it on Athena. 
%
% \begin{figure}[h]
% \begin{center}
% \mbox{\psfig{figure=notes-nn-fig-mm.eps}}
% \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!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\section{Today's Topics}

\begin{itemize}
\item In the news
\item Certification
	\begin{itemize}
	\item Introduction
	\item PGP
	\item X509
	\end{itemize}
\end{itemize}

\section{In the news}

The following are some interesting bugs and related issues from the
news this week:

{\bf Intel Pentium Bug}

Running the instruction {\tt F0 0F C7 C8} will currently crash any
Intel Pentium, regardless of operating system or software from which
it is called.  The instruction, however, has no documented use, so
this bug is unlikely to affect most people.  

While there are no security attacks because of this bug, there are
denial of service attacks.  If you download an ActiveX control, it can
crash your machine utilizing this bug.

The bug may possibly have been put there as a trap door, but it was
most likely just a bug that random checking of instructions never came
upon.  It is agreed that the floating-point division bug was a much
worse problem, as was the one in which dividing by 0 would put you in
priviledged mode.  Intel says they are going to fix this one very
quickly. 

{\bf Microsoft Internet Explorer Bug}

Apparently, in resource URLs ({\tt res://}), IE doesn't check for
array bounds.  So past the first 256 characters, you can write
anything you want, and it will be written to disk.  So you could write
an entire virus starting at the 257th character of such a URL, and it
would execute on the user's machine.

{\bf Sun Microsystems Falsified Java Benchmarks (not a bug)}

Recently, it was found that Sun Microsystems falsified their
benchmarks in some way as to prepare the system to run the particular
timing tests very fast.  This isn't a bug, but an interesting point.

\section{Certification}

In the real world, we don't just have Alice and Bob dealing with each
other's public keys.  We have to add more people to the system, and
along with the people come scaling problems.  What operations are
needed to make public keys work in practice?

\begin{itemize}

\item Give me Alice's public key 
	\begin{itemize}
	\item also: Encrypt this message with Alice's public key
	\item key lookup based on name
	\end{itemize}	

\item Who signed this message
	\begin{itemize}
	\item name lookup based on key
	\item associate name with a public key
	\end{itemize}

\end{itemize}

The large namespace makes these operations difficult to implement.
Also, the names should be unique, recognizable by human beings, and
easy to use.  If such a naming scheme is difficult to use, it becomes
a security issue.  

\vspace{4mm}

Certification attempts to bind names (such as unique email addresses)
to keys.  A certificate might be a signed document that says that
``rivest@mit.edu'''s key is $n_{rivest}$ and $e_{rivest}$.  Current
systems to try to do this are PGP, X509, and SDSI.

\subsection{Who has the authority to give away certificates?}

There is no existing infrastructure for this, yet.  There are also
many ways to go about it, which are outlined here.

\subsubsection{PGP uses a web of trust}

\begin{itemize}

\item Relies on the principle that everyone is related by several
degrees of separation.

\item local, bottom-up

\item Example (see figure): rivest@mit.edu signs a key for
alice@mit.edu, thereby vouching for the validity of her key.  She can
then sign for whomever she wants, including:

	\begin{itemize}

	\item a real user, bob@mit.edu (key $K_3$), or

	\item a faked user, bill@whitehouse.gov (key $K_{bill}$),
	which she creates and maintains for sinister reasons.

	\end{itemize}

\end{itemize}

 \begin{figure}[h]
 \begin{center}
 \mbox{\psfig{figure=notes-20-fig-01.eps}}
 \caption{Sample PGP web of trust.}
 \label{fig:01}
 \end{center}
 \end{figure}

There are issues that arise with this system as follows:

\begin{itemize}
\item Is signing a key transitive?  That is, because rivest@mit.edu
signs alice@mit.edu's key, does that mean that he believes that any
key she signs is valid?  Currently, in such a system, you must find a
path from you to the person with whom you want to communicate, and
evaluate whether you trust that path.  Path Server, by AT\&T, is an
online service to find the path between any two keys.

\item Alice could, indeed, fake that key from Bill Clinton, and use it
to fake email from him.

\item In conclusion, it is a nice system, but it doesn't scale very
well.

\end{itemize}

\subsubsection{Hierarchical systems}

There could be any number of hierarchical systems, such as the one
pictured in Figure 2 below, which could be used not only for signing
certificates, but also for providing authorization to certain
services: 

 \begin{figure}[h]
 \begin{center}
 \mbox{\psfig{figure=notes-20-fig-02.eps}}
 \caption{A sample hierarchy.}
 \label{fig:02}
 \end{center}
 \end{figure}

In this case, the root is responsible for signing the certificates of
the .edu, .com, .net, and .org nodes, as well as any other that report
directly to it.  The .edu node, in turn, signs the certificates of
mit.edu, cmu.edu, and all of the other .edu domains.  In turn, mit.edu
signs lcs.mit.edu, media.mit.edu, etc.  This goes down the chain until
an individual person (here, rivest@mit.edu) has his certificates
validated (this is a slow process).  

X509 uses a different hierarchy, where the levels start at
``country,'' ``state,'' ``organization,'' ``division,'' and continue
down to ``name.''  In the previous example hierarchy, the levels were
more clearly linked to DNS organizations.  A sample key for Professor
Rivest might be ``Country=US, State=MA, Org=MIT, ... Name=Rivest.''
It is a similar structure with a clear outline of authority.  However,
there are some problems with it:

\begin{itemize}

\item What if there is more than one email address to a person?

\item What if one person belongs to more than one organization?

\item Too much trust is placed on the top nodes (if the root node is
compromised, the whole system is),

\item Maintenance (ten percent of the country changes jobs every year),

\item Names are long, when they should be

	\begin{itemize}
	\item unique, and
	\item readable by human beings.
	\end{itemize}

\item Some possibly unwarranted trust in low-level nodes, and

\item losing keys, moving, departmental name change.

\end{itemize}

How do you deal with change?

\begin{itemize}
\item Expiration dates on certificates (in any of the cases),
\item Signed forwarding addresses (in the case of moving, etc), and
\item Revocation (in the case of key compromise, move, change of
organization, etc).
\end{itemize}

Dealing with revocation is a particular challenge.

\begin{itemize}

\item It is possible to maintain a system with no certificates which
uses online certification when necessary.

\item Revocation lists

	\begin{itemize}

	\item Each certification authority has a list of all of the
	certificates that have been revoked,

	\item Issued periodically and signed by the certification
	authority.  But how do you know that you have the most recent
	revocation list?  You can put an expiration date on each one
	that says something along the lines of, ``This revocation list
	is good until the next of its kind is released on 1 December
	1997.''

	\end{itemize}

\item Silvio Micali presents another approach (see below).

\end{itemize}

The approach used by Silvio Micali is as follows: a certificate
contains a name, key, date, and values called $x_0$ and $y_0$.  There
is also a known hashing function.  If someone queries a server to find
out whether a particular certificate for Bob is still is still valid.
The following is returned to him.

 \begin{figure}[h]
 \begin{center}
 \mbox{\psfig{figure=notes-20-fig-03.eps}}
 \caption{Silvio Micali's approach to certification.}
 \label{fig:03}
 \end{center}
 \end{figure}

In this case, the fields within the dotted lines are what Bob presents
as his certificate.  The server sends back a value.  If the server
sends back $y_{1}$, then the ticket is revoked (where $y_{1}$ is the
hash of $y_{0}$).  If the server sends back an $x{i}$, then the
certificate was still valid $i$ days after creation, and $x_{i}$ is
$x_{0}$ hashed $i$ times with the same known algorithm.

\subsection{What prevents you from giving away your private key?}

All of the techniques used for public-key cryptography assume that a
private key stays private; specifically, that no one will voluntarily
give away their private key.  People are worried about

\begin{itemize}

\item liability,

\item legal contracts,

\item loss of reputation (assuming key is associated with name), and

\item detecting double-use (stolen v. given away).

\end{itemize}

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

\end{document}
