%     to get hardcopy of this lecture, you need the following files (plus
%     the normal latex and tex base directories):
%     lecture23.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
%     caches.idraw:    picture for this lecture
%
% run the following programs:
% latex lecture23
%   -> Creates lecture23.dvi, plus latex intermediate files
% latex lecture23
%   -> Run a second time to get cross-references right
% dvi2ps lecture23 > lecture23.ps
%   -> Merges the figures with the text, can also pipe to lpr
%
\documentstyle[12pt,pocs-header]{article}
\Scribe{David Waitzman}
\Lecturer{Bulter Lampson}
\LectureNumber{23}
\LectureDate{December 4, 1990}
\include{macros} % used to include figures in this document

\newcommand{\sfop}{$\Rightarrow$}
\newcommand{\spf}[3]{#1 \sfop \ #2 {\bf except} #3}
\newcommand{\spfq}[4]{\begin{quote} \spf{$K_{#1}$}{{\tt #2}}{{\tt #3}}
\hfill #4 \end{quote}}
\newcommand{\says}[2]{#1 {\bf says} ``#2''}
\newcommand{\saysq}[2]{\begin{quote} \says{#1}{#2} \end{quote}}
\newcommand{\dd}{{\rm `..'}}
\newcommand{\qt}[2]{#1\,\verb+|+\,#2}
\newcommand{\cert}[5]{\saysq{\qt{$K_{#1}$}{#2}}{\spf{$K_{#3}$}{{\tt
#4}}{{\tt #5}}}}

\begin{document}
\MakeScribeTop

%%%
%%% Special formatting changes
%%% 
\setlength{\parindent}{0mm}
\setlength{\parskip}{2.5mm}


\section{Review of Channels}

{\em Channels}\/ provide a means for principals to make statements or
for one principal to communicate with another.  We require {\em secure
channels}\/ for our discussion.

Secure channels provide {\em secrecy}\/ and {\em integrity}.  A secure
channel is an abstraction that 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}

Data encryption is typically needed for channels to be secure, especially in
computer networks.

\section{Encryption}

If you believe that P is the only sender that knows the encryption key,
and will use it to send messages, then you can use encryption on the
channel.

All methods of encryption have some similar properties.  An encryption
scheme is one where there are both encryption and decryption functions
that have keys {\tt K} and ${\tt K^{-1}}$ as parameters.  The two
functions must satisfy the following relationship.
\begin{eqnarray*}
	{\tt Enc(K^{-1}, m) = x}\\
	{\tt Dec(K, x) = m}
\end{eqnarray*}

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}
from decoding the message.  Furthermore, it must also prevent someone
from sending an improperly encoded message as a real message.

Exhaustive search of all possible keys will be practical if the
key size is too small.


There are two kinds of encryption:

\begin{itemize}
\item {\bf shared}\ \  ${\tt K = K^{-1}}$  (e.g., like a letter
      substitution cipher) 

\item {\bf public}\ \  ${\tt K \neq K^{-1}}$

\end{itemize}

\subsection{Shared-Key Encryption}

For shared encryption, integrity is lost, since all holders of the key
can send data as the official sender.

The Data Encryption Standard (DES) is a common form of shared-key
encryption.  It has a single 56 bit key, and 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.  Software can do encryption at the rate of
approximately 1/2 bit per instruction.  Hardware can do encryption
at a rate greater than 1 Gbytes/second.  For DES, a hardware
implementation is only about 10000 gates.


If you want to have integrity, then if you use ${\tt Dec(K, random\
message)}$ then the message must not look valid.  This is usually
acheived by computing a checksum of the message and encrypting both
the message and the checksum.  The checksum of the data will ensure
that the result of the decryption is the same as the data originally
encrypted.  The checksum must stop random permutations of the message
from looking valid.  For instance, a simple XOR checksum fails here.

\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, Enc(K^{-1}, m)) = m}\\
	{\tt Dec(K^{-1}, Enc(K, m)) = m}
\end{eqnarray*}

With public encryption, even if you know ${\tt K}$, and many ${\tt
(m,x)}$ pairs, then you still can't find ${\tt K^{-1}}$.  The normal
use of public encryption is for integrity.  Therefore, usually
publicly distribute ${\tt K}$, and leave ${\tt K^{-1}}$ secret.
This scheme allows both secure broadcasts and one-way
transmissions.

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 is about 1000 to 5000 times slower than shared
key encryption.  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.

\subsection{Hardware Implementations}

Suppose you want to encrypt all traffic.  Assume you need to use a
shared-key cryptosystem for algorithmic speed.  Hardware cryptographic
support may be required for implementation speed.

%%DIAGRAM#1: external hardware crypto-peripheral
\begin{figure}
\centerline{\psfig{width=5.5in,height=2in,figure=hw.idraw}}
\caption{Crypto-Peripheral}
\label{terminal}
\end{figure}

Figure 1 shows a host with an attached ethernet controller card.  The
card could be enhanced with an encryption/decryption device that can
transfer plaintext directly to and from the host's memory.  We call
such a device a {\em crypto-peripheral}.

For the crypto-peripheral to determine the key to use for encrypting
or decrypting a packet, it could examine the packet for a keyid.  This
is shown as follows:

%%DIAGRAM#2: keyid in an network packet.
\vspace{3mm}
{\tt
Packet: \framebox{\framebox{header \framebox{keyid} } cypher-text }
}
\vspace{3mm}

The keyid could be an index into a table inside the crypto-peripheral.
The crypto-peripheral must hide the table from the outside.

An alternative is to give the crypto-peripheral a master key.  The
keyid and the master key can be decrypted to give the message's real
key.  (That is, the key-id is the encrypted form of the real message key,
and the master key is the key to encrypt/decrypt it).  This saves
having to have the full key table stored inside the crypto-peripheral.


\section{Key exchange}

Suppose have both public and shared-key implementations available.

There are two problems:
\begin{itemize}
\item Authenticating the endpoints
\item Exchanging keys
\end{itemize}

We will consider two nodes, {\tt A} and {\tt B}, talking with each other.

\subsection*{Authenticating the endpoints}
\vspace*{-4mm}
\begin{tabbing}
XXXXXX\=XXXXXXXXXXXXX\=XXXXXXXXXXXX\=\kill

\>A\>B \vspace*{4mm} \\

1.\>${\tt K^{-1}_a}$, ${\tt K_{a}}$ \>${\tt K^{-1}_b}$, ${\tt K_{b}}$
\>[${\tt K_{a}}$ and ${\tt K_{b}}$ are public] \vspace*{2mm} \\

2.\>{\tt K}\>{\tt K}\>[{\tt K} is a shared key.  An oracle said this]
\vspace*{2mm} \\

3.\>{\tt A} sends ${\tt Enc(K^{-1}_{a}}$, ``I know the key that hashes
to Hash({\tt K})''$)$ [a one-way hash] \vspace*{2mm} \\

4.\>\>{\tt B} concludes ${\tt K\Rightarrow K_{a}}$
\end{tabbing}

The same protocol is used to authenticate {\tt B} to {\tt A}; this
allows {\tt A} and {\tt B} to communicate using shared-key {\tt K}.

This is an application of handoff rule: ${\tt K_{a}\ {\bf says}\ K
\Rightarrow K_{a}}$.  Some messages encrypted with {\tt K} will come
from {\tt B}.  Therefore, need a way to multiplex the channel ${\tt
K|A \Rightarrow K_{a}}$.  This can be done with one bit.

\subsection*{Exchanging the keys}
{\tt A} and {\tt B} choose random numbers ${\tt J_a}$ and ${\tt J_b}$.

\vspace{-4mm}
\begin{tabbing}
XXXXX\=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.\=\kill

\>A\>B\\

\>Does ${\tt Encrypt(K_{b}, J_a)}$\>Does ${\tt Encrypt(K_{a}, J_b)}$\\
\vspace{2mm}
\>Sends to the world\>Sends to the world\\
\vspace{2mm}
\>Receives node B's message\>Receives node A's message\\
\>Decrypts it using ${\tt K^{-1}_a}$\>Decrypts it using ${\tt K^{-1}_b}$\\
\>A is the only party that can do this\>B is the only party that can do this\\
\end{tabbing}
\vspace{-4mm}

The only party that can find ${\tt J_a}$ is {\tt B} (using the private key of a
public-key pair).
The only party that can find ${\tt J_b}$ is {\tt A} (using the private key of a
public-key pair).
You also want the property that knowing ${\tt J_a}$ or ${\tt J_b}$ doesn't
reveal {\tt K}.

One optimization is if you use the ${\tt J_X}$ method symetrically then you
don't need to use the other algorithm for authenticating {\tt A} and
{\tt B}.  The important thing in the above explanation is that it is the
basis for what is commonly used in papers on the subject.

We Now have a building block for building secure distributed systems.


\section{Certificates}

A formula like `${\tt K_{a}\ {\bf says}\ }$``I know {\tt K}''' is just
a pile of bits; it is called a {\em certificate}.  Given channels
usable by computers, we will now explain more about certificates.

P says ``read file foo''.  We could make P some key ${\tt K_{a}}$,
and have file foo's ACL say ${\tt K_{a}}$ can read UID.  The problem
is that this is not a humanly readable ACL, and it is hard to change
${\tt K_{a}}$ since we'll need to update the ACL.

Therefore, want a key ${\tt K_{bwl} \Rightarrow bwl}$, and ACL: ``bwl
can read'' with P being {\tt bwl}.  So, we need a way for the file server
to learn things like ${\tt K_{bwl}\Rightarrow bwl}$.

We have the handoff rule: if ${\tt A'\Rightarrow A}$  and ${\tt A'\
{\bf says}\ B\Rightarrow A}$, then ${\tt B\Rightarrow A}$

%%%<<< See paper, page #8 >>>

Suppose ${\tt K_{ca}\Rightarrow anybody}$; that is, there is a widely
known public key.
We will assume that there is a certification authority, {\tt CA}, that
can deal with certificate storage/generation/verification issues.

Since {\tt CA} knows ${\tt K_{bwl}\Rightarrow bwl}$, it can generate
the certificate ${\tt K_{ca}\ {\bf says}\ K_{bwl} \Rightarrow bwl}$.
Because of the handoff rule, we will believe ${\tt K_{bwl}\Rightarrow
bwl}$.

{\tt A} and {\tt B} need to ask the {\tt CA} for the certificates
${K_{ca}\ {\bf says}\ K_{b}\Rightarrow B}$ and ${K_{ca}\ {\bf says}\
K_{a}\Rightarrow A}$ respectively.
These certificates are independent of {\tt A} and {\tt B}.  Therefore,
certification tickets can be stored unsecurely, everywhere [only for
public-key systems].

This is harder with shared-key systems.  We want ${\tt K_{a/ca}\ {\bf says}\ K_{ab} \Rightarrow B}$ and ${\tt K_{b/ca}\ {\bf says}\  K_{ab} \Rightarrow A}$, where ${\tt K_{x/ca}}$ denotes the
shared key between CA and X.  (The message can have ${\tt K_{ab}}$ in
the clear since the entire message will be encrypted)

\section{Naming Trees}

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, with names as path
names.  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}

There are  names like /mit/clark and /dec/bwl.

Three new principles:
\begin{quote}
$\vdash$ P {\bf except} M \sfop\  P \hfill (N1) \\
$\vdash$ M $\not=$ N \hspace*{.2cm} $\supset$ \hspace*{.2cm}
   \spf{\qt{(P {\bf except} M)}{N}}{P/N}{\dd} \hfill (N2) \\
$\vdash$ M $\not=$ \dd \hspace*{.2cm} $\supset$ \hspace*{.2cm}
   \spf{\qt{(P/N {\bf except} M)}{\dd}}{P}{N} \hfill (N3)
\end{quote}

DEC thinks: ${\tt K_{root} \Rightarrow / \ except\ dec}$.
MIT thinks: ${\tt K_{root} \Rightarrow / \ except\ mit}$

If at node {\tt /dec} then the certificates are:
\begin{enumerate}
\item \spf{$K_{bwl}$}{{\tt /dec/bwl}}{{\tt nil}}
\item \cert{bwl}{\dd}{dec}{/dec}{bwl}
\item \cert{dec}{\dd}{root}{/}{dec}
\item \cert{root}{mit}{mit}{/mit}{\dd}
\item \cert{mit}{clark}{clark}{/mit/clark}{\dd}
\end{enumerate}

An alternative is to have certificates 3, 4, 5 and
{\tt $ K_{dec}\Rightarrow$ dec except bwl}.


\section{Practical Issues}

In the following discussion, pr means process.
\begin{figure}
\centerline{\psfig{height=2.5in,figure=protocols.idraw}}
\caption{Protocol Stacks}
\label{protocols}
\end{figure}
The goal in figure \ref{protocols} is to conclude that ${\tt K|pr
\Rightarrow bwl}$.
We will describe having {\tt bwl} hand over to WOS (at login time) the
ability to speak for him:

\begin{enumerate}
\item ${\tt K_{bwl}\ {\bf says}\ K_{wos}|pr \Rightarrow K_{bwl}}$

\item NFS knows: ${\tt K|pr \Rightarrow  K_{wos}|pr}$

\item Thus, ${\tt K|pr \Rightarrow K_{bwl}}$
\end{enumerate}

At login time we generate ${\tt K^{-1}_{bwl}}$ from {\tt bwl}'s password.

An enhancement: use caching to speed up the system.  Cache the
certificates.  The problem that arises is invalidating the cache.

\end{document}