 |
Samidh Chakrabarti, James Knight, Bill Thies
Proposals are underway to replace the current MIT Card with a cryptographically secure ``smart card'' that improves the lives of students, faculty, and staff. We present the design for a simple, secure, convenient, and cheap card system that is flexible enough to accommodate diverse needs. Our design is centralized, with cards that store only a public/private key and servers that map public keys to access rights. However, to maintain individual privacy, we introduce proxies as intermediaries between card readers and servers; the proxy caches group information, enforces auxiliary restrictions (e.g., time of access), and are the only agents capable of logging. By storing hierarchical access lists on a server, our system provides simple revocation and addition of access privileges, as well as flexible delegation of administrative responsibility. We believe that the explicit trust relationships in our system are preferable to schemes which achieve complete privacy at the cost of complexity, performance, and convenience.
When we entered MIT as freshmen in 1997, we were issued a magnetic stripe card known as the MIT Card. It wasn't until that moment that we felt like we were truly MIT students. To us, the MIT Card was our official passport to MIT facilities and services. By simply swiping our card through card readers, we could open the doors to buildings or labs, check out books at the library, or even enter parking garages. Because of all of these valuable functions, the MIT Card system is used not only by students, but by faculty, staff, and MIT affiliates as well.
Despite its utility, the existing MIT Card system has several undesirable features.
In this paper, we present a design for a secure MIT Card system that utilizes electronic smart cards. The card is not designed for very high security areas, where additional measures such as passwords or keycodes should be retained to protect access even when a card has been lost or stolen. Specifically, our system is designed such that it meets these requirements:
In addition to these absolute requirements, we have several other considerations that shaped our design:
Generally speaking, our design is centralized. Cards hold only a public/private key pair, and an individual is identified by his public key every time he requests access to a door. The ultimate authority for the access control lists and the mapping from public key to identity is a server such as Athena. On the server, the access control lists can be administered just like mailing lists, allowing convenient addition and revocation of access privileges, as well as flexible delegation of list administration rights.
However, there is also a distributed aspect of our design. To prevent the server from logging an individual's actions, we introduce a layer of indirection between the card reader and the server: the proxy. Instead of querying the server to determine group membership every time an individual requests access, the card reader communicates with a trusted proxy, where group information is cached. The proxy-which might be run by a department, lab, or public facility-periodically queries the server for updated group information, thereby hiding from the server the exact pattern of individual accesses. Additionally, the proxy maintains auxiliary access restrictions, such as time of day or access frequency.
The flexibility of our design is evident as the interactions above are extended to multiple servers, proxies, and card readers. When one installs a card reader, one needs to choose: 1) a proxy to trust to log as desired, and 2) a server to trust to maintain lists as desired. If one can't trust another party to perform one of these services, then one can setup an independent proxy or server. As a result, there could be several mutually distrustful servers and proxies, all communicating in the same system, using the same smart card; our design would scale to realms outside of MIT without any inconvenience to the cardholder. Moreover, in every case our system is deployed, it retains the property that the trust between two parties is explicit.
This section specifies the details of our design. After discussing the role of the server (Section 3.1), the proxy (Section 3.2), the card reader (Section 3.3), and the card (Section 3.4), we give the protocols that allow for secure communication between these agents (Section 3.5).
| Card | Reader | Proxy | Server | |
|---|---|---|---|---|
| Public key signatures | X | X | X | X |
| Public key encryption | X | X | X | |
| Random number generation | X | X | X | |
| Large persistant storage | X | X |
The authority for all group and identity information is the server. It is responsible for keeping track of the mapping between users and public keys, as well as who all the members of a group are. This system should be highly secure, as anyone who gains access to it can also gain access to any door that is controlled by this system.
While the system is designed such that it is perfectly feasible to run only one centralized server for all of MIT, the reality is that some groups, such as LCS or AI, who traditionally have their own systems, will want to have more complete control over their doors as well. Thus, the system is designed so that it is relatively easy to setup a separate server if one wishes.
Setting up a server is a fairly simple matter technically. Essentially one just has to install a piece of software that will read group lists and identity to public key mappings from some source (this source could be as simple as a text file.) The software then just has to send these lists as specified by the protocol described in section 3.5.2, whenever an authorized proxy requests them. For the server to be useful, however, one must populate the user list with actual users' public keys.
In order to run your own server, you must therefore have some sort of way to verify who a user is before entering their key into the list. This is discussed in detail in Section 3.4.1.
Once you have set up an independent server, a set of proxies and card readers can be configured to use this server. Thus, the resulting system is completely independent from the main MIT system, but shares the same ID card.
The server has a minimal amount of functionality it must provide. All it needs to do is store the following information and transmit it on demand.
The implementation of the server described in this paper is based on the Athena list structure. However, this is by no means the only way it may be implemented. Any database system that can provide the required functionality may be used. We decided to use the existing Athena lists for usability reasons. In most cases, the list of people who have access to a lab will also correlate with the list of people on a mailing list, or a locker access list. For example, the list 6.033-students contains all the students in 6.033. If there were a 6.033 lab, access should be allowed to all the students in the course.
Athena lists currently have the following attributes: List of members, the administrator (can be a list or a user), whether the list is a mailing list, whether the list is a filesystem group, and flags indicating if the list is private and visible. To make them work with our system requires essentially no changes. They provide many useful features, which we will briefly outline. One of the major issues that the existing Athena structure accomplishes is delegation of administration. A central administrator should not be required to be involved in every modification to a list. With the Athena structure, any user, or any group of users can be designated as the administrator of a list. The list itself may even be set as its own administrator, in which case anyone on the list may add anyone else-for example, if a student group has an office, members of the student group could give access to whomever they choose.
The proxy provides a trusted layer of indirection between the card reader and the server. Each proxy might service multiple card readers that belong to mutually distrustful groups; its fundamental role is to determine group membership of the individuals who are requesting access through the card readers. To determine which public keys are authorized to access which card readers, the proxy intermittently queries the appropriate servers and caches the group lists as sets of public keys. Additionally, the proxy is responsible for enforcing auxiliary access restrictions, such as the time, date, or frequency with which an individual can gain access. Lastly, by asking the servers for identities in addition to public keys, the proxy is the only agent that can provide logging services for a card reader.
Any machine with an Internet connection (or a direct connection to a server and card reader) can serve as a proxy. Thus, a proxy could be set up in each department or lab to configure local card readers; however, a default proxy could also be maintained on the same machine as a server for groups that do not require more local administration. Given a machine, the proxy can be installed as software that would be publicly available. This software could originate from many sources, such as a particular server, the card reader manufacturer, or an open source group. The proxy software need not be particular to any given server.
For the proxy to be operational, it must be registered with the servers it hopes to interact with. The administrator of a proxy would authenticate the proxy's public key to the server by some manual process that is peculiar to each server. For example, for a proxy to gain access to the members of Athena lists, the proxy's administrator might have to present a photo ID and his intended use of the proxy, in addition to the proxy's public key.
The proxy keeps track of the following information:
| CARD READER PUBLIC KEY | CONFIGURATION RECORDS |
|---|---|
| 3908234980 | config-record-1, config-record-2 |
| 2349082332 | config-record-3 |
Each configuration record is a complete description of a set of access rights. At the minimum, a configuration record contains a list at some server. It might contain additional restrictions, as well as logging instructions, for example:
| CONFIG-RECORD-1 |
|---|
| list: daytime-door-529-5th-floor-lcs@lcs.mit.edu |
| times allowed: MWF,5-9 |
| minimum latency between accesses: 2 minutes |
| log: number of daily accesses |
The proxy maintains multiple configuration records per card reader so that different sets of individuals can have different access restrictions to the same place. Note that the configuration record can prevent pass-back violations via the ``minimum latency'' field.
If desired, some of this configuration information could also be stored centrally and periodically downloaded from a server without any changes to other parts of our design.
| SERVER LIST | PUBLIC KEYS AND IDENTITIES |
|---|---|
| students@athena.mit.edu | 9834835213 (jerry), 1348139410 (franz), ... |
| 6th-floor@lcs.mit.edu | 1341341331 (hari), 1343295232 (damian), ... |
For proxies that do not require identities (such as doors without logs), the identity field can be dropped from the table.
The proxy has encryption/decryption capabilities, as well as digital signature (and verification) algorithms. It updates the data structures above as described in Section 3.3 and Section 3.5.
The card reader is a simple component whose primary purpose is to communicate between the card and the proxy. Card readers can be installed for 1) controlling access to a door, and 2) authenticating personal identity, as in a library. Though a card reader could be installed to control logins to workstations (such as Athena), we recommend that a password still be required in these contexts so as to limit the damage that one could do with a stolen or lost card.
We assume that card readers are installed by a third party, such as the company that manufactures them. Each card reader comes with a password, that is given to the administrator for the card reader upon its installation. Once the card reader is on a network, the administrator can connect to it using some software from the manufacturer and set up 1) a new password, and 2) a list of proxies (given by IP addresses and public keys) that the card reader trusts to determine access rights of individuals. As specified below, this list is stored securely within the card reader itself.
Finally, the administrator must contact each proxy used by the card reader and set up its configuration records. Since these records are changed infrequently, the administrator could authenticate himself to the proxy in person, perhaps with a photo ID and a certificate of ownership for the card reader (given by its public key.) If desired, an automated interface that authenticates the administrator given the password of his card reader (or other identifying information) could be designed without any change to the system.
The card reader keeps track of the following data:
| IP ADDRESS | PUBLIC KEY |
|---|---|
| 18.0.23.4 | 3912323523 |
| 18.0.25.8 | 2103402352 |
Instead of having an internet connection, the card reader could maintain a direct connection to a proxy without any changes to our design. In this case, the card reader only needs to keep track of the public key of the proxy to which it's connected.
The card reader has encryption/decryption capabilities, as well as digital signature (and verification) algorithms. Additionally, it can generate a random number during communication with the card.
The card is the individual's means of identification. It differs from current MIT Card in that 1) it contains a public/private key pair, 2) it can compute digital signature functions, and 3) it communicates with the card reader via a stationary and slightly longer connection instead of just a swipe. We assume that the card communicates with the reader through a physical (as opposed to wireless) connection, so as to minimize the risk of 1) accidental disclosure of one's identity (e.g., to a card reader on a chair), and 2) interception of the communications by a listening device near the reader.
Cards can be issued from anywhere that can print information onto the surface of the card. This could be done internal to MIT, or could be sent to a third-party contractor that receives a name, signature, picture, etc. through the mail, and sends back a corresponding card.
However, for a card to be useful, the cardholder must register his card's public key with each server whose doors he wants to access. This registration should be done in person, with the server administrator verifying that an individual matches the picture and biographical information on his card. If there's a match, the individual swipes his card through a card reader and the server associates his public key with his account.
If an individual loses his card, he needs to go to every server with which he is registered and assert that his account should no longer be bound to a given public key. Though this may sound tedious, the individual could register his new card during the same visit, since that process will have to be redone anyways. Any global revocation of a public key would violate the independence of the servers, since the server would have to trust another source for an identity/public key binding.
If the administrator of a card reader wants to revoke an individual's access, then he can simply remove the individual from the access list on whichever server is maintaining it. The change will take effect the next time the proxy updates its version of the access lists.
The card keeps track of the following data:
The card has digital signature (and verification) algorithms.
This section describes the communication protocols that ensure authentic transactions between the card reader, the proxy, and the server. In the following procedures, {M} K indicates that message {M} is signed with key K; {M} K indicates that message M is encrypted with key K.
When a card wants access to a door:
At this point, the card can be removed from the reader. These three steps should not take longer than a few tenths of a second.
If the user is not authorized, the proxy sends back a response {{``access denied'', N} proxy-private-key } reader-public-key to the reader.
If communication fails with one of the proxies, the card reader can try another proxy on its list.
Note that an attacker could try to mount a replay attack by sending a prior message from a card reader to the proxy. The proxy would then authenticate the user and send back a second reply. However, this would not accomplish anything, as when the proxy sends the reply back to the card reader, the reader would reject it, because N, the nonce in the message, is not what the reader expected.
When the proxy wants a new group list from the server:
This protocol prevents replay attacks in both directions. It is not strictly necessary to prevent someone from replaying a request by the proxy to the server, since it would not lead to unauthorized access. However, since these lists can be rather large, preventing the replay protects the network against undue congestion if an attacker flooded the server with old proxy requests.
Instead of the proxy requesting updated lists from the server, the server could notify the proxy that a user list has been changed. This is not necessary, as the proxy can just update its list frequently.
When a card-based key system is installed, privacy advocates often warn of ``Big Brother'' scenarios. They fear that some global authority will be able to track their every move and in turn be able to reconstruct their patterns of behavior. These are legitimate concerns shared by many people at MIT. They claim that ``the administration'' has no business watching their moves.
Initially when we were designing our system, we discussed a wide variety of designs that made user privacy the highest priority. We soon determined that any attempt to completely obscure identity ends up being either inconvenient, or placing trust nonetheless in a central authority that could engineer an attack to achieve logging (see Section 5.)
So our final design rests on a compromise. While people are weary to trust any central MIT administrators, they do trust people whom they know. For example, suppose the Architecture department ran a proxy to control access to the department labs. As described in Section 3, the only entities capable of logging user activity are those that run proxies. This means that the only people who can create an access log of the Architecture department's facilities is the Architecture department itself. A person who works in the Architecture department would likely trust the Architecture department's system administrator with this log information more than an MIT administrator. This is a reasonable observation since the closer someone is to you, the more likely you are to trust him. Hence, the credos of our system is not to ``Trust no one,'' it is to ``Trust only those who you trust.''
Of course, each entity that runs a proxy can choose what information, if any, they want to log. At most, a proxy can log the time a particular public key attempted to access a particular entry. If there are users who are concerned about their department logging this information, they can complain to their system administrators. Since these sys admins are their colleagues, it is likely that the parties can reach an amicable agreement. ``Big Brother'' is no longer watching, only your ``Friends'' are. Giving this logging power to local authorities also reduces the risk of anyone lying about whether or not they keep logs, since the proxy administrators would essentially have to lie to their colleagues.
By decentralizing logging power to local proxies, it makes it impossible to automatically create an MIT-wide global log of user activity. In some cases, such as law enforcement action, police may need log information from multiple proxies. To accomplish this, the police would need to request the logs of each proxy they are concerned with. This scenario, which would almost certainly require that a criminal act had taken place, is the closest that anyone could come to creating a global log.
Discussion of how our system protects against attacks was presented in Section 3. This section focuses on what an attacker could accomplish if she, despite all of our security measures, is somehow able to tamper with a card, card reader, proxy, access list server, or communication line.
This design assumes that the smart cards were purchased from a manufacturer who guarantees a high level of tamper-resistance. For example, some smart cards are engineered such that any attempt to open them results in the memory contents being destroyed through chemical means. This would protect against someone obtaining a private key off of a card.
The greatest risk associated with someone tampering with a card reader is that the public key of everyone who swipes their card through the reader could be recorded. The same is true if a malicious person installs a decoy card reader. Encrypting communication between the card reader and card such the identity of the card is never disclosed to an unauthorized reader is not possible under our system because the card does not store the identity of any entity besides itself. Thus, it has no way of knowing whether the reader it is communicating with is malicious or not.
But is this really a problem? The only thing the attacker could get is information about who (i.e. which public keys) tried to access a particular entry. The private keys of the card holders remain unknown to the attacker, so he couldn't use them to spoof the identity of a card holder in order to obtain access to other entry points. Such card reader tampering would be a purely localized problem since the attack doesn't compromise any other card readers on the system.
If an attacker were to compromise the security of a proxy, he would have complete control over only the entries that the proxy oversees. The attacker could modify the proxy such that it always sends a ``open door'' message to card readers. Or the attacker could modify the access lists cached on the proxy in order to allow or deny access to anyone he wants. Essentially, the attacker would have complete control over every entry point the proxy manages. This attack, however, would only have a localized scope. Compromising one proxy wouldn't give the attacker control over entrances managed by other proxies. More importantly, tampering with a proxy wouldn't give the attacker any information about the private keys of any users, so secure user authentication is preserved throughout the system.
It is important to note that the proxies are being run by system administrators who are likely to be very vigilant about their system. If someone breaks into a proxy, it is likely that the administrators will detect the problem, especially if there are any anomalous problems reported with card reader behavior.
The scenario of hackers breaking into an server represents a serious breach of security. The hackers could modify any access list contained on the server, essentially giving them control over every entrance that uses a card-reader that draws its permissions from one of those lists. Because of this vulnerability, the access list servers must be the highest security machines of the entire system. This isn't an unreasonable demand. After all, the main access list server is likely to be the mailing list servers of Athena. Information Services (I/S), which runs Athena, already has many years of security experience dealing with possible attacks on Athena mailing lists. So I/S is already well-prepared for any attacks that may be launched against the access lists.
As described in Section 3, any vital information sent across communication wires is encrypted. An attacker listening on a wire will find it computationally infeasible to recover the contents of the conversation. The attacker will, however, be able to record public keys as they are transmitted between the card and the card reader. We expect that intercepting this communication will be fairly difficult, and probably about as difficult as tampering with the card reader. Also, as explained in Section 5.2, having the public keys doesn't compromise the security of the users of the system since the users' private keys are unknown to the attacker.
In this section, we compare our design with other smart card designs (Section 6.1), with mechanical keys and locks (Section 6.2), and with the current MIT Card (Section 6.3).
Arguably, the primary shortcoming of our design is that a proxy has access to one's identity every time that one requests access through a card reader. Though one's identity is not exposed beyond the proxy, it may be the case that, while the card reader's administrator trusts the proxy not to keep logs, the individual requesting access does not.
To allow one to remain truly anonymous while interacting with a card reader, we considered a design where cards keep track of a group key for each group that they belong to. Then, the card reader asks the card for the key of the group that can access the door, and the key supplied by the card is checked against the server. Since all the members of the group have the same key, there is no way to distinguish one member from another.
This design suffers, however, with regards to revocation. When one member loses his card, the group key must be changed so that the lost card can't gain access to the door. We can't rely solely on key expiration to invalidate the lost card, since one of our design criteria is near-instant revocation. How, then, do the group members obtain the new key without revealing their identity? We considered the following solutions to this problem:
We conclude that achieving total privacy is not worth the complexity, inconvenience, cost, or confusion introduced by any of the schemes above. Moreover, our discussions of completely private protocols proved them very difficult to verify, such that the system might advertise more privacy than was really there.
In contrast, our design provides a simple way to openly specify who one trusts. If a card reader is intended for moderately private use, one could consider running a private proxy that one trusts with user access information. For very sensitive access, one could set up a distinct server such that both the group contents and the access logs would be under local control. In all cases, group management and key revocation is done via straightforward use of a server's list structure. Cards are cheap and simple, storing only a single public/private key. Additionally, the use of proxies to cache group information increases the reliability of the system, as servers can go down without affecting the proxies, and card readers can try alternate proxies if their default one fails.
Finally, it is not clear that granting individuals complete privacy in their access to card readers is a desirable goal. In most cases, the administrator of a card reader is sharing some resource that he is responsible for-shouldn't he have the right to monitor how his resource is used? Moreover, if logging should ever become necessary, the system should be designed to accommodate that need without drastic changes. In these contexts, the flexibility of individual proxies to maintain different logging policies is a strength-not a weakness-of our design.
The obvious benefit of a card-based system over a mechanical lock-and-key system is that a card can act as a massive key-ring with many keys, saving the user the trouble of carrying a bundle of clunky metal. Also, if someone's card gets stolen, it is easier to maintain security by electronically revoking his permission to access doorways. In a mechanical system, one must change the physical lock and reissue new keys. Similarly, the general problem of keeping track of who can access a room is simplified using electronic access lists; one no longer has to track who has a physical key. Finally, card-based systems can restrict access to a specified portion of the day. With mechanical keys, the bearer can open a door at any time of day.
On the other hand, from a privacy standpoint a card-based system is more invasive than a mechanical lock-and-key system. The user of a mechanical key need not fear their activities being recorded since key use is completely anonymous. Also, keys can be issued to anyone regardless of whether or not they have an account on a given server, and keys can be copied and shared between friends without the explicit permission of a group administrator. Though in some sense these attributes are desirable, they are also hazardous to administrators who are trying to keep careful control over access rights. Since getting an account on a server is easy, and access lists specify precise delegation rights, we think that electronic cards are more appropriate than keys in this context.
Cost is also an issue. Doors with a small number of users (e.g., a specific office) may find it more cost-effective to use conventional keys. Doors with large numbers of users (e.g., the Media Lab's main entrance) could find a card-based system to be cheaper since the cost of periodic re-keying of physical locks may be prohibitively expensive.
A system following our design is capable of doing everything that the current MIT Card system can (with the exception of support for monetary transactions.) So from a functional perspective, the smart card-based system is at least as desirable. In terms of security and convenience, our new system is far superior to the existing MIT Card system. It aims to keep a user's activity private from a ``big brother,'' it keeps data secure between the card and a server, and it simplifies and decentralizes the process of access list administration.
The only theoretical disadvantage of our new system is that it is more expensive. Smart cards cost more than magnetic-stripe cards and smart card readers are more costly than magnetic-stripe readers. If we look beyond theory to implementation, we can see another disadvantage of the new system. The new system is more complex than the existing MIT Card system. Presumably, this increased complexity will lead to at least a few implementation bugs which could be exploited to reduce the system's security. However, given time and intense debugging, most of these bugs could be discovered.
We have presented a design for a simple, secure, convenient, and cheap smart card that would flexibly accommodate the diverse demands of the MIT community. Though individuals do not remain completely anonymous in their accesses to card readers, the presence of a proxy between the card reader and the server restricts logging capabilities to a trusted party. Additionally, the proxies provide a convenient means for enforcing auxiliary access restrictions, and they increase the reliability of the system by distributing the group lists and public key bindings. In all, the proxy substantiates a compromise between privacy and convenience that-coupled with secure communication protocols and flexible group management-represents a viable plan for the next MIT Card.
Saltzer, ``Topics in the Engineering of Computer Systems'', in preparation.
This document was generated using the LaTeX2HTML translator Version 98.1 release (February 19th, 1998)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -link 2 -no_navigation -show_section_numbers report.
The translation was initiated on 2000-07-15