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

1) 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.

2) 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.  

3) 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.

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.


\section 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.  


\subsection Who's who

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

1) 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. 

2) 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.  

3) 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.  

4) 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.

5) 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.

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

\subsection 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:

1) The user inserts his card into the slot.

2) 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.

3) 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.

4) 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.

5) 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.

6) The card verifies the identity of the key server and extracts the
public-key of the slot.  

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

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

9) 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. 

10) 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.

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

12) The user can now remove his card from the slot.

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.


\subsection 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:

1) His smartcard

2) An optional password


\subsection 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:

1) The public-key of the key server.

2) Its own private key.

3) 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.

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.


\subsection 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:

1) The public-key of the key server.

2) Its own private key.

3) Knowledge of whether a password is required for particular operations.

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.


\subsection 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:

1) The public key of the key server.

2) Its own private key.

3) Whether or not a password is required to use this service.

4) Which card-slots are authorized to request a transaction from this service. 

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.


\subsection The key server

The key server knows:

1) It's private key.

2) The public keys for every id that exists.

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.


\subsection 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, 

1) It provides all three operations which are required.
2) Since its proposal in 1985, it has remained secure.  It has survived almost
10 years of cryptanalysis without being broken.
3) 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.

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.


\subsection 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.


\subsection 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.  


\subsection 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:

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

2) 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.

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.


\subsection Physical and Network security





Insert a diagram of the system.
