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