\section{Technical Issues}

The implementation of a secure authentic transaction system using
smartcards over the MIT network presents several challenges:

\begin{enumerate}

\item Authentication of the user to the service.  How can a service be sure
that a specific card which is presented should be allowed to use the
service.  How can the card prove the its identity.

\item Authentication of the service to the user.  How can the user be sure
that the service which he is authorizing to perform a transaction is a real
service.  In any case where a monetary transaction is involved, the user
certainly doesn't want to authorize just anyone to perform that
transaction.

\item Administration of the cards.  What happens if a card is lost or
stolen?  How can new cards be issued?  These problems seem to imply a
certain amount of centralization in their solutions. What happens if that
certralization breaks down.

\end{enumerate}

The approach to these problems which we recommend is the use of the
smartcards as an encryption engine.  All of the necessary authentication
and authorization problems can be solved through the use of encryption.
The system which we propose provides answers to these questions in a
reasonably elegant and extensible way.  This system involves five classes
of participants: users, smartcards, cardslots, servers, and a key server.
We will examine the system as a whole and then consider in detail the
demands on each of the participants.


\subsection{The smartcard encryption engine}

The smartcards encryption engine ("The system") is a secure, robust and
extensible way to use smartcards to anthenticate a user and authorize
various transactions based upon that authentication.  The transactions
involved can be anything from "Let me in the front door." to "Charge all
this food to my meal plan."  The physical procedure can be as simple as
sliding the card into a slot, or it can involved typing a password for
those situation where simple possession of a card is insufficient
authorization.  The encryption protocols used are simple variations to the
standard public-key encryption and signature protocols.

\subsubsection{Who's who}

The system involves the interaction of five different types of
participants:

\begin{enumerate}

\item The User: This is the person who is trying to use a card. This person
could be anyone from a janitor to a grad student to the Provost of MIT.
So, his interaction with the system should be simple and straightforward.

\item The smartcards: this is the small card which each person will be
issued.  This card is different from the magstripe, "ATM"-type cards to
which most people are accustomed.  The smartcards have small computers on
them.  These computers are capable of handling much of the complexity
involved in the system, shielding the user from the details which take
place behind the scenes.

\item The cardslot: This is the small hole into which the card is placed.
The slot is responsible for many things.  It must supply the power to the
smartcard, and act as the network link.  It is probably attached to
something like a door or a cash register, and it uses the smartcard to
authenticate requests to a server.

\item The server: The servers are a broad range of systems for dealing with
opening doors, keeping track of library books, charging for a burger and
fries, and so on.  The server stands ready to receive authenticated
requests from a card slot, and then acts on those requests.

\item The key server: The key server maintains a list of public-keys for
each user on the system.  It is the responsibility of the key server to
securely distribute any of these keys on request.

\end{enumerate}

Each of these participants is identified by a unique 32-bit number.  

\subsubsection{Who does what?}

Most simply described, the system uses public-key cryptography to perform
encryption, authentication, and "zero-knowledge proofs of identity".  A
zero knowledge proof enables two untrusted computers with the aid of a
trusted key server to securely prove their identity to each other.  Every
entity (except the user) has a private-key/public-key pair.  These keys are
used for authentication and encryption, and also to confirm the integrity
of received messages.  A simple transaction goes like this:

\begin{enumerate}

\item The user inserts his card into the slot.

\item Using the public key of the key server, the card encrypts and signs
its id, and the information required for a zero-knowledge proof of identity
to the key server.  (This process of proving one's identity to another
entity is called "zero-knowledge proof of identity."  It sends this message
to the card slot.

\item Using the public key of the key server, the slot encrypts and signs
its id, and the information for a zero-knowledge proof.  It sends this
message and the message received from the card to the key server.

\item The key server receives the two messages from the slot and confirms
the identity of the slot and the card.  The key server then produces the
information for a zero-knowledge proof and puts this into two separate
signed and encrypted messages: one for the card and one for the slot.  It
includes in each of these messages the public keys for the third party,
i.e, the message for the slot contains zero-knowledge proof information,
and the public-key of the card.  It sends both of these messages to the
slot.

\item The slot receives the messages from the key server, and after
authenticating the key server, extracts the public key of the card from the
message. The slot forwards the messages from the key server to the card.

\item The card verifies the identity of the key server and extracts the
public-key of the slot.  

\item Now that the card and the slot have the public keys of the other,
they exchange zero-knowledge proof information and confirm their
identities.

\item The slot sends the card a private symmetric session-key in which they
conduct the rest of their business.

\item The slot produces a message which it wishes to send to the server for
processing.  This message gets sent to the card which produces a signature
for it.  The message and the signature are encrypted, timestamped and sent
to the server.

\item The server receives the message and decrypts it.  It checks the
timestamp, and uses the signature to verify that the card (and hence the
user of the card) really wishes the accompanying transaction to be
performed.  The server may have to get the public key from the key server.
The server now attempts to perform the transaction.  This may involve
checking for authorization or comparing account balances, but the exact
nature of the transaction is irrelevant to the encryption and
authentication system.

\item After performing the transaction, an acknowledgement containing
verification of success or failure is sent to the slot.  

\item The user can now remove his card from the slot.

\end{enumerate}

If any of the above verifications fails, then the whole process fails.  The
card, slot, or user is free to retry, but everything must work, or the card
and the slot will not exchange a session key, and nothing can proceed.

If the above procedure seems a little paranoid, that is because it is.
This rises from the open nature of the network and the user's need of
assurance that the slot into which he is placing his precious card is a
valid, real slot, and not a slot which a criminal has produced to spoof the
user.  The proofs of identity ensure that only slots with a public key, and
therefore, only officially registered slots, will be able to continue the
protocol.  The user has an implicit trust that an official card-slot will
perform as expected, only sending transactions which the user has
requested.

About half of the complexity of the above protocol can be relaxed if we
assume that the user and card can trust the slot.  This is not
unreasonable, since the slot will usually be an Institute door or cash
register.  The network connection between the card and the slot is also
secure since it is a direct physical link.  It is important to note that
this relaxation of the protocol makes the card vulnerable to a chosen
plaintext attack, leaving the card's private key open to cryptanalysis, so
the paranoia is necessary for the most complete security.


\subsubsection{The user}

By the user, we mean the actual, physical, card-carrying person who wants
to get something done.  He could be anyone, so his interaction with the
system should be kept simple and minimal.  The most we should require a
user to do, is typing a password into a keypad.  This is reasonable, since
most people are familiar with this procedure from automatic teller machines
(ATM's).

The user is fallible, so we should be prepared when he loses or damages his
card.  If this happens, we simply issue him a new card with a new key pair.
The key server is informed of his new public key, and his old public key is
removed from the database.

The user is required to have one (or possibly two) thing:

\begin{enumerate}

\item His smartcard

\item An optional password

\end{enumerate}

\subsubsection{The card}

In general, there will be a one-to-one mapping from smartcards to users, but
this is not necessarily the case.  In most situations, possession of a card by
a user is equivalent to having all of the permissions and authorizations which 
the card has.  For those cases where a little more security is required, a
password can be used to verify the identity of the card-holder.  

The smartcard knows the following pieces of information:

\begin{enumerate}

\item The public-key of the key server.

\item Its own private key.

\item A second private-key which has been hashed using the optional
password.  In those situations where a password is required, the password
will be used to decrypt the second key, and this key will be used in place
of the usual private key for all transactions.

\end{enumerate}

The card also has contains all of the computational machinery necessary for
public-key encryption, signatures, and zero-knowledge proofs.  It also
knows a simple form of symmetric encryption for communicating with the card
slot.

Note that the card doesn't care about any of the details of a particular
transaction.  It is simple an encryption engine and a secure storage place
for the user's private-key.

An added level of security can be added by using a smartcard with a
built-in keypad into which to type the password.  This would prevent the
"trojan horse" attack in which passwords are recorded as the user types
them in.  This step is important since the user enters the password before
the identity of the card-slot has been confirmed.


\subsubsection{The card slot}

The card slot is responsible for providing the card with a link to the
network and a transaction to perform.  The slot is probably attached to
door, a cash register, or a keypad.  It is the slot who figures out what
type of transaction is being performed and determines the server to which
to send the transaction.

The card slot has:

\begin{enumerate}

\item The public-key of the key server.

\item Its own private key.

\item Knowledge of whether a password is required for particular operations.

\end{enumerate}

The slot also contains the same encryption machinery as the card, as well
as whatever is necessary to figure out what the user is trying to do,
create the transaction request and forward it to the server.

\subsubsection{The server}

The server component of the system is actually a catch-all for the many
diverse services which may be using the system.  A service can be a single
computer or an entire system in itself.  The server needs to be able to
perform the same encryption operations as the other components of the
system and it knows:

\begin{enumerate}

\item The public key of the key server.

\item Its own private key.

\item Whether or not a password is required to use this service.

\item Which card-slots are authorized to request a transaction from this
service. 

\end{enumerate}

Additional services are easily added with no real extension to the
smartcard protocols.  All that is necessary is that a particular card slot
know the transaction format which a server expects.  The card will sign the
message regardless of its content.

Added security is provided by giving the server a list of authorized
card-slots.  Obviously something is going wrong if an attempt to order food
comes from a door slot.  This technique will not continue to work if the
system gets too large.  If this becomes a problem in the future, then the
list can be replaced by some sort of capability system.  This was left out
of the protocol at this time to reduce the initial complexity of the
system.

\subsubsection{The key server}

The key server knows:

\begin{enumerate}

\item It's private key.

\item The public keys for every id that exists.

\end{enumerate}

These keys can be changed when necessary due to lost cards, etc.  If the
private key is changed, then every card, cardslot, and server on the system
needs to be informed of this change.  This cannot be done securely using
any automatic means, and would probably require reissueing cards to all
users.  This is probably the single biggest point of failure in the entire
system.  The importance of the physical and network security of the key
server cannot be overstated, since the compromise of the key-server's
private-key allows any other component of the system to be spoofed.

Since the key server is required for every transaction, it is desirable to
replicate its service on many different machines placed at strategic
network locations.  This is possible since the information which the server
contains is mostly static.  It only changes when a public key is changed or
added.  This propagation process could be automated.  However, this
approach does allow a security hole if a key is changed, but due to network
difficulties, a particular server fails to receive notification of this.
This problem is offset by the greatly improved reliability and availability
of a replicated service.


\subsubsection{The ElGamal encryption protocol}

Since all transactions which will occur on the system will involve traffic
over the insecure MIT network, some form of encryption is required to
protect the interests of all users and service providers.  Using
cryptographic techniques not only ensures the integrity and validity of
transactions, but also the privacy of all involved parties.

The use of an asymmetric, public-key system provides mechanisms to do all
of the required operations: data encryption to ensure privacy, message
signing to ensure integrity, and zero-knowledge proof of identity to ensure
validity.  The specific public-key cryptosystem which we propose using was
first proposed by Taher ElGamal in 1985.  The ElGamal system provides for
encryption and digital signatures.  In 1988, Thomas Beth invented a variant
of the ElGamal scheme which is suitable for proofs of identity.

This cryptosystem was chosen for three reasons, 

\end{enumerate}

\item It provides all three operations which are required.

\item Since its proposal in 1985, it has remained secure.  It has survived
almost 10 years of cryptanalysis without being broken.

\item The ElGamal-Beth proof of identity protocol requires only a single
round-trip network transaction.  Many such protocols involve complex
handshaking requiring two or three or more round-trip requests.  This high
rate of network traffic is unsuitable for our needs.

\end{enumerate}

The ElGamal scheme is unpatented; however, the Public Key Partners (PKP)
consortium (of which MIT is a member) feels that this algorithm is covered
under the Diffie-Hellman patent, so there are licensing issues to deal
with.  This patent expires in the US on April 29, 1997.  Further
investigation of this proposal will involve contacting PKP regarding
licensing costs.

\subsubsection{Extensions to the system}

The initial implementation of the system has two separate and opposing
goals: first, to be as secure as possible, and second to be as simple as
possible which still meeting the first goal.  The first goal is necessary
to any system of this type, while the second goal helps to simplify the
initial implementation.  Transaction speed has not been a major design goal
of the system, and it is likely that improvements in speed will need to be
made before the system is put into widespread use.  There are several
techniques which can be used to achieve some speedup.

In 1988, Hans-Joachim Knobloch realized one of the first smart card
implementations of a public-key cryptographic system.  He made a number of
recommendations regarding the makeup of the smartcard processor which he
asserts should increase performance "by some orders of magnitude."[GAM be
sure to put a reference here.]  This should speed up the encryption
operations performed by the smartcard.

Since a particular card slot and server are likely to be in regular
communication, it is possible for them to securely exchange a session key.
This reduces the number of queries to the key server and the number of
expensive proofs of identity required.  Only the card and the slot would
have to proof themselves to each other.

As a further speedup, commonly used public-keys could be cached by any of
smart cards, card slots, and servers.  This reduces network traffic and the
load on the key server.  However, if this is done, it is strongly
recommended that cached keys have a very limited lifetime.  Otherwise, a
lost card's key may be remembered even though it has changed in the key
server.

\subsubsection{Smart cards vs. magnetic stripes}

The smart card system is being designed to replace the system currently in
place at MIT.  The old system uses cards with a magnetic stripe on the
back, and sends transactions over a private network.  Since the network is
not public, it does not need to perform data encryption.  The smartcard
system is more complex to deal with the security and privacy issues which
an open, public network entails.

The additional overhead required by the smartcard system is made up of two
additional network transactions (card-slot to key server and server to key
server) and the time required to perform the encryption operations.  The
use of a cache can reduce the network overhead, but the biggest performance
hit comes from the encryption operations, specifically the proofs of
identity.  In the absence of custom hardware on the smartcards, a single
proof of identity could take about half a second.  If the hardware is
present, this time could be greatly reduced.  Unfortunately, at the rate of
one-half second per proof, each transaction has a lower bound of about 1.5
seconds.  By relaxing the protocol and allowing the card to trust the
cardslot, this time could be halved.

\subsubsection{Extensibility of the smart card system}

The proposed system is very general.  The encryption engine deals primarily
with authentication and verification of the contents of a transaction.  It
does not examine the actual content of the transaction message any more
than required to produce a signature.  This makes it very easy to add new
services to the system.  Only two things are required:

\begin{enumerate}

\item Make a card slot that knows about the new service and understands the
transaction format which the server expects to receive.

\item Make the server for the new service understand how to validate the
identity of a card slot and confirm the integrity of the message.  After
performing these things, it treats the message as it would without the
system.

\end{enumerate}

Since the addition of new services is easy, one should consider what other
things may restrict the growth of the system.  Already addressed, is the
issue of the card slot lists which each server maintains.  It is also
possible to run out of identifiers for all of the various entities involved
in the system.  With a 32-bit id, however, this is unlikely.  It would
require having over 4 billion entities.

The most likely limits are key server storage and network capacity.  Each
key server contains a list of every public key in use.  This could
potentially become a lot of data.  But even more serious is the load on the
key server as it attempts to cope with all of the public-key requests which
come in.  Caching reduces this problem somewhat, but for security issues,
keys cannot remain in the cache for very long periods of time.  Replicating
the key server at many sites reduces the load, as well.  However, noticable
delays probably inevitable during high use times due to network traffic.
This traffic will include not only the systems load, but every file
read/write, World Wide Web request and zephyrgram produced by the hundreds
of other MIT net users across campus.  Of the many extensibility issues,
the problem of network delay is the most insurmountable.

----------CHANGES CONTAINED HERE-----------------

\subsection{Physical and Network security}





-------------------------------------------------





Insert a diagram of the system.
