\documentstyle[simplemargins,ifthen,fancyheadings,epsf]{report}

\newcommand{\lf}{\vspace{\baselineskip}}
\newcommand{\PSbox}[3]{\mbox{\rule{0in}{#3}\special{psfile=#1}\hspace{#2}}}
%%%% smart card
%%%% public key/private key
%%%% card reader


\setlength{\evensidemargin}{0pt}
\setlength{\oddsidemargin}{0pt}
\setlength{\topmargin}{-42pt}
\setlength{\headheight}{14pt}
\setlength{\headsep}{30pt}
\setlength{\textwidth}{6.5in}
\setlength{\textheight}{9in}
\setlength{\parskip}{2pt}	

\setcounter{secnumdepth}{3}     % subsubsections are numbered
\setcounter{tocdepth}{3}        % subsubsections are listed in toc
\renewcommand{\thesection}{\arabic{section}}
\renewcommand{\thesubsection}{\thesection.\arabic{subsection}}
\renewcommand{\thefigure}{\arabic{figure}}
\renewcommand{\theequation}{\arabic{equation}}
\title{Using Smart Cards Instead Of The MITCard}
\author{Dave Cho\\Michelle Hsu\\George Madrid}
\date{\today}

\begin{document}
\maketitle
\newpage
\pagenumbering{roman}
\tableofcontents
%\newpage
\listoffigures
\newpage
\pagenumbering{arabic}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}

\begin{quotation}
\begin{center} 
{\em Zijn schapen zijn in het droog.}\\
-- Dutch proverb \end{center}
\end{quotation}

In this report, we will investigate the possibility of replacing the
current MIT card with a new technology called the smart card.  A smart card
looks like a plastic credit card, but it has a microprocessor chip and a
non-volatile RAM embedded in it.  There are many potential advantages to
using the smart card, but also a few disadvantages (mainly the cost).  Like
the Dutch farmer, our proposed system would require a lot of work and
equipment; however, it is unclear if the cost is worth the payoff.

In the following sections, we will discuss the technical, social, financial,
and administrative issues associated with implementing the smart card.  A
concluding section discusses the advantages and disadvantages and our
recommendation of whether or not to switch to the smart card. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\section{Technical Issues}

The implementation of a secure authentic transaction system using
smart cards over the MIT network presents several challenges:
\begin{enumerate} \itemsep=-2pt
\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 its identity?
\item Authentication of the service to the user.  How can the user be certain
that he is communicating with a real service and not an illegal one?  In any
case where a monetary transaction is involved, the user needs to be certain to
whom he is giving authorization to spend his cash.
\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 smart cards
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, smart cards, card readers, servers, and a key server.
These components communicate over a network which is shared with many
unrelated activities as depicted in Figure 1.  We will examine the system
as a whole and then consider in detail the demands on each of the
participants.

\begin{figure}[hptb]
\PSbox{/mit/dcctdw/PS/Classes/6.033/case2fig2.eps}{339pt}{364pt}
%\epsfbox{/mit/dcctdw/PS/Classes/6.033/case2fig2.eps}
\caption{Interconnection of Smart Card Components}
\end{figure}

\subsection{The Smart Card Encryption Engine}

The smart cards encryption engine (``The system'') is a secure, robust and
extensible way to use smart cards to authenticate 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 involve typing a password for
those situations where simple possession of a card is insufficient
authorization.  The encryption protocols used are simple variations of 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} \itemsep=-2pt

\item The user: 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.
His interaction with the system should be simple and straightforward.

\item The smart cards: 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 smart cards 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 card reader: the small hole into which the card is placed.
The card reader is responsible for many things.  It must supply the power
to the smart card, and act as the network link.  It is probably attached to
something like a door or a cash register, and it uses the smart card to
authenticate requests to a server.

\item The servers: 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 reader, and then acts on those requests.

\item The key server: a server which 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.  This
allows over 4 billion unique ID's.

\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 to securely prove their
identity to each otyher with the aid of a trusted key server.  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} \itemsep=-2pt

\item The user inserts his card into the card reader.

\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.
It sends this message to the card reader.

\item Using the public key of the key server, the card reader 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 card reader and
confirms the identity of the card reader 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
card reader.  It includes in each of these messages the public keys for the
third party, {\em i.e.}, the message for the card reader contains
zero-knowledge proof information, and the public key of the card.  It sends
both of these messages to the card reader.

\item The card reader receives the messages from the key server and, after
authenticating the key server, extracts the public key of the card from the
message. The card reader 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 card reader.  

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

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

\item The card reader 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 card reader.  

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

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

\begin{figure}[hptb]
\PSbox{/mit/dcctdw/PS/Classes/6.033/case2fig1.eps}{261pt}{187pt}
%\epsfbox{/mit/dcctdw/PS/Classes/6.033/case2fig1.eps}
\caption{Diagram of Authentication Transactions}
\end{figure}

The network activity is depicted in Figure 2.  Note that most activity takes
place at the physical link between the smart card and the card reader.  There
are three transactions which take place over the network.  All of these are
encrypted and signed making them secure against alteration and packet
sniffing.  

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 card reader into which he is placing his precious card
is a valid, real card reader, and not a card reader which a criminal has
produced to spoof the user.  The proofs of identity ensure that only card
readers with a public key, and therefore, only officially registered card
readers, will be able to continue the protocol.  The user has an implicit
trust that an official card reader 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 card reader.  This is not
unreasonable, since the card reader will usually be an Institute door or
cash register.  The network connection between the card and the card reader
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 a user should have 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 things:
\begin{enumerate} \itemsep=-2pt

\item His smart card; and

\item An optional password.

\end{enumerate}
\subsubsection{The Card}

In general, there will be a one-to-one mapping from smart cards 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 smart card knows the following pieces of information:
\begin{enumerate} \itemsep=-2pt

\item The public key of the key server;

\item Its own private key; and

\item A second private key which has been encrypted 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 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 reader.

Note that the card doesn't care about any of the details of a particular
transaction.  It is simply 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 smart card 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 reader has been confirmed.


\subsubsection{The Card Reader}

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

The card reader has:
\begin{enumerate} \itemsep=-2pt

\item The public key of the key server;

\item Its own private key;

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

\item A prioritized list of servers which are capable of handling a
transaction.

\end{enumerate}
The reader 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.

The card reader keeps a list of servers in order to provide some mechanism for
fault tolerance.  This list should be in some sort or preferential order.  In
the case of food service, for example, the central food server would be first
on the list, followed by a backup server on the local subnet.  If the card
reader fails to contact all of the servers on its list, then it has no choice
but to inform the user that his operation cannot be completed and to eject his
card.

\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} \itemsep=-2pt

\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; and

\item Which card-readers are authorized to request a transaction for this
service. 

\end{enumerate}
Additional services are easily added with no real extension to the
smart card protocols.  All that is necessary is that a particular card reader
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-readers.  Obviously something is going wrong if an attempt to order food
comes from a door reader.  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} \itemsep=-2pt

\item Its private key; and

\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, card reader, 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 reissuing 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, added or
deleted.  This propagation process could be automated.  This approach creates
a security hole when a key is changed, but a particular server fails to
receive notification of this due to network difficulties.  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
published by Taher ElGamal in 1985 [1].  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. [2]

This cryptosystem was chosen for three reasons, 
\begin{enumerate} \itemsep=-2pt

\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; and

\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.  Thus, there may be licensing issues to
dealt with.  The Diffie-Hellman patent expires in the US on April 29, 1997.
Further investigation of this proposal will involve contacting PKP
regarding licensing costs. [3]

\subsection{Speeding Up 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 while 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 smart card processor which he
asserts should increase performance ``by some orders of magnitude.''  This
should speed up the encryption operations performed by the smart card. [4]

Since a particular card reader 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 reader 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 readers, 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 Versus Magnetic Stripes}

The smart card system is 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 smart card system is more complex to
deal with the security and privacy issues which an open, public network
creates.

The additional overhead required by the smart card system is made up of two
additional network transactions (card-reader 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 smart cards,
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
card reader, 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:
\begin{enumerate} \itemsep=-2pt

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

\item Make the server for the new service understand how to validate the
identity of a card reader 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 reader 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, as 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.  

Noticable delays are probably inevitable during high use times due to
network traffic.  This traffic will include not only the load produces by
the smartcard system, 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}

Ultimately, the security of any system is only as good as the least secure
component of that system.  This applies to the smart card system as well as
any other.  With all the attention that is being placed on encryption
methods and protocols, it is easy to overlook the basic issues of physical
and network security.  Unless all of the involved machines, key servers, and
servers alike are safe from physical and network prying, the system is not
secure.  Anyone with physical or network access to the machine can gain
access to any data he desires and possibly change it.

Fortunately, denying physical access to something is an old problem with
many solutions.  Most of these solutions involve good old-fashioned lock
and key.  Unfortunately, denying network access is a much newer and much
more subtle problem.  The methods of attack are very diverse.  Usually, by
making a machine as closed as possible to anything but the most essential
of network traffic, one can achieve a secure workstation.  As an example,
the Kerberos server for MIT has never been broken into.  [5]

It is likely that the key servers would be maintained by several
professional system administrators and that they would be secure.  The
weak link is the many servers which may be maintained by other individuals
who lack familiarity with the issues involved in network security.  The
best solution is to have the servers jointly maintained by the service
providers and by the maintainers of the key servers.

%%%%%%%%%%%%%%%% Insert a diagram of the system.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\section{Social Issues}

Several social issues surround our design.  They are:
\begin{enumerate} \itemsep=-2pt
\item Privacy and the use of encryption;
\item Logging;
\item Speed of delivery of new card;
\item Responsibility;
\item What has extra passwords;
\item Special needs; and
\item Color.
\end{enumerate}

\subsection{Privacy}
%Problems:
%	not letting anyone else know what i do, where i go, when i go, what
%i buy, etc
%	i'm innocent AND it's none of your damn business
%	at-range interrogation
%	location monitoring
The main privacy issue is to not unnecessarily reveal information that
isn't anyone else's business.  In an insecure environment, anyone can find
out when and where a person goes, what they buy, etc.  From this, a usage
pattern can be constructed, which can be exploited.  There are two ways
this information can be constructed: logging requests and packet sniffing.
The former is discussed in the next section.  Packet sniffing can be
countered by encrypting all packets with a sufficiently strong encryption
engine.  However, a major problem with using a strong encryption engine is
the amount of time encryption takes -- for instance, a good assumption is
that door open requests should not exceed five seconds to process.

Technically, smart card technology has the capability of installing a
battery, thereby rendering the smart cards always active.  Since these cards
would be ``always on'', it is possible to use low-frequency radio signals
to transact with one of these cards at range.  While there are many
legitimate uses of this technique ({\em e.g.}, a detector at a door
identifies the person immediately in front of it), the system can be
greatly abused if the information is divulged to the wrong people.  Note
also that this technology allows for constant location monitoring, which
could be used in a Orwellian {\bf 1984}-esque manner.

\subsection{Logging}
%Problems:
%	if ya got the info, ya can't say ya don't have it.
%	students may not want info released to parents; workers may not
%want info released to superiors
All transactions with this system can be logged -- from who made requests
for services to what service was rendered (door opened, a certain entree
purchased), all with timestamps.  The advantages of logging is that a
precise account can be reconstructed for future use (itemized bills, etc.)

The disadvantages of logging are twofold.  First, the agency that holds the
log cannot deny the existence of the logs to the authorities: sometimes it
is advantageous to M.I.T. that information is not made public via court
order.  Secondly, students may not wish to have certain categories of
information available to their parents; likewise, employees may have
similar concerns with regard to their supervisors.

provide examples?

\subsection{Replacement Speed}
%Problem:
%	the card is a central lossage point -- if you lose it, you need a
%replacement damn fast.

The proposed smart card would be a single point of failure: if lost, the
user would suddenly be without keys, food money, or library privileges.
While the last is probably not a major problem, the first two obviously
are, and thus, a major concern is how fast smart cards can be generated and
delivered.  The cards differ only in the user's password and extra PIN
number, so no time would be lost contacting possibly-down servers for
information.  However, the information might not be trivial to encode in
the cards; at this time, the process of programming the cards is unknown.

\subsection{Responsibility}
%Problems:
%	if someone steals my card and
%		breaks into a dorm and burns it down, am i responsible?
%		uses my meal card, am i responsible?
%	there are parallels to low-tech, but no one ever said laws were
%reasonable
%	if a card reader eats my card (gulp munch munch), who pays for the
%replacement?  these things ain't cheap

With physical keys, credit cards, and library cards, there are policies
already in place dealing with responsibility, liability, and
accountability.  However, the logical assumption that these would transfer
smoothly to the smart card equivalent is not determined.  This is a question
for lawyers, and is outside our expertise.

Another question of accountability is if a card reader catastrophically
fails and effectively destroys a smart card.  Although an unlikely
occurrence, the question of who pays for the replacement card still exists,
especially if the cost of smart cards is a non-trivial amount.

\subsection{Extra Passwords}
%Issue: What should have extra passwords?
%	Labs?  Personal dorm rooms?  Anything dealing with money?
%	How easily changed?  Who controls it?

The technology exists to have mini-keyboards on the smart card itself,
thereby providing a technically secure manner to prompt the user for an
additional password.  This would help provide that only people who are
authorized by the card's owner can access certain services.  From this are
raised the following questions:
\begin{enumerate} \itemsep=-2pt
\item Which services would have this extra level of security?
\item Who would have authority to change the password?
\item How difficult would it be to change the password?
\end{enumerate}
Ideally, the extra level of security should be implementable at the reader,
and easily changed.  Convenience, however, is an issue -- perhaps the a
personal identification number (PIN) should be demanded by the reader
rather than the smart card itself.  Note that this modification would
require the user to trust the card reader.

\subsection{Special Needs}

Due to religious constraints, Orthodox Jews will not be able to use a smart
card system.  This is due to the restriction that no electricity can be
used on the Sabbath, thereby rendering these people without a means of
entering their dormitory.  Thus, a workaround needs to be devised to
accomodate these people (this solution would only be necessary for
dormitories, and not, for instance, laboratories).

\subsection{Color}

%blood on concrete:			..
%chartreuse on mauve:			.
%
%vanity cards?  ala credit cards, the background could be custom-made,
%although this would probably be quite expensive.  however,
%fraternities/ilgs/student groups could get cards that have their particular
%logo in the background.  an odd way to advertise, but since a fraternity
%could conceivably order 100 of these things, which would last on the order
%of 5 years, it might be possible, although highly doubtful.

An informal poll revealed that a ``blood on concrete'' (maroon on grey)
motif was twice as popular as a ``chartreuse on mauve'' concept.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\section{Financial Issues}

From a financial point of view, there are several things to consider 
about the smart card:
\begin{enumerate} \itemsep=-2pt
\item Cost of the actual cards
\item Cost of buying and installing card readers 
\item Number of readers to purchase/install
\item Maintenance of the readers.
\end{enumerate}

\subsection{Cost Of Physical Cards}

The cost is approximately \$0.10 for a magnetic stripe card versus over
\$10 for a smart card (this is a late 1980s figure: it should be cheaper by
now). [6]  There seems to be quite a differential here, on the order of about 
two orders of magnitude.  This is a major determining factor in switching 
the current system over to a smart card system.  If the benefits of using a 
smart card do not greatly outweigh using a magnetic-stripe card, it seems 
it will be hard to justify switching to a smart card system.

%%%%%%%%%%%%%%%% This needs to be integrated with a conclusive section from
%%%%%%%%%%%%%%%% the other sections)

Also related to cost is the fact that card readers do not replace
locks, but rather exist in addition to locks.  So the cost of locks, etc.,
will still exist, but there will not have to be nearly as many keys
to copy, distribute, and worry about having copied.  At present, locks
are not changed very often; thus, if few people have the keys to the locks,
then there is no need to change the locks often after the
card-readers are installed.

%%%%%%%%%%%%%%%%  Also, though, is the Jewish issue, because they will have
%%%%%%%%%%%%%%%%  to have keys .....  ???

\subsection{Cost Of Card Readers}

The current card readers for the M.I.T. cards are very expensive.  An
approximate range of the cost taken from various {\em The Tech} articles
and other sources follows:
\begin{enumerate} \itemsep=-2pt	

\item Estimations of \$140,000 per house/dormitory to add card readers
and change the locks on perimeter doors, from Lawrence McGuire, Director of
Housing and Food Services. [7]

\item {\em The Tech} editorial staff claims an estimate of \$3,000 per
lock; \$50,000 to card the essential entrances of the buildings on campus
({\em e.g.}, Infinite Corridor, Bldg 66, Killian Court entrances) [8]

\item Estimation of \$80,000 to card all the locks in the Media Lab,
from Gerry Hornik of the Media Lab. [9]

\end{enumerate}
Compare these figures to: cost of a new key: \$1.75 at Economy Hardware;
\$15 dollars including fine, from M.I.T.  Cost of a new lock is less than
\$20.

In addition to door locks, the card readers on all the A.R.A. cash
registers will have to be changed.  They currently read magnetic strip
cards, but a smart card will require a more sophisticated reader.  The
libraries, which recently have switched to a magnetic stripe reader, will
have to obtain smart card readers also.  Any other services enabled on the
card (copy services, parking, etc.) will need to install smart card readers
as well.

\subsection{Purchase/Installation Of Locks} 

If card readers are installed, the question will be how many of the locks
on a building/dormitory should be card accessible.  The locks are quite
expensive, so it would be better to not have an excessive number of card
locks (for example, installing a card lock outside every single dormitory
room).  However, all the outer doors of a building should be card
accessible at the least.  Dormitories are the main concern, though since
M.I.T. has such an open campus and most Institute buildings are accessible
24 hours a day, some people have said that perhaps the main buildings on
campus should have card locks installed.  In dormitories, only the main
entrances (or entrances to the outside) should have card-readers, for
financial reasons mainly.  If not all the outside entrances are card
enabled (and not regular key accessible either), then there runs the danger
of people propping open doors for convenient access, allowing ``street
urchins'' easy access.

If the eventual objective is to have card readers on every single door
at M.I.T., but the transition will start out by just replacing the key
locks on main/outside doors, then the cost issue will have to be considered
in a different light.  A hundred thousand dollars now, versus a hundred
thousand dollars every year for the next five years is very different.
	
\subsection{Maintenance}

Because of the newness of the card readers and their lesser fault-tolerance
capabilities, M.I.T. will probably need a small staff (2-3 people)
responsible solely for the maintenance of the card locks.  At the
present, they are not very fault tolerant.  Power outages, spilled cans of
soda, and hackers are among the reasons a reader might break down.

When the card-readers are down, people will need another way of getting
into a building.  In most dormitories there are desk workers who will still
be there after the card-readers are installed, but after-hours, there
usually is no deskworker, so the only way people can get into a dormitory
is by using their key.  If any reader breaks down before or after the desk
is open, then someone will have to be there to open the door for them.  For
instance, at McCormick, before the readers were installed, there was no way
for residents to get in after 2 {\sc a.m.}; thus, a night watchman had to
sit at the desk all night to let any residents in.

However, it would not be practical to leave a single person assigned this
duty for each dormitory, because hopefully the readers will not break down
often enough for this to be necessary.

\newpage
\section{Administrative Issues}

The administration will also have several things to consider if the option
to switch to the smart card is followed:
\begin{enumerate} \itemsep=-2pt

\item When to install the locks (now, next year, five years from now, etc);

\item Transition between the M.I.T. card and the smart card;

\item Dealing with lost or stolen cards; and

\item Benefits/drawbacks for the administration.

\end{enumerate}

\subsection{When To Install} 

Considering the cost of replacing the current M.I.T. ID cards with the
smart card (possibly up to 100 times as much per card), it would seem wise
that unless smart cards could be shown to provide an immediate dramatic
improvement over the M.I.T. card, the administration should wait a few
years for the cost of the physical card to decrease before switching the
system.  Also, with the locks being so extraordinarily expensive, it might
be wise to wait until the cost of individual locks decreases too.  (I don't
know what the cost of a mechanical key lock is, but I assume it's
definitely under 20 dollars.)  If security is the concern (because keys are
so easily copied), locks on the doors can be changed more often.
Changing locks could occur at least 150 times before it equaled the cost of
a card lock.  The only benefit of a card-reader, then, appears to be of
a security nature.

\subsection{Transition Between Cards} 

Another aspect is handling the transition between the old card and new
card.  A brief period during which both cards work to make for a smoother
transition.  Perhaps a week during which both the old card and new card are
compatible should exist, so any problems during this period can be reported
and corrected before the new card becomes the sole means of
access, meals, etc.

\subsection{Lost Cards Or Stolen Cards}

Since a major advantage of the card is increased security, replacing lost
or stolen cards should be quick, with as little lag time as possible.  This
is especially the case if the smart card has many services attached to it,
such as identification, meal purchases, dormitory/building access, library
privileges, medical center pharmacy purchases, athletic facility access,
parking, photocopying, etc.  Efficient replacement with minimal
loss should be possible.

If super smart cards, which include a keyboard and display, were used
instead of smart cards, the cost would be even more and losing your card
would be like losing a personal computer.  Super smart cards do not flex as
much as other plastic cards, but they are flexible enough when exposed to
reasonable bending forces.  These cards can keep track of everything from
current credit card and checking account balances to phone numbers and
addresses.  The primary benefit is that the user does not have to trust a
card reader, since the user's PIN is entered directly into his card, and
not the reader.

\subsection{Services Enabled On The Smart Card}

The basic services available on the smart card will be: 
\begin{enumerate} \itemsep=-2pt
\item Identification;
\item Meal purchases; and
\item Dormitory/building access.
\end{enumerate}
Additional services that would be useful are:
\begin{enumerate} \itemsep=-2pt
\item Allowing library privileges;
\item Athletic facility access; and
\item Parking privileges.
\end{enumerate}
Finally, for convenience, it is possible to have:
\begin{enumerate} \itemsep=-2pt
\item A photocopy card;
\item Phone card; and
\item Medical Center pharmacy card
\end{enumerate}
included on the smart card.

For the cardservices involving money (meal, copy, phone, pharmacy), the
idea will be not to have the smart card containing ``electronic money'',
because then if the card is lost, so is all the money.  Rather, the smart
card will be an authorization to make a purchase.  This authorization will
be either of the form ``there is still money in the account, purchase is
allowed'' (like the current meal cards work) or ``a charge may be made to
this account'' (for payment after the purchase is made -- basically, a
credit card charging to the person's MIT account). This could be used for
the pharmacy and phone services; the copy card may work either way, though
currently it is of the former type.

\subsection{Backup Systems}

Ideally, all services would have backup systems in place should an
arbitrary component fail.  In general, all card readers should have battery
backup, although ensuring that the battery is fresh might be difficult.
However, it might be possible to request, via SNMP, that a particular card
reader disallow service temporarily and do a self-check.

For identification, the user's photo can be included on the card, with his
name and identification number included as well.

For meal purchases and library privileges, if a card reader fails, another
card reader can be used instead.  For large dining halls, a local backup
machine could be used to queue requests for off-line batch processing
should the network fail; likewise, a similar queuing backup system can be
used for the libraries.

For dormitory, building, athletic facilities, and parking access, if a
given card or card reader fails, the user could use a phone conviently
located next to the door to call the Campus Police.

For photocopy services, just like the current photocopy cards, there is no
good backup or ``limp home'' system.

The phone service account could be manually credited by requesting the user
to type in his account number, as is currently done with phone cards.  A
likewise backup system could be used to queue pharmacy requests.

\subsection{Benefits And Drawbacks For The Administration}
 
Though the administration claims that they will not enable logs on
dormitory/building access, they can be enabled at any time (for instance,
if intruders to dormitories are still at high levels, the administration
will want to keep track of comings/goings of residents for a while).  This
can increase security, but also enters the realm of privacy concerns.
(this is covered more thoroughly in Section 3.).

Other types of logging, such as keeping track of food purchases, would be
useful for settling billing disputes.  Noting entrances and exits of
residents in the parking lots will hlep th ecmapus police crack down on
illegal parking by those without a permit.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\section{Concluding Remarks}

\subsection{Advantages And Disadvantages}

The advantages of our proposal are:
\begin{enumerate} \itemsep=-2pt
\item Much higher level of security -- smart cards are much harder to
reproduce than physical keys.

\item Information, and information access, is centralized.  Thus, rather
than having five different cards accessing five different services, users
just need a single card.

\item Assuming an optimistic viewpoint, the smart cards are a step towards
having a fully electronic world -- digital money, keys, authentication, and
authorization.

\item If the smart card technology cost goes down (as most computer
technology does), the proposed system may be more cost effective in the
long run, since each new student or faculty member would only be given one
card, rather than four keys, a library card, a meal card, a parking gate
card, etc.

\item Smart card could use the existing MITnet, whereas the M.I.T. card
needs its own dedicated lines for security.

\end{enumerate}
The disadvantages of our proposal are:
\begin{enumerate} \itemsep=-2pt

\item Assuming a pessimistic viewpoint, smart cards are an excellent way
for the Administration and/or Campus Police to monitor everyone's
movements.

\item The centralization of service access ({\em i.e.}, the smart card
itself) means that once lost, all other services are unaccessible.

\item Services not normally needing electricity are now affected by power
hits ({\em e.g.}, opening doors).

\item The system may be slow, due to computationally intensive
authentication routines.

\item The system would require a large support staff, although the total
number of staff required to keep the entire system up may be comparable
with the current number of staff running the decentralized services.

\item Very high startup cost -- buying and installing readers, servers, and
cards. 

\item The system will introduce a large amount of network traffic, and will
be dependent on this network.

\item The system has the potential for introducing logs, and thus, the
potential for abuses of these logs.

\item Since our system would utilize servers that contain sensitive
information, this information would be vulnerable if someone managed to
gain root access on that machine -- an unlikely occurrence if the physical
security of the machine is maintained.
\end{enumerate}

\subsection{Recommendations}

\begin{enumerate} \itemsep=-2pt

\item Based on the research we have done on the smart card, it seems that
switching the current system over to smart cards is a good idea.

\item However, because of the extraordinarily high cost of smart cards as
compared to magnetic-stripe cards, we propose to keep the current system,
but re-evaluate the smart card proposal in a few years, when hopefully the
financial aspects will not be as overwhelming.

\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
{\Huge References

\lf
}

1.  ElGamal, Taher, ``A Public-Key Cryptosystem and a Signature Scheme
Based on Discrete Logarithms,'' {\em IEEE Transactions on Information
Theory,}\/ v.  IT-31, n. 4, 1985, pp. 469--472.

2.  Beth, Thomas, ``Efficient Zero-Knowledge Identification Scheme for
Smart Cards,'' {\em Advances in Cryptology---EUROCRYPT '88 Proceedings,}\/
Berlin: Springer-Verlag, 1988, pp. 302--310.

3.  Schneier, Bruce.  {\bf Applied Cryptography: Protocols, Algorithms, and
Source Code in C}.  New York: John Wiley \& Sons, Inc., 1994.

4.  Knobloch, Hans-Joachim, "A Smart Card Implementation of the Fiat-Shamir
Identification Scheme," {\em Advances in Cryptology---EUROCRYPT '88
Proceedings,}\/ Berlin: Springer-Verlag, 1988, pp. 87--95.

5.  Interview with Jeffrey I Schiller, Network Manager for Distributed
Computing and Network Services, 8 May 1994.

6.  Bright, Roy.  {\bf Smart cards: principles, practice, applications}.
Ellis Horwood, 1988.

7.  Kim, Hyun Soo, ``3 Dorms may get card key system,'' {\em The Tech}, 20
January 1993\/ v. 112, n. 66.

8.  Editorial Staff, ``It's time to get serious about safety,'' {\em The
Tech}, 20 November 1992\/ v. 112, n. 59.

9.  Email from Amy Bruckman to The Faculty Committee on Privacy and The
Graduate Student Council: Privacy implications of the MIT Card.  19
September 1993.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newpage
{\Huge Colophon

\lf
}

This document was produced by using GNU Emacs 18.57.123 and \LaTeX, which
were run on Athena DEC 5000/25 and SUN SPARCclassic workstations.  The font
is twelve-point NewCenturySchoolbook.

The document was divided into three sections.  Those sections, and their
authors, are:

\begin{tabular}{ll}
Technical Issues & George Madrid \\
Social Issues & Dave Cho \\
Financial Issues & Michelle Hsu \\
Administrative Issues & Michelle Hsu \\
\end{tabular}

Proofreading was done equally by the entire group.

Toscannini's ice cream was eaten by George Madrid.


Inspiration was provided by Michelle Hsu.

The \LaTeX\ formatting was done by Dave Cho.

\end{document}