Using Smart Cards Instead Of The MITCard

Dave Cho Michelle Hsu George Madrid

February 2, 1996

Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Technical Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 The Smart Card Encryption Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.1 Who’s Who . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.2 Who Does What? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.3 The User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.4 The Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.5 The Card Reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.6 The Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.7 The Key Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 The ElGamal Encryption Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Speeding Up The System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Smart Cards Versus Magnetic Stripes . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 Extensibility Of The Smart Card System . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.6 Physical And Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Social Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Replacement Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Responsibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5 Extra Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.6 Special Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.7 Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Financial Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 Cost Of Physical Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Cost Of Card Readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3 Purchase/Installation Of Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Administrative Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 When To Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 Transition Between Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 Lost Cards Or Stolen Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4 Services Enabled On The Smart Card . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.5 Backup Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6 Benefits And Drawbacks For The Administration . . . . . . . . . . . . . . . . . . . . . 15

6 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1 Advantages And Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

ii

List of Figures

1 Interconnection of Smart Card Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Diagram of Authentication Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1 Introduction

Zijn schapen zijn in het droog. – Dutch proverb

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.

2 Technical Issues

The implementation of a secure authentic transaction system using smart cards 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 its identity?

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

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

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

2.1.1 Who’s Who

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

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

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

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

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

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

Each of these participants is identified by a unique 32-bit number. This allows over 4 billion unique ID’s.

Figure 1: Interconnection of Smart Card Components 3 2.1.2 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:

1. The user inserts his card into the card reader.

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

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

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

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

6. The card verifies the identity of the key server and extracts the public key of the card reader.

7. Now that the card and the card reader each have the public key of the other, they exchange zeroknowledge proof information and confirm their identities.

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

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

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 card reader.

12. The user can now remove his card from the card reader.

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.

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.

Figure 2: Diagram of Authentication Transactions

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.

2.1.3 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:

1. His smart card; and

2. An optional password.

2.1.4 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:

1. The public key of the key server;

2. Its own private key; and

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

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.

2.1.5 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:

1. The public key of the key server;

2. Its own private key;

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

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

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.

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

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

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.

2.1.7 The Key Server

The key server knows:

1. Its private key; and

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

2.2 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,

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

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

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

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

2.5 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 reader that knows about the new service and understands the transaction format which the server expects to receive; and

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

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.

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

3 Social Issues

Several social issues surround our design. They are:

1. Privacy and the use of encryption;

2. Logging;

3. Speed of delivery of new card;

4. Responsibility;

5. What has extra passwords;

6. Special needs; and

7. Color.

3.1 Privacy

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 (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 1984-esque manner.

3.2 Logging

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?

3.3 Replacement Speed

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.

3.4 Responsibility

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.

3.5 Extra Passwords

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:

1. Which services would have this extra level of security?

2. Who would have authority to change the password?

3. How difficult would it be to change the password?

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.

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

3.7 Color

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

4 Financial Issues

From a financial point of view, there are several things to consider about the smart card:

1. Cost of the actual cards

2. Cost of buying and installing card readers

3. Number of readers to purchase/install

4. Maintenance of the readers.

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

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.

4.2 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 The Tech articles and other sources follows:

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

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

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

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.

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

4.4 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 afterhours, 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 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.

5 Administrative Issues

The administration will also have several things to consider if the option to switch to the smart card is followed:

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

2. Transition between the M.I.T. card and the smart card;

3. Dealing with lost or stolen cards; and

4. Benefits/drawbacks for the administration.

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

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

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

5.4 Services Enabled On The Smart Card

The basic services available on the smart card will be:

1. Identification;

2. Meal purchases; and

3. Dormitory/building access.

Additional services that would be useful are:

1. Allowing library privileges;

2. Athletic facility access; and

3. Parking privileges.

Finally, for convenience, it is possible to have:

1. A photocopy card;

2. Phone card; and

3. Medical Center pharmacy card

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.

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

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

6 Concluding Remarks

6.1 Advantages And Disadvantages

The advantages of our proposal are:

1. Much higher level of security – smart cards are much harder to reproduce than physical keys.

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

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

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

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

The disadvantages of our proposal are:

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

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

3. Services not normally needing electricity are now affected by power hits (e.g., opening doors).

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

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

6. Very high startup cost – buying and installing readers, servers, and cards.

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

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

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

6.2 Recommendations

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

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

References

1. ElGamal, Taher, “A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms,” 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,” Advances in Cryptology—EUROCRYPT ’88 Proceedings, Berlin: Springer-Verlag, 1988, pp. 302–310.

3. Schneier, Bruce. 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,” 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. Smart cards: principles, practice, applications. Ellis Horwood, 1988.

7. Kim, Hyun Soo, “3 Dorms may get card key system,” The Tech, 20 January 1993 v. 112, n. 66.

8. Editorial Staff, “It’s time to get serious about safety,” 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.

Colophon

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:

Technical Issues  George Madrid
Social Issues  Dave Cho
Financial Issues  Michelle Hsu
Administrative Issues Michelle Hsu

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.