% to get hardcopy of this lecture, you need the following files (plus the
% normal latex and tex base directories):
%     lecture19.tex:     latex source file
%     macros.tex:      figure macros
%     psfig.tex:       postscript figure (psfig) macro definition
%     pocs-header.sty: Principles of Computer Systems lecture latex header
%
% run the following programs:
% latex lecture19
%   -> Creates lecture9.dvi, plus latex intermediate files
% latex lecture19
%   -> Run a second time to get cross-references right
% dvi2ps lecture19 > lecture19.ps
%   -> Merges the figures with the text, can also pipe to lpr
%
\documentstyle[12pt,pocs-header]{article}
\Scribes{Steve Keckler and Beng-Hong Lim} 
\Lecturer{Butler Lampson}
\LectureNumber{19}
\LectureDate{November 21, 1990}
\include{macros} % used to include figures in this document
\def\speaksfor{$\Rightarrow$}
\def\says{$\models$}

\begin{document}
\MakeScribeTop

\section{Administrivia}

\begin{table}[h]
\centering
\begin{tabular}{|c|l|} \hline
\multicolumn{1}{|c|}{Handout} &
\multicolumn{1}{c|}{Title} \\ \hline
Notes & Lecture Notes \#16 \\
Notes & Lecture Notes \#17 \\
\hline
\end{tabular}
\end{table}
Jonathan's message describing Butler's clarifications on
problem set \#6 is included at the end of these notes.

\section{Overview}

This lecture covered further issues of computer security including 
the following topics:
\begin{itemize}
\item Secure Channels
\item Encryption
\item Methods of Authentication
\end{itemize}
Handout \#35, {\em Requirements and Technology for Computer 
Security} by Butler Lampson and Doug McIlroy, is the primary source 
for this lecture.

\section{New Terminology}

In order to discuss issues of authentication, we must be able to say 
something about who can send messages and how the messages can 
be sent.

\begin{itemize}
\item A {\em principal} is said to be an entity that is allowed to 
make {\em statements}.  A principal is a subject that appears on 
the Access Control List and may be a single user, such as Bob, or an 
aggregate set of users, such as Bob and Alice, or the users on the 
fifth floor of 545 Tech Square.  The principal may even be an 
application or a system that is being run by another principal.
\item A {\em statement} can be thought of as a request.  A 
statement can mean ``print the contents of file x to my terminal'' or 
``start program y and concatenate the results onto file z''.
\item A {\em channel} is some method by which a principal makes a 
statement.  A channel can be physical, such as a wire, or more
abstract such as a network.
\end{itemize}

We also introduce two new symbols that will aid in the description of
authentication.  To make the claim that principal P makes statement S
we say {\tt P $\models$ S} (or ``P says S'').  We can also show the
relationship between two principals by saying {\tt C $\Rightarrow$ P}
(or ``C speaks for P'').  With these symbols we can make more
complex conclusions: {\tt if C $\Rightarrow$ P and C $\models$ S then P
$\models$ S} (or ``if C speaks for P and C says S then P says S'').

\section{Secure Channels}

As we said in the previous section, channels provide a means for
principals to make statements or for one principal to communicate with
another.  A secure channel is an abstraction which can describe any
secure form of communication.  A channel need not be held in real
time: there can be a time delay from when a message is sent and when
it is received.  The abstraction can include:
\begin{itemize}
\item A physically protected medium such as a wire, disk drive, etc.
\item Calls to the operating system kernel.
\item A network.
\end{itemize}
The goal of a secure channel is to be able to tell where a message 
originated, {\em authentication}, and be able to restrict 
deterministically where a message is sent.  A physical wire fits 
well into this paradigm such that the server knows where requests 
are coming from by seeing what wires they arrive on.  A kernel call 
has similar simplicity in that the operating system keeps track of 
the process IDs and knows which ones are requesting service.

A network, however, is more complicated since the principals which 
are communicating are separated physically.  In order to send a 
message to another principal, one must package up the destination 
address, as well as the source address into the message itself.  If 
the network is hierarchical, we might require more fields in the 
addresses to indicate localities or ports.  Thus we would be able to 
multiplex the source and destination locations to more than one 
principal.  

This secure network model has a few problems.  First, if the encoding
mechanism has an error, then our secure data will end up where we do
not intend.  Thus, the security in a network is only as good as the
channel encoding.  Secondly, in this network description the wires
themselves are still a part of the security model.  This is not an
optimal arrangement, since in reality guarding the wires between two
remote principals could be costly and inefficient.  Ideally, we would
like to decouple the hardware from our security model.

\section{Encryption}

Encryption provides a method of curing both of the problems
encountered in the network described above and allows us to send
secure messages over non-secure channels.  Thus it allows us to
decouple the interconnection network from the secure transmission
model.

All methods of encryption have some similar properties.  An encryption
scheme is one where there are both Encryption and Decryption functions
which have a keys {\tt k} and ${\tt k^{-1}}$ as parameters.  The two
functions must satisfy the following relationship. 
	\[{\tt Dec_{k^{-1}}(Enc_k (M)) = M}\]

The keys {\tt k} and ${\tt k^{-1}}$ may or may not be the same.  An
encryption scheme must prevent someone without the proper ${\tt k^{-1}}$
from decoding the message.  Furthermore, it must also prevent someone
from sending an improperly encoded message as a real message.

The following sections describe several methods of encrypting data.

\subsection{One Time Pad}
The one time pad is so called since the key {\tt k} may only be used
once.  In a simple version of this scheme, {\tt k} is a random set of
bits which is as long as the data to be encrypted.  To encrypt, we
merely XOR the key with the data.  To decode, we let ${\tt k^{-1} =
k}$ and XOR with the encrypted data to get the result.

The one time pad has certain disadvantages.  A given {\tt k} can only be
used once, because if someone knows the decoded message M, then they
automatically know the key {\tt k}.  Furthermore, since we need just as many
key bits as data bits, the keys can grow to be larger than manageable.

As with other encryption schemes, a checksum, which provides some
information about the unencoded data, will be required to ensure that
a received message was in fact created with the encoding algorithm.

\subsection{Data Encryption Standard}
The Data Encryption Standard (DES) has a single 56 bit key which it
uses for all of the data it encodes.  The data is encoded in 64 bit
blocks.  The unencoded data is permuted by some algorithm and then
XORed with the key.  The result is then sent back around the loop and
permuted again.  This continues for sixteen cycles after which the
bits should be sufficiently randomized.

To decrypt, one merely repeats the process.  The decryption cost
without the key is seen as far too high for anyone to effectively
crack the code.  Currently, hardware can perform the DES at a rate of
15 megabits per second.

A checksum is required as well.

\subsection{Public Key Encryption}
The public key encryption scheme provides two different keys {\tt k}
and ${\tt k^{-1}}$ in which both of the following relationships hold.
\begin{eqnarray*}
{\tt Dec_{k^{-1}} (Enc_k (M))} & {\tt = } & {\tt M} \\
{\tt Dec_k (Enc_{k^{-1}} (M))} & {\tt = } & {\tt M}
\end{eqnarray*} 
Each principal will publish {\tt k} but keep ${\tt k^{-1}}$ private.
This scheme will allow both secure broadcasts and one-way
transmission.

If principal A wants to broadcast a message, he simply encrypts with
his ${\tt k^{-1}}$.  Thus all other principals who know principal A's
${\tt k}$ will be able to read the message and be assured that it
did in fact come from principal A.  This then provides a simple means
of authentication.

If principal B want to send a secure message to only principal A, he
encrypts it with A's ${\tt k}$.  Thus only principal A will be able
to decrypt this message with his ${\tt k^{-1}}$.

Public key encryption generally has 512 bit keys, much longer than
DES, and is a slower method of encryption.  Current technology allows
only 500 bits/second per MIP.


\section{Authentication}

In a computer system two pricipals communicate over a channel.  
The process of authentication is to enable one principal to determine
that the channel speaks for the other principal.  As an example, let's
say A speaks to B over channel C:
\begin{verbatim}

                  A -----------------------> B
                               C
\end{verbatim}
How can B determine that C \speaksfor~A? (In practice, the portion of
the channel transmitting A's messages since the channel is likely to
be multiplexed.)  A straightforward method would be for the
authentication process to take place out of band.  An example of an
out of band authentication is for the communicating parties to have
previously met and confidentially agreed on a key.  Another example is
in a timeshared system where the terminals and operator's console are
physically wired into the computer (figure \ref{terminal}).  Consider
the following situation.

\begin{figure}
\centerline{\psfig{width=5.5in,height=2in,figure=terminal.idraw}}
\caption{Console and terminals.}
\label{terminal}
\end{figure}

When Bob logs into Terminal 1, the operator, Boss, issues the following:

\centerline{Boss \says Ch1 \speaksfor~Bob}

This implies Ch1 \speaksfor~Bob, since Boss \speaksfor~Anyone.

In general, we have the following rule:

\centerline{If A \speaksfor~B, A \says~C \speaksfor~B then C \speaksfor~B.}

The rule relies on a model of competency of the parties involved.  The
reason the consequent holds is because if C is competent, then in
order to speak for B, C can always make the effort to request A to say
that C speaks for B.

\subsection{In Band Authentication}

Being able to do authentication without having to resort to out of
band mechanisms is an attractive proposition because it makes the
process of authentication more automatic and less cumbersome.  Figure
\ref{inbandauth} illustrates the principals and channels involved in
authenticating a communication session between two parties. 

\begin{figure}
\centerline{\psfig{width=2in,height=2in,figure=inbandauth.idraw}}
\caption{In band authentication}
\label{inbandauth}
\end{figure}

S is commonly known as the {\sl authentication server} or the {\sl key
distribution center}.  Each principal believes the following:

\begin{itemize}

\item S believes: $K_{AS}$ \speaksfor~A,  $K_{BS}$ \speaksfor~B  
\item A believes: $K_{AS}$ \speaksfor~S,  S \speaksfor~Anyone
\item B believes: $K_{BS}$ \speaksfor~S,  S \speaksfor~Anyone

\end{itemize}

When A wants to talk to B, A requests S to set up a channel to B.  S
sends

\centerline{$K_{AS}$ \says~$K_{AB}$ \speaksfor~B and $K_{BS}$
\says~$K_{AB}$ \speaksfor~A}
\noindent
back to A.  A then passes on $K_{BS}$ \says~$K_{AB}$ \speaksfor~A to
B.  One point to note here is that S never needed to communicate
directly with B to authenticate A.  The path that the authentication
messages taks to travel from the server to the client is immaterial.

One question not addressed is how the server gets set up in the first
place.  Existing systems usually have some system specific scheme for
setting up the servers.

\subsection{Public Key Encryption}

The preceding examples were all based on a secure key encryption
scheme.  One consequence of this is that all communication to set up
the authentication needs to be pairwise.  An alternative method is to
use public key encryption.  Each principal has a private key and a
public key.  Figure \ref{pubkey} illustrates the principals and
channels involved.  The $k_{x}$'s are the public keys and
$k_{x}^{-1}$'s are the private keys. 

\begin{figure}
\centerline{\psfig{width=3in,height=2in,figure=pubkey.idraw}}
\caption{Public Key Authentication.}
\label{pubkey}
\end{figure}

A and B believe $K_S$ \speaksfor~S and S \speaksfor~Anyone. When A
needs to send an authenticated message M to B, he sends

	\[{\tt Enc_{k_A^{-1}}(Enc_{k_B}(M))}\]

%% $$Enc_{k_A^{-1}}(Enc_{k_B}(M))$$

to B.  This message also has the additional property that the message
can only be decoded someone who has $k_B^{-1}$. $Enc_{k_B}$ encrypts
the message for B, while $Enc_{k_A^{-1}}$ puts A's signature on the
message.

Nevertheless authentication is still needed, i.e., someone needs to
say which keys belong to which principals.  To do this, S says:

$$K_S \models K_A \Rightarrow A  \hbox{\rm~~~(no mention made of B)} $$
$$K_S \models K_B \Rightarrow B  \hbox{\rm~~~(no mention made of A)} $$

Note, that unlike secure key authentication, the authentication
statements from the server are not pairwise.  This implies that the
statements can be made at any time, and that the server does not need
to be on line for two principals to communicate.

\subsection{Designation of authentication servers}

In the simple examples above, there was only one server involved in
the authentication process. In large distributed systems, having a
single server would be a bottleneck so multiple servers exist.  This
brings up the question of which server should be chosen to
authenticate a channel between two principals.  The solution to this
is to impose a hierarchical stucture to the system.  Figure
\ref{nametree} illustrates a simple structure.


\begin{figure}
\centerline{\psfig{width=2.5in,height=2.5in,figure=nametree.idraw}}
\caption{Hierarchical Namespace}
\label{nametree}
\end{figure}

The idea then is to use least common ancestor as server.  If Bob wants
to communicate with Alice, then the server used would be the US
server.  However, if John wants to communicate with Alice, the MIT
server would be used and the US server need not be involved at all.  A
refinement of this scheme is possible.  Suppose principals at MIT and
DEC communicate frequently.  MIT and DEC can then agree to bypass the
US server through another server, turning the tree into a DAG.

\section{Clarification of Problem Set 6}
\begin{verbatim}
From: Jonathan Amsterdam <jba@ai.mit.edu>
Date: Wed, 21 Nov 90 15:25:43 est
To: 6.826@neutron.lcs.mit.edu
Subject: PS6 clarification

For those who were not in class, Butler provided the following
clarifications on the new problem set:

Although one way to do the problem would be to quantize time very
finely and pay attention to how the signals propagate down the wire,
that's more detail than necessary.  A more simple-minded approach is
suggested, wherein each transmitter is responsible for sending some
signal on the wire once per tick of its clock.  So each bit
transmitter sends a sequence of tuples:

	<X1, t1, t2>
	<X2, t2, t3>

where the X's are 0, 1 or idle and the t's are times, and 
t_k+1 - t_k = clock period.  (These are global times, common to all of
the nodes.)

Receivers see the signals sent by each transmitter delayed by the
distance between the two nodes.  (You can assume three constants,
dist12, dist23 and dist13, which are the pairwise distances between
the nodes, expressed in units of time.)

At any point in time, each receiver sees a superposition of the three
signals sent by the three transmitters (appropriately delayed).  The
receiver sees a collision if more than one signal is non-idle;
otherwise it sees the appropriate bit.  The receiver never sees
partial bits or other such glitches--this is a substantial
idealization of the real world, where an actual receiver would see
a continuously varying voltage.

One way to implement reception is to have the wire call the receiver
for each bit that comes by.  The other way (perhaps more work) is to
have a "master clock" that pokes each receiver, telling it to read a
bit.
\end{verbatim}

\end{document}


% For GnuEmacs:
% Local variables:
% compile-command: "latex lecture19"
% End: