Priya Agrawal
Neha Bhargava
Chaitra Chandrasekhar
Al Dahya
J.D. Zamfirescu
December 10, 2004
The MIT ID Card serves as a primary form of identification for all members of the MIT community. Advances in technology have made it possible to expand the functionality of the MIT ID Card over the years to provide many conveniences, including access to various facilities and the use of TechCash for purchases. However, these added comforts have come at a price: the security and privacy of MIT Card users. Technical problems - such as the theft of information on an MIT Card and the ease with which the card can be duplicated - have already been demonstrated, and seriously compromise the security of the card. The privacy of individual card-owners is at also a serious concern with the current card system, which has the ability to track users by keeping information on every transaction, including entries and exits to and from campus buildings. Our report aims to analyze how these issues affect the MIT ID Card system and the MIT population as a whole. In order to understand the system and the issues and concerns that influence it, we conducted interviews with administrators, faculty, lab directors, the police, and relevant committee members. To ensure student participation in the process, we conducted a survey of the student body to assess the awareness level, security and privacy concerns, and opinions of the current system.
Having studied the current system and policies, other available technologies and systems, MIT student body opinions, and the facts presented by and the opinions of other players, our group has identified several areas for improvement. Our recommendation can be broadly broken into three categories: technology, policy, and oversight. In terms of technology, we found the encryption offered by the current RFID system to be inadequate, therefore the widespread use of RFID technology should be shelved until the security of the system can be confirmed. Policy-wise, we have found MIT's current method of storing data on all card swipes with no restrictions to be excessive. We also find that the policy is not clearly stated and the cardholders are not appropriately informed. We recommend that entry data be kept only for those labs and dormitories who request it. In general, entries to public spaces will not be tracked; however, tracking of these areas may be turned on at the discretion of a committee we describe. Finally, we believe that an oversight board is required to ensure that access to information resulting from card use is regulated by a clear and easily available policy and that this policy is consistently enforced. This will ensure the accountability of those who can access the logs and the privacy of users, at the level decided by the oversight board.
In analyzing the MIT ID Card system we endeavored to follow three guiding principles in building a system that is beneficial to all users.Ê The first of these principles is the protection of privacy for cardholders. To the greatest extent possible, we believe that MIT community members should be free to use their card without fear of being tracked.Ê The second guiding principle we have followed is to maintain campus security. Therefore, while privacy is important we have also tried to remain cognizant of the fact that entry logging can serve as an important tool to combat crime on campus. Third, we seek to ensure that the MIT Card is both convenient and able to provide expanded services to cardholders. We believe that the expanded functionality currently offered by the MIT Card is of real value to the MIT community and should be maintained wherever and whenever possible. In many ways, these three principles are contradictory, with greater security often meaning less privacy and reduced convenience; our goal here is to balance the three competing demands and achieve an acceptable and maintainable equilibrium between privacy, security, and convenience.
This section describes in detail 2.1 the methodology of our research into the MIT ID Card and its associated privacy implications and 2.2 outlines what this report is meant to achieve.
Our main goal in studying the MIT ID Card system was to talk to everyone and get as many first-hand accounts as possible: we gathered opinions from undergraduate and graduate students via a survey, and we interviewed administrators, former administrators, the Card Office, Enterprise Services, MIT Police, lab heads, members of old committees charged with a similar mandate as our own, current members of the Card Advisory Council, vendors of the current system, a few faculty members, and a few generally outspoken members of the community. In addition to our primary sources, we also consulted a number of secondary sources: Tech news articles, system specifications, IS documentation, internal websites. We used these articles as launching points from which we found a number of faculty members, administrators, and committee members with whom to speak.
In order to discover how the student body feels about the MIT ID Card and its associate policies, we conducted a survey over a period of one month beginning November 1. We advertised our survey on the undergraduate dorm mailing lists, which combined reach a very large fraction of undergraduate students and also many graduate students. We also advertised our survey to certain graduate dorm lists, and also one or two ILG lists, but it is safe to say that our survey as a whole represents more the opinion of undergraduates living in dorms than any other particular group: of 513 respondents, 63 do not live in on-campus dorms, and 403 had not spent any time as graduate students (i.e., were undergraduates). The principal reason for this skew in representation is distributionary, and unfortunate: neither the Inter-Fraternity Council nor the Graduate Student Council replied to repeated requests to forward our survey to their members.
Our survey was online, available at http://privacy.mit.edu; it took on average 5-10 minutes to complete, and consisted of 9 ``main'' survey questions, 4 demographic questions, and a comments box. We offered respondents to leave their username to enter a drawing for a $20 gift certificate for one respondent, as an incentive for participation. We justified this incentive by realizing that we were more likely to hear from students who did not have a very strong opinion on the matter if we included an external incentive.
The default response for all questions was ``decline to respond'' (and an empty box for the one main question that involved text entry). All questions were optional, and 18 respondents declined to respond at least one main question. An additional 60 respondents declined to answer the one main question that involved text entry;1 the other 8 main questions involved only selection from a menu.
We were interested to know whether students knew that the MIT ID Card contains an RFID chip in it, and whether they were comfortable with it. We were also interested to know how students felt about the current policy of keeping logs of entry data. Finally, we were also interested to know student opinions on some of the policies we were considering recommending.
Appendix A contains a full copy of our survey as it was presented, as well as a description of the distribution of responses for each question. The conclusions we drew from the results of our survey are spread throughout the rest of the report.
To find the opinions of the various groups on campus who might potentially have an interest in the MIT ID Card, and in order to be able to take their thoughts into consideration in our report, we conducted numerous interviews with community leaders:
Current and Former Administrators
Faculty
In addition to the faculty mentioned above, we spoke with:
Lab Directors
MIT Police
System Vendors
Committee Members
In addition to those committee members listed above, we spoke with:
Members of the MIT Community
In addition to the people we spoke with, there are a number of community members we wanted to speak with but were unable to: Chief of Campus Police John DiFava; any members of the former Card Steering Committee; and any members of the former Card Privacy Committee. We were able to find almost no information beyond a single Tech article on the Card Privacy Committee. It is possible that this committee did not exist, and was merely proposed, or that it simply produced no discussion or recommendations.
Our report contains three foci: a description of the current system, including limitations and flaws; a description of the ideal system; and necessary changes to the current system that can be implemented at low cost. Our recommendations throughout are heavily influenced by the individuals we spoke with and take into consideration to the greatest extent possible the differing views of all parties with interest in the MIT ID Card system.
We present a thorough history of the current MIT ID Card system, as well as a discussion of the technical flaws and the questionable practices and policies currently employed. The current system is imperfect in many ways; we identify these ways. We also consider input from as many campus groups as we have spoken with to discover their opinions of the current system and how it might be changed.
We also present a recommendation for the ideal future system. Our system addresses as many of the technical flaws of the current system as we believe is possible with currently available technology. Our technical recommendations are heavily influenced by our policy decisions, which we believe will result in a system that is acceptable to as many members of the MIT community while still within the bounds of implementability and while being useful to those who require the information available by virtue of having a campus-wide access system.
We are not blind to the fact that any new implementation will take a substantial amount of time, money, and effort. Many of the administrators we spoke with were not optimistic about the likelihood of an entirely new system being implemented from scratch, especially since many of our ``ideal system'' recommendations are not being offered by vendors as an off-the-shelf solution. To address this problem, we present a set of changes we believe is it imperative be applied to the current system to address our serious privacy concerns.
Historically, MIT had used a person's social security number (SSN) as their primary identifying number across MIT systems. In fact, the SSN would be the ID number that appeared on an MIT identification card. However, as more records were stored on computer systems and access to these systems become more widespread, concerns about privacy became more acute. The use of a person's SSN as the common institute identification number was quickly singled out as being both dangerous and unnecessary. In response to these concerns, the Institute began to restrict use of a person's SSN, declaring it part of a person's personal data and thus protected by the MIT policies on privacy and disclosure of information. In tandem, MIT's Data Administrator, Scott Thorne, issued the Tech Info document ``People Related Projects: 37707'' to MIT Information Systems on August 17th, 1994. The document outlined the creation of a new common MIT ID numbering scheme and the system to support the lookup and assignment of this ID.23
According to the initial 1994 document, the MIT ID required the following four attributes:
In August 1995 development of the central computer system necessary to support the new MIT ID was completed and over the years this ID system has been adopted by the following campus groups:
Concurrently with the developments of the MIT ID, the Institute was also endeavoring to create a more flexible and useful ID card. On September 29th, 1993, MIT started experimenting with consolidating the functionality of its meal card and ID card. The new ``student services card'' was to be the first phase in a process that, as then Director of Housing and Food Services Lawrence E. Maguire put it, would create a ``one-card system that [met] the fundamental needs of the Institute as a whole [for] identification, access, and purchasing.'' [5] The process initially went through some growing pains as a proper system was fleshed out that would allow ID card, meal plan access, door access, and other functionality to exist on one card. In fact, the 1993-1994 academic year almost seemed comical to MIT students as they were issued no fewer than three cards over the course of the year. A column in The Tech perhaps best summarizes the incredulity that some regarded MIT's attempts to create a new card. In columnist Mark P. Hurst's self-styled ``Cards in Review'' he notes that:
In September we all affixed our registration stickers to our Old Card, the ID card we've used since freshman year. Magnetic stripe, photo, and a spot for the athletic sticker.
Things soon got better when we got the New Card (at this point, the ``Old New Card''). This winner had the notable improvements of not containing a photo, registration sticker, or athletic sticker. The Old New Card was much better than the Old Old card, since it could be used for unlocking some doors some of the time (for mine, none of the time) and for buying lots of overpriced food on its New Magnetic Stripe. It also had the value added service (for you ARA types, a ``Val-U-Service'') that students could use stolen Old New Cards without that hassle of photo identification.
Jump to the present: the New New Card. It has a New New Magnetic Stripe, which can be used to open more doors more of the time, and a New Photo, which is really an Old Photo, having been taken from the Old Old Card, but no athletic sticker, which is still on the Old Old Card. So if you want to buy an overpriced lunch and then work it off in the gym, you have to carry the Old Old Card and the New New Card.
...You may be saying to yourself, ``The real reason we got three cards this year is because we're in a transition period to a new card.'' Could be, but can't we have foresight of more than a week to cut down on new versions of the same old magnetic stripe? Besides, next year won't be much different. Look at your New New Card. On the front is an expiration date - in September. That's right: get ready for the New New New Card next fall. The fun never ends! [15]
As Hurst astutely noted, the next installment in the evolving MIT Card was issued towards the end of September 1994. The new card endeavored to combine the various functionality of the many cards from the previous year. In this case, dormitory access, parking access, meal purchases, and library card services were all included in one card. A feature new to this card was the introduction of a declining balance account that allowed students to make cash purchases using their ID card. This card was used for the entire year and is the first in the line of cards now known at MIT as the MIT Card.
From early in the process it was noted that security and privacy issues would dominate the introduction of this new MIT Card, however for the first few years little was done to formally address these issues. On November 3rd, 1993, the Undergraduate Association (UA) appointed a task force to investigate privacy, security, and convenience concerns surrounding the introduction of the proposed MIT Card. Also as early as 1993, the different offices within MIT that were planning on making use of the new MIT Card began stating what policies they would be following regarding the usage data that would become available to them. Assistant Director of Housing and Food Services Kenneth R. Wisentaner told The Tech that despite having the capability to track student use of card readers to gain access to MIT buildings, there was no intention of actually using this feature. Chief of Police Anne P. Glavin reported that parking lot usage data would be recorded and stored for 2 years for parking and traffic enforcement and for long range planning. Finally, Wisentaner noted that meal transactions would be stored for about one academic year. [6]
In this mess of policy declarations and preliminary investigations by the UA, it is very striking that no overarching body was acting to coordinate and oversee the creation and implementation of privacy and usage polices for the new ID card. At the time, no committee existed whose mandate specifically covered the MIT Card and its associated policies; instead, all privacy issues fell under the purview of the Faculty Committee on Privacy. However, as if to exacerbate the existing problem with lack of oversight, the Committee on Privacy ceased to meet between May 1994 and November 1995 because there was no one to act as chair of the committee. What is more, as observed by Amy S. Bruckman - then Graduate Student Union (GSU) representative to the Committee on Privacy, the committee itself ``had no authority or resources, and its recommendations were often ignored or laxly enforced.'' [17] This lack of cohesion and oversight is apparent in an anecdote recounted by Bruckman. According to her, a few months after use of card swipe access to dormitories was activated, a student called the security guard of her dormitory to report that her card was not working and had never worked. The security guard, in response to this complaint, responded by saying that indeed the card did work because it was used to gain access to some building X at a previous time. In the end, it turns out that, despite the assertion by the Office of Housing and Food Services that it would not be tracking students, they had forgotten to switch off the tracking feature on the system.
During the early phases of the introduction of the MIT Card, privacy took a back burner to the sheer number of complications that surrounded the implementation of the new ID system. It was not until 1995 - after the new MIT Card was better established - that serious attention was drawn to the security and privacy implications. In September of 1995 MIT issued yet a new ID card. The new MIT Card's biggest change was that it no longer displayed the student's SSN, instead using a randomly generated ID number created using the system proposed and implemented by MIT Data Services. This marked the convergence of the programs to develop a more private MIT identification scheme and a more functional ID card. Also of important note, this new ID card was, for the first time, issued to MIT employees, thus replacing an older ID issued by the Personnel Office.
Very shortly after the introducing the new ID card for the 1995-96 school year, Senior Vice-President William R. Dickinson announced the creation of the MIT Card Steering Committee. The committee had no standing agenda and was instead tasked with addressing any issues regarding the MIT Card as they arose. One of the first issues that came to the forefront of attention was the security of data contained on the MIT Card's magnetic strip. It was realized early on that, if someone could gain access to a person's ID card, the information stored on the card could be easily read by any card reader and used to steal the person's identity. On March 28th, 1995 André DeHon published a paper entitled ``Security Assessment of the M.I.T. Card.'' Through the course of this paper, DeHon proceeds to make an argument that that ``the level of security provided by the card is laughable.'' His analysis walks through several scenarios in which an ID card could become compromised and ultimately leads to several recommendations that essentially suggest that the MIT Card was not sufficiently secure to be trusted for use with financial transactions. [7]
On the heels of DeHon's paper and the controversy it caused, the Office of Housing and Food Services instructed that the MIT Card should no longer be used as collateral for items loaned to students. This referred to the common practice of requiring a student to give their card away whenever they took items, especially from dormitory desks, on loan. When the student returned the borrowed item, they were given back their ID. The main concern here was that while a student's card was held as collateral it could be read by a rogue reader and its information stolen.4 In possession of information stolen from an ID card, a person could create a new card and make purchases or access restricted areas under this new identity. In response to questions about DeHon's report, Associate Director of Food Services John T. McNeil noted that, ``We [at the Office of Housing and Food Services] were certainly aware of the faults that [DeHon] points out. I don't really know of a system that would be foolproof.'' Carrying on, McNeil states that, ``we knew [when] putting [the new MIT Card system] together that the system is only as good as the people who use it. We were aware that copying was a possibility, but really it's a felony to do that.'' In many ways, McNeil's reaction summarized the sentiment at the time. Yes there were legitimate concerns and yes the card system was not perfect; however a lot of time and money had been sunk into the system and, frankly, it would be impossible to develop a perfectly secure yet convenient and flexible solution for the MIT ID Card. Therefore, faced with this reality it seems that the overwhelming choice was to go forward with the system on hand and accept the increased risks as the cost of having a more functional card system. [8]
This is not to say that no effort was made to improve the security of the MIT Card. In fact, the Office of Housing and Food Services took some of DeHon's recommendations to heart and made some of the technology changes he suggested.5 In fact it could be argued that it was DeHon's paper which prompted then Dean for Undergraduate Education and Student Affairs Arthur C. Smith to instruct that a committee be created to oversee the MIT Card. It is as a direct result from this request that the MIT Card Steering Committee was formed. However, as time progressed and the new MIT community became more familiarized and comfortable with new ID card, these questions of security and privacy again fell from the focus of people's attention.6
For the next couple years following 1995, few major changes were made to the MIT Card and controversy over the card fell to a minimum. At the onset of the 1996-97 academic year uses for the MIT Card included: identification, meal plan access, library book borrowing, access to dormitory entrances, entry to parking lots, and access to various buildings across campus. At this point time, Maguire characterized the services offered by the MIT Card to be in the ``upper middle'' segment in comparison to those offered by other schools; and while other ways to expand the MIT Card were being explored, nothing firm was in the pipeline. Also in 1996, MIT changed its policy on the expiration of ID cards. Prior to 1996, cards were valid for only one year and were replaced each September; however, in order to cut back on printing costs, card expiration was extended to a four year period.
The 1997-98 academic year occurred without major event for the MIT Card, but in the summer of 1998 a major reorganization of both the Office of Residence and Campus Activities and the Department of Housing and Food Services led to the creation of an independent MIT Card Office. The new MIT Card Office reported to the Dean of Students and Undergraduate Education and was to be headed by former director of Housing and Food Services Lawrence Maguire. From this point forward, the MIT Card Office became responsible for development and expansion of the MIT Card system, distribution of ID cards, and maintenance of MIT Card infrastructure and software.
During the summer of 1999, the MIT Card office began an upgrade of the MIT Card system. The upgrade occurred in two parts, the first occurring in the summer of 1999 when the card office installed Diebold Corporation's CS Gold application.7 The next phase involved the installation of a Windows NT server and porting over to an Oracle database and would actually not be entirely complete until the 2001-2001 academic year. With an estimated price tag of $350,000, this purchase represents the largest change to the MIT Card system since the upgrades it under went from 1993 to 1995. [9]8
In 2001, the MIT Card office moved again within the Institute to fall under the supervision of Director of Enterprise Services (headed by Steve Immerman) of the Office of the Executive Vice President. Along with this move, a three person team was commissioned to study the existing MIT Card Office and MIT Card. Led by Interim MIT Card Office Director Kirk Kolenbrander and with Greg Anderson and Matt Brody from MIT Information Systems, the team researched practices at MIT and at universities across the United States and concluded that the MIT Card Office was outdated and irrelevant to the MIT community. According to the MIT Card Office 2000-2001 report to the President, the team established the following principles to guide the policies and structure of the office:
The full set of recommendations made by the team was compiled into a report which was then adopted by the Dean for Student Life, Vice President for Information Systems, the Director of Facilities, and the Director of Enterprise Services. Final approval for the recommendations in the report was given by the Executive Vice President and the Chancellor. [10]
The period of 2002 to present the MIT Card Office has overseen two interrelated efforts in addition to the implementation of the recommendations from the report adopted the previous year. These were a push to ``effectively and efficiently absorb some of the smaller, independent card access systems on campus into its campus-wide system;'' and to make the jump to proximity access technology for the MIT Card. [10] The effort to absorb other card access systems came from both the belief that a single ID card controlling access to all campus facilities was preferable to multiple disparate systems and the successful completion of upgrades to the MIT Card system which gave it the capability to handle an expanded system. To realize this ambition, the Card Office went to the various groups on campus and pitched the idea of using the MIT Card for their access requirements. The concept was extremely well received and, according to the current Director of the MIT Card Office Dan Michaud, at present the 34 locations have MIT Card client stations installed with over 20 to be deployed before next spring.9 As a result of the extremely strong response the MIT Card Office received to this new program, it was forced to reevaluate its policies for privacy and security. Acknowledging the wider impact that any decision made by the MIT Card Office would have on the MIT community, a special committee, dubbed the MIT Card Advisory Council, was convened in 2002 to help develop policies and procedure for the MIT Card. The council is still in existence and is comprised of representatives from the MIT undergraduate and graduate population as well as key players in the MIT faculty and staff.10
The other big initiative for the MIT Card Office was the rolling out of MIT Cards equipped with RFID chips. According to Michaud, the addition of RFID technology came largely at the behest of MIT labs who were interested in expanding into this technology. There are few firm justifications for using this technology except that it is a new and interesting toy. The most compelling reason for RFID technology is that it will save on maintenance costs because readers and cards are less likely to be worn down. The new cards are rolled out in the summer of 2003 and the newly minted STATA center is equipped with proximity card readers. The use of RFID technology drew quick outcry from members of the MIT community who questioned the security of such a system, one of the most outspoken of whom is Richard M. Stallman, founder of the GNU project and now resident in building 32.11 Stallman questions both the security of RFID cards against rogue readers and the dangers to privacy that could arise from tracking RFID cards. Despite the concerns raised by community members, RFID chips are now included standard within all cards issued by the MIT Card Office.
Perhaps, the final important event that brings us to the present state of affairs is the summer 2002 decision by the MIT Card Office to activate the tracking feature of the MIT Card system and keep logs of all card access incidents for a period of two weeks. The decision to start tracking was done without notification to members of the MIT community. News of this change in policy was finally released to the MIT community in a January 29, 2003 article in The Tech. According to both Daniel Michaud and John McDonald, Associate Director of Enterprise Services, the decision to enable tracking was made in response to requests from a large number of labs and departments for such a feature if they were to use the MIT Card system for access control. According to McDonald, when Enterprise Services took a survey of groups across campus on why they had bought their own access systems the three most common replies they received were: audit logs, local control over doors and people with access, and the ability to use proximity readers. Therefore, the move to enable tracking was part of the larger program to attract these groups to use the MIT Card system. At its own discretion, the MIT Card Office implemented its own policy governing access to tracking logs. This policy stated that all logged data would be kept for a period of two weeks and would only be accessible by written request from MIT Chief of Police John DiFava. To date, logs have been accessed in only a handful of instances in response to thefts and missing person cases.
Thus we arrive at the current state of the MIT Card, MIT Card Office, and all associated policies. The evolution of the technology, vision, and policies guiding the development of the MIT Card has been far from perfect. However, what we now find ourselves with is a system that provides many conveniences upon which we rely and, in fact, expect. Many questions have been raised over our ID, and perhaps only a handful of these questions have even been answered; however, many people to whom we have spoken view the development of the MIT Card as a tradeoff between the cost of action (lessened privacy, security, and identity theft) and the cost of inaction (decentralized and expensive access control across campus and few conveniences for cardholders). It is many of these unanswered questions that we endeavor to answer in this report and we hope to provide reason and guidance for the further evolution of our MIT Card.
The current policy for the MIT ID Card is a result of multiple policy changes over the years, which were outlined in great detail above. The current system tracks all types of entries from all locations on campus, including in the classroom buildings on the main campus, dormitories, and laboratories. The current magnetic stripe system does not record failed attempts, which will be described in the Tracking section below, to enter a building. It should be noted in reference to this blanket tracking policy that according to Daniel Michaud, the head of the Card Office, the current technology system of the card can only support tracking all entries at all locations or recording no entries at all locations. All of the data is then stored in the system for viewing by the gatekeeper of the data two weeks after recording.
The data that is recorded is under the control of the head of the Card Office. There are three other employees of the office that are also able to access the information freely. According to the MIT ID Card policies that are posted online, the tracking information will only be used for trouble shooting and police investigations. [18]
The troubleshooting occurs at the Card Office by the employees. As far as police investigations, the chief of Campus Police, currently Chief John DiFava, must send a signed written request to the head of the Card Office to obtain any tracking information. No other outside group is allowed to request the data.
When an access to this data occurs, then there is a log that is updated to record who viewed what data at what time. The current system does include a log that could be used for auditing information. This computer also includes the log files of who has accessed the database. However, it is speculated that Mr. Michaud leaves his account logged into his computer during the day for other employees to use the database system. Aside from the speculation, the log is also useless for auditing the head of the office if he can easily delete any evidence of accesses that he has made of the data.
The tracking policy in terms of uses, locations, length of record storage, and who has access to the data is all available online at the card website. There is part of the policy that is not readily available to the public, which is the information regarding the Card Advisory Council. This body meets quarterly to review and advise on current and potential policies regarding the MIT ID Card. Current members of the council include Dan Michaud, Assistant Deans from several different offices, and representatives from the Faculty, Graduate Student Council, the Undergraduate Association, MIT Campus Police, MIT Enterprise Services, Athletics, Human Resources, Registrar's Office, Alumni Association, and MIT Libraries. Overall, the current policy has its strengths and weaknesses that will be discussed in depth below.
There are several major changes to policy that we recommend for the current and future MIT ID Card system. Our most urgent recommendation for the policy surrounding the card is that those recommendations that can be implemented with the current system technology should be implemented as soon as possible. These recommendations include the implementation of an auditing policy, and changes in who the gatekeepers are for the access log.
The policy changes we recommend are:
FERPA, also known as the Buckley Amendment, allows for students above the age of 18 to access educational records kept by educational institutions. For post-secondary information, these rights to access are passed solely to the student if he or she is over 18 years of age. Students are entitled to view their educational records within 45 days of making such a request to the institution that keeps these records. Disclosures of information to third parties by the educational institution can be done only with student consent with some important exceptions. These exceptions include disclosure of information without student consent to ``court subpoenas, requesting information, federal audit requests, law enforcement requests regarding missing students, and requests from health departmentsÉappropriate parties in connection with a health or safety emergency if knowledge of the information is necessary to protect the health or safety of the student or other individuals.'' [20]
The FERPA laws apply to all public institutions and those private institutions which receive public, including MIT. Much of the financial aid that students receive at MIT is through federal funding, and many of the research programs on campus are also funded by the government. According to Professor Arthur C. Smith and Danny Weitzner, tracking data that MIT records is considered to be educational data, and is subject to the guidelines of FERPA. MIT and the tracking data it maintains are then subject to the rules of FERPA because MIT is a partially government funded private educational institution. In our policy recommendations, we will adhere to the guidelines that FERPA lays out for the usage and disclosure of educational information.
In addition to the disclosure rules outlined in FERPA, we have strived to adhere to the Fair Information Principles of the U.S. Department of Health, Education, and Welfare. These five principles that guide the legislation enacted by these departments were developed in response to the computerization of medical records and a desire to maintain the privacy of the public in light of new technology. These principles are:
The CORI Laws are state laws intended to protect the privacy of those who have criminal records when those records are accessed by other parties. These are laws that MIT police must follow when attempting to access anyone's criminal record for investigative purposes, and surely serve as a reminder of the kinds of privacy protections that students are entitled to in light of the protections guaranteed to those with criminal records. The penalty for non-compliance with the CORI laws is a $10,000 fine, or 1 year in prison for offending officers, according to Detective Jay Perault and Lieutenant Albert Pierce of the MIT Campus Police. The laws set an important and high standard for police actions when accessing the personal records of any person including the tracking data of students.
Based on these principles and laws, it seems that much of the data that is recorded by the current system falls subject to FERPA and should be that policy formulations should adhere to the Fair Information Principles, as they are national standards for privacy protection. Tracking data is identifiable data in that card swipe data can be traced back to the user of a card given the right records of id numbers. Although the state and federal realms contain many laws concerning the protection of privacy, and accesses to state and federal records, such rigorous processes do not exist within the confines of MIT. The following policy and technology recommendations were created by taking the guiding principles and model laws from the state and federal domain into account. It is our goal that the following recommendations, if adopted, would prevent theft and other crimes while preserving a high level of privacy protection. An attempt has also been made to keep the policies as straightforward as possible so that they are accepted by the entire community as logical and necessary policies and not as cumbersome processes designed to make simple tasks relatively difficult.
When an ID card is scanned by a card reader, one of three things can happen: the reader identifies the card as valid and grants permission to the specific location, the reader identifies the card as valid but denies access to the particular door, or the reader fails to identify the card as authentic. These different scenarios occur depending on the card owner's access privileges and if the reader is functioning correctly. If the user does not have permission to enter and the reader is working correctly, the attempt is called a denied entry. The second type of entry, where the reader is not working properly, is a termed a failed attempt and does not depend on the status of the user. If the card owner has permission to enter the building, the reader is working correctly, and the user is allowed in, the access is a successful one. These three types of attempts to enter create three different categories of data that could be handled differently in recording.
Another use of recording denied entries is to monitor individuals trying to gain access with ill-natured intentions. Depending upon how the specific tracking data is pinpointed in the database, the level of usefulness for crime investigation varies. If the Campus Police are investigating a crime and find numerous denied entries in the record close to the time of occurrence, the data could help the police find a potential suspect. On the other hand, if the Campus Police find the information ``accidentally'' while aimlessly looking through data, then this would be a breach of students' privacy rights. According to Pierce and Perault of the MIT Campus Police, the data with a user identifier attached should be stored for shorter periods of time to reduce the possibility of ``fishing'' for data. Additionally, shorter periods of time would lessen the ability of the database administrators to browse through data as a past time, since it would be there for less time. If the Campus Police look through denied entry data randomly, the user identifier will hurt the privacy rights and a lack of identifier would therefore be preferable. However, the privacy rights can only be upheld if there is an effective database access protocol, which will be discussed in the Database Access Section. If there is proper security of the database and the administrators do not use it to ``fish'' for data, then the user identifier on denied data is not a problem. The two cases have one key component that differs: the reasons of why the data administrator found the data.
In general, if denied entry data is stored with a user identifier, then it should only be investigated when there is a specific reason, such as a complaint from a card user of a system failure or a crime investigation. Assuming that the data access is properly restricted, then denied entry data should be recorded at all locations.
If there is a broken reader, then the record of failed entries would be extremely useful in finding a problem. The system could keep track of the number of failed entries in a certain location over a certain time period. If the number of failures exceeds a certain limit, then a warning could be raised to the database administrator to warn of possible card reader failures. A further discussion of a possible alert system appears in the Data Access section later on.
The other possibility is an outsider attempting to break into a building on campus. However, a large number of failures at the same reader has higher chances of indicating, is a hardware system problem rather than an ill intentioned outsider. Regardless of the cause, the counter for number of failed entries would still be triggered in the case of an outsider and warn the database administrator of a possible problem.
Failed entry data should be kept for a long enough period to allow the database administrator to discover a problem. Hence, the data must be kept long enough such that on a normal basis, if a card reader was not working at a certain location, then enough failed attempts would accrue and warn the administrators of the database. Keeping this data for too long does not pose a privacy threat, since it does not have any personal information identifiers, but rather only a time stamp and location.
While considering solutions for fulfilling the above requirements, a few principles need to be kept in mind Ð campus security needs and individuals' privacy rights. The policy created needs to provide the optimal amount of data for use in a crime investigation. At the same time, the recording of this data could infringe on the privacy rights of students, faculty, and administration. Individuals with access to this data could potentially use it for inappropriate reasons, such as monitoring the number of individuals of a certain demographic that enter a building at a certain time or to track the whereabouts of a certain person.
Due to the possible contradicting goals, each potential solution will need to be evaluated in terms of how well it fits each motivation and in turn how well this fits the needs of the campus. In particular, the policy of the successful entries in the tracking system focuses on location of tracking and lifetime of records.
According to Lieutenant Albert Pierce and Detective Jay Perault of the MIT Campus Police, the data currently recorded by readers at building entrances is useful in their work, though how it is used varies by case. In general, they were not able to inform us of how the data is used or how frequently it is used due to the confidentiality of investigations. However, they did mention that the information is very useful in the cases of missing students, since the information helps to recreate where and when the individual has recently been. The data garnered from tracking could be useful to prove an alibi of an individual's location or to piece together information about a crime, such as witnesses or suspects. The representatives of the Campus Police did mention that the tracking records merely suggest possibilities, rather than using the data as stand alone evidence, that need to be verified in other ways. In relation to the privacy issue, a survey of the student population indicated that two thirds of the individuals were not opposed to tracking, if the data was kept for a reasonable time period, if they were aware of it beforehand. In conclusion, tracking could occur without excessively infringing on privacy rights, if the lifetime of the records and access to the records, which will be discussed later, are properly restricted.
While tracking is important to the MIT Campus Police for investigation purposes, it can possibly jeopardize individuals' privacy rights. The stored data could be looked at by authorized individuals, but for inappropriate reasons. Authorities could look through the data for entertainment or look specifically at people of a certain demographic. These possible misuses hurt the principal of student privacy rights that should be upheld. Therefore, tracking at any locations would be possibly harmful to privacy rights. Furthermore, the tracking data is not always helpful for solving crimes. For example, currently, according to Lissa Natkin, the Assistant Director of CSAIL, most thefts from CSAIL occur during hours when the card is not needed for entrance. This fact indicates that there are problems in the security system of the building and not a result of a problem in the current card system. Therefore the tracking could not have helped solve these crimes. Though this may be a more specialized case, it shows that while the tracking records do offer the possibility of greater security and investigative power, tracking and investigative power do not always correlate.
Another possibility is to track only at specific locations, especially where more expensive crimes can occur and the privacy rights are not as problematic. Laboratory areas with expensive equipment would not have the same sort of privacy rights associated with them as more personal spaces such as dormitories. In this way, tracking could vary throughout the campus depending upon need.
According to Lieutenant Pierce and Detective Perault of the MIT Campus Police, theft is a big problem at MIT since the members of campus are very trusting of others and do not always lock up their possessions. Theft is a bigger problem in dorms, where students often leave their doors unlocked, and in labs, where there is very expensive equipment. To this end, tracking could be helpful in assisting in crime investigations and should be performed in dormitories and laboratories.
As Former Dean of Harvard College Harry Lewis suggested, this scheme presents a few problems. It would lose some of its potential use and be more complicated than a uniform policy. Professor Lewis pointed out that individuals on campus should be fully aware of the policy and would then be more likely to approve it if it is simple and the same for all locations. However, the proposed policy is simple enough such that individuals can easily remember it and if the policy did get more complicated, then some sort of picture icon could be placed next to each reader that tracks the card swipes.
Lifetime of Data Record
The data recorded by the system when a card is read can be kept for a variable amount of time Ð never, eternally, or a limited amount. The different lengths of time would provide different amount of utility to the police force as an investigative tool and still protect privacy rights. Not recording any data would be the same as tracking at no locations, which hurts the police from gathering possibly valuable information about future crimes but at the same time protects privacy rights. This issue was evaluated above in the same regard as not performing any tracking, which was decided to not be optimal for security reasons.
On the other hand, if the data is kept eternally in the database, then the police would be able to utilize the information maximally. If they needed information on who was at a certain location at a certain day and time, it would be useful to simply look at the records as a starting point. The Campus Police expressed the important role that the tracking data is able to hold in investigations. For police utilization, the data should be recorded and kept. However, if the records are kept indefinitely, then the problem of inappropriate usage becomes more severe. If authorities have access to unlimited amounts of tracking data, then it is a privacy threat. Individuals may fear that the people holding these records could use it for ``Big Brother'' type of activities. While eternal recording of data could be more useful to police, it threatens to infringe on the privacy rights of individuals.
If the record was kept for a limited amount of time, then a balance could be reached such that all of the principles of security and privacy were optimally upheld. The longer time period allows for better utilization of the records on the part of the Campus Police. But the shorter time period helps protect the students' rights for privacy. Lieutenant Pierce and Detective Perault of the MIT Campus Police explained in an interview that the current limit of two weeks was set such that it prevented authorities from ``fishing for data'' or monitoring an individual's records without specific reason. Student opinions from the survey showed that most individuals were comfortable with the current policy of holding the data for 2 weeks. It also showed that these one third felt unfavorably towards tracking was because of the amount of time that the data would be stored and these individuals were in favor of keeping the data between two and seven days. However, this short of a time period would probably drastically decrease the value of the records to the Campus Police. Therefore, the recommendation is to keep the data for a two week period.
There are a few ways of implementing the policy such that all of the members of campus will be aware of the policy and be able to find it when necessary. The members of campus should be aware of the policy from the time that they arrive. One way is to give out a flier in the welcome packet when a new student, faculty, or administrator joins the campus. This will help make all individuals aware of the policy. However, a person may lose it during their years at MIT. For this reason, the policy needs to be available by some other route, like the web. The web would make the information easily accessible to campus members at any point in time. Public awareness of the policy is important to help protect privacy rights of people on campus.
An efficient access protocol should be created, while still trying to uphold the keystone principles, particularly, protection of student privacy rights and efficiency of investigative security tools. Access paths should be created only when there is a specific reason. If the tracking data is accessed by unauthorized individuals, then there could be numerous security issues and the privacy of the students would be compromised. Deciding which individuals should have access to which types of information and how they access it depends upon their role on campus.
Facilities
The tracking of ID cards can be useful for facilities to learn about the traffic patterns in certain buildings. This data can be useful for a department to figure out cleaning schedules, estimated amounts of traffic, and other such information from data regarding the number of people that accessed a building by using a card reader. This information, however only requires knowing how many people used the reader and at what time. It does not require any other sort of demographics, such as sex, race, or class. Any extra information that is given, but is not pertinent to performing the project at hand, could perhaps lead to misuse of data. For this reason, it would be better if this anonymous data that was completely stripped of all identification data was available to facilities.
On the other hand, this data could potentially be used for supervisory purposes. For example, suppose a worker is supposed to be at his job at some exact time and other people very rarely enter this building around that time. If the anonymous tracking data is available to the facilities head of a lab and subsequently the boss of the worker, the boss might be able to tell exactly when the employee arrives to the work location. The card tracking system should not be used for these purposes. Very precise information regarding the number of individuals that entered at a certain location at a certain time is unnecessary to the purpose of analyzing traffic data.
Yet, this anonymous tracking information could be helpful to the facilities department in their work. Calculations could be made from this data such that it has lower resolution. For example, one way to lessen the precision of the tracking information is for facilities to specify a twelve hour period of the day. The data for this twelve hour period is averaged for the last two weeks and then rounded up or down to the nearest integer person per twelve hour period. This type of formula would make it harder for a third party to make stipulations regarding the whereabouts of specific individuals, which protects the privacy rights of the card users, but at the same time, it helps illustrate the traffic patterns in a certain location.
Card Office
The main function of the Card Office is maintenance of the card system, which includes proper functioning of all of the readers and successful access to the correct locations for individual card holders. The employees of the office need information to pinpoint broken readers. For example, if a reader is not functioning properly in a certain building, the problem will not be found until the office is alerted by an individual that tries unsuccessfully to gain access at this location and calls the office to let them know of the failure. Then one of the Card Office employees that have access to this data can find the information. Since viewing the information is currently not restricted, the employees could look at other recorded data while looking for something specific. This presents another possible situation of infringement of privacy rights.
The worker at the Card Office should be able to use his own computer to check how many failures have occurred or if there have been any successful entries in the past few hours. The workers of the Card Office are supposed to make sure that the system is running properly. This does not necessitate the worker knowing the identification of the card users unless it is in regards to a specific individual card holder. In this case, the student, faculty, or administrator would be present at the Card Office and could give permissions to the employee to view his or her account at the time of trouble shooting. More information on student access rights is in the later Student Access section of Personal Data. The Card Office employees can fulfill this role with regular access to anonymous tracking data.
Furthermore, there are certain card trouble-shooting situations where other solutions could also provide quicker solutions. When a reader to an entry is broken, then attempting to use a valid card may result in a failed entry. If the reader remains broken, then more individuals will attempt to use the reader to gain access and more failed attempts will occur. The database is already recording these failed attempts, so the information should be used. An automatic counter is recommended that alerts the maintenance team when a broken reader is suspected. The automatic nature is important in that if the system is able to check these possibilities internally, then there is no human contact or possibility of privacy rights infringement. This counter could base its alert system on the proportion of failed entries versus successful ones or the number of failed entries that have occurred over a set period of time. Setting these tolerances at reasonable values will quicken the process of pinpointing and fixing broken readers, while not encouraging Card Office employees to casually search through campus members' personal tracking data.
While considering these possibilities, only one gatekeeper of certain information should be picked. A second gatekeeper would add a layer of security to the system, but it will also make the system more inefficient. The second gatekeeper would need to be an individual on campus that has student's interests in mind, such as faculty members or deans. Deans, for example, work on a daily basis on confidential student matters. However, the police may need data quickly for a time sensitive issue and making it mandatory that one of these individuals be present for any data access would slow down the process greatly. A quicker and more efficient option is to rely partially on an efficient auditing system, designs of which will be further discussed in the Auditing section below. If there is only one gatekeeper and a good auditing system, the security still remains intact and efficiency high.
Student Access
Students may need to demonstrate to the Card Office that they are experiencing a particular problem with the functioning of their card. Currently, when there is a problem of this sort, then one of the three employees with access will look up the information and act accordingly. With the current recommended architecture all Card Office employees except for the head have the permissions to only access the anonymous data. With this setup, students should have access to their own information. If the students hold the privileges to their own account, their privacy is protected the best. On the other hand, if desk workers at the Card Office have access to this information, it would be easy to track a student and follow the student's routes. Furthermore, if the student realizes that they can access their own data and the desk worker cannot, the students will trust the system more to uphold their privacy rights. The easiest authentication method for students would be to require entry of their Kerberos username and password. The Kerberos password is already secure enough to do other transactions that require privacy and it is already in place. The student being able to access their own information is important to protect privacy and maintain any principals that were put into place from all of the other sides of policy.
One reason that we have to provide information to students is that it counts as educational data. This kind of information must be provided to students under the Family Education Rights and Privacy Act (FERPA). There are a few ways to provide this information in an easily accessible, but in a secure and efficient way. One possibility is to offer it on Websis, where private academic and financial information is stored for students to view. The Websis system is fairly safe and reliable, as the campus trusts it to store their other personal information. It is also easily accessible from anywhere, as long as the user has a personal certificate. However, setting up the system on Websis requires a data system that will update the system regularly and for the entire database to be on the web. Limiting the data to one computer in the Card Office will make it more secure and less easily obtainable by an outside third party. While having this information on Websis would be a novelty, it is not really necessary. Most students will need this information more often for solving problems associated with the card, for which they would need to visit the Card Office anyways. If students are interested in viewing their records, they should be able to visit the Card Office. Having student records accessible to the individual at the Card Office would ensure security of the information and meet the requirements of FERPA.
One of the additional provisions for student privacy protection is that students will be provided with a copy of their data if their data is specifically requested for any reason. This policy has been adopted by Harvard University, and we feel that students should be entitled to know when their personal records have been requested. Such a procedure follows in the spirit of disclosure, one of the Fair Use Principals, and the disclosure guidelines of FERPA.
Campus Police
The Campus Police find tracking data valuable in investigations, as was noted earlier. If they do not have access to the data, then the security importance of the tracking is not fulfilled. Therefore, the Campus Police should definitely have access to tracking data in some way or form. The Campus Police currently gain access to the data by requesting it from the head of the Card Office and putting it into the case file for storage. This system restricts the power that the police would have if they have full access to the database. According to Lieutenant Pierce and Detective Perault of the MIT Campus Police, the current system is flexible to the time constraints of an investigation, as they are usually able to get the data within a day and even sooner if needed. Furthermore, they noted that if the Campus Police need the information and the two week storage period is almost ending, then the Card Office can save it for the police until the paper work is completed.
On the other hand, more police power could be useful in cases where there is extreme time sensitivity. The information as an investigative tool is one of the key motivations of tracking. Police are supposed to uphold citizen's rights, as according to Pierce and Perault, they face a $10,000 fine and a year of jail time if they violate any of the privacy laws. The police are aware of the consequences of invading an individual's privacy and already deal with this on an everyday basis. Speeding up crime investigation is a strong reason to make the police as the gatekeeper of the data and there is also already infrastructure in place to hold them responsible for upholding privacy rights. However, the police's domain should be limited when it comes to dormitories, which should be part of the housemaster's, as discussed below.
Housemasters
Police have the permissions to view student and faculty tracking information. However, privacy rights need to be protected more in the dormitories and for this reason there needs to be an extra precaution to protect the dormitory tracking data. Larry Benedict, Dean of Student Life, suggested that the housemaster of a dorm should have access to his or her dorm's tracking information. The housemaster of a dorm is supposed to be one of the key individuals involved in a student's life, especially when there are any problems. Current MIT policy specifies that housemasters ``should be knowledgeable about the resources that exist at MIT for responding to crises and should be quick to call upon them when needed.'' [24]
Numerous duties of the housemaster require that the housemaster maintain the student's privacy rights and act in the student's interest, including representing the student in front of the Dean's office. For these reasons, the housemaster is a good choice as the gatekeeper for their own dormitory records. The housemaster should need to agree to any police accesses of tracking entry data from that housemaster's dormitory.
Housemasters deal with numerous crises that they need to investigate themselves. According to Julian Wheatley, the housemaster of East Campus, most housemasters prefer keeping these type of investigations internal so that they can still hold control, rather than making the information external. For the motivation of internal house investigations, Wheatley was in favor of housemasters being the gatekeeper for dormitory information, especially in the case of a possible missing person case. Under this recommendation, housemasters can at any time access data regarding their own dormitory at the Card Office, where the data is stored.
Since the data will be centralized in a certain location and not be placed online, the housemaster will need to visit the office to view data. There should be a secure authentication process for login, for which the Kerberos system can be used. The housemasters have two roles for taking care of student data: they can view the data to investigate internal house matters and they need to act as the gatekeeper for the data anytime someone else wants access to it, especially the Campus Police.
Miscellaneous
Any other individual on or off campus should not usually need access to the tracking data. Again, if access to the data is too easy, then the privacy rights of the students and faculty are at risk. However, if any other party does need information, such as outside government agencies, then they could be directed through the Campus Police. One possibility is through the Campus Police, which would make sense due to the hierarchical nature of the jurisdictions. The current policy for outside government agencies is that they need a subpoena for any information, according to Pierce and Perault of the MIT Campus Police. However, these individuals also mentioned that requests from other groups are usually rejected unless it's a criminal investigation. If any one on campus has a reason that they want to access the data, they can go through one of two channels: the Campus Police or the Housemasters. Which group an individual approaches should depend upon the type of concern.
One of the recommendations of this report is to expand and strengthen the mandate of the current Card Advisory Council, and to rename the council the Card Advisory and Oversight Counsel. In formulating this recommendation, we considered information gathered from interviews with current members of the Card Advisory Council, and members of past versions of the same committee, and combined our findings with our own concerns, and those of other users of the MIT ID Card.
One of the main problems with the current committee is that although there are ostensibly members from all parts of the MIT community on the council, not everyone is always present at the meetings. Most importantly, undergraduate attendance at these meetings is relatively low, as it is across many institute committees with undergraduate representatives. Low attendance by undergraduate representatives is problematic because undergraduates make up a large portion of the MIT community and should have proportional representation on the committee. If undergraduate representation at the policy reviews meetings is low, then the policy recommendations and reviews will probably not accurately the undergraduate interests as well. As demonstrated by our survey of the student body, there is widespread ignorance of the card and its policies. For such a large portion of the community to be completely ignorant of these policies is intuitively disturbing.
The Council's main function at present is only to review changes and additions to the MIT Card policies; it does not currently have any power to make decisions. Herein lies another flaw with the construction of the current council. These policy discussions and reviews are nothing if they don't have the power to actually enforce any of those recommendations. One way to understand why the lack of decision making power of the council is problematic is to imagine the function and purpose of congress without lawmaking powers: Congress would exist to discuss and review the policies and laws of the administration, but would not have any power to change those policies. The actual laws would be completely controlled by the administration, and there would be no way to ensure that the laws took into account the interests of all the people the law would apply to. This is the case with the current council: It meets to discuss policies of the card, and how those policies might affect the MIT community, but they have no power to enforce any of those policies, or to make sure that the policies in place really look out for the interests of the groups they represent.
When the tracking function of the MIT ID Card system was turned on in 2002, recommendations of previous card advisory committees were disregarded. Previous incarnations of the Card Advisory Council had decided that maintaining records of successful card accesses was undesirable. It is unclear how much effort was made to make sure the tracking policy was acceptable to the entire community. From information gathered from John McDonald, Associate Director of Enterprise Services, it seems that the change was made to accommodate labs and offices on campus that wanted local access control, access to audit logs, and RFID technology. The accommodation was made to help bring more labs and offices under the card office umbrella to improve convenience for the labs.
It was assumed that this change in tracking policy was generally desired by the entire MIT community when in fact a large portion of the community Ð the student population Ð had no knowledge of the feature until an article in The Tech described the launch of the tracking policy some 6 months afterwards. This change in system operation flew in the face of previous policy decisions to not keep record of card access. A policy review of the change in tracking was never conducted at this time. This seems to have been a major breakdown in the way that these processes were ostensibly supposed to work. Such a decision which affects all users on campus should have been approved by the representative committeeÑthe care advisory council.
Despite the inabilities of the council to effectively steer policy, the Card Council does have some very important merits. According to Hector Hernandez, a recent addition to the Card Advisory Council, the committee is composed of all the right players. Discussions between members of the council are genuine roundtable discussions in which no person's opinion is more important than another member's, and the discussions that occur at meetings are fruitful ones in which many important issues are discussed.
Many of the members are highly cognizant of the implications that the card's functions have for privacy; some members of the council, such as Hector Hernandez, are on the council because of a strong interest in the larger privacy and security concerns surrounding the card.
The CAOB will be in charge of dealing with all other problems that may arise as a result of keeping tracking information. One such situation that is likely to arise is when 3rd parties subpoena the tracking information, perhaps in relation to a criminal investigation. Third parties may want to serve the subpoena to anyone with access to the data. For example, the state police might serve the manager of the card office with a subpoena for tracking information. At this point, the card manager has two options according to Hal Abelson, a professor at MIT who has previously received a subpoena for information: He can consult directly with MIT general counsel to determine whether or not he must comply with the subpoena and provide the information, or he can pass the subpoena on to some other authority to consult general counsel. Our recommendation in this situation is to pass the subpoena up to the card advisory council to handle compliance issues with the subpoena. The CAOB will be in charge of consulting MIT general counsel about whether or not they must comply with the subpoena. If general counsel advises the CAOB to comply with the subpoena, then the CAOB will provide the requested data to the party serving the subpoena.
It seems that it is important to at least make the committee carry more weight, and to use this weight to get its proposed policies approved and implemented. One requirement for this is to make the committee more permanent and less easily dissolved. In the past, Committees on Privacy seemed to be formed whenever privacy concerning the card was a salient issue in the community. By making the Card Advisory and Oversight Council a stronger Institute committee, we can ensure the continuity of the committee. Over the past several years, card committees, and privacy committees, other various committees have been formed and dissolved. In the process of forming and dissolving committees, much of the accumulated knowledge seems to have been lost and is difficult to find unless one speaks with former members of those committees, who may not remember all of the discussions and findings in the desired detail. When interest in the topic died, or the current issues were resolved, the privacy committees disbanded, or discontinued. Our recommendation entails making the Committee a more permanent institute committee so that issues of security, privacy, and the MIT ID Card can be dealt with proactively and counter problems before they become widespread.
In the event that dissolution of the CAOB can not be prevented, a process for dissolution should be followed. This process should ensure that the findings and the policies of the committee are kept intact and archived for future use, when the Council might be reincarnated.
This section describes the auditing mechanism we feel is necessary to protect against abuse of data collected by the MIT ID Card system.
Possible misuses of the tracking data include discriminatory, supervisory, and random tracking. Discriminatory tracking would entail the distillation of entry/exit data of different groups on campus. Supervisory tracking is the tracking of employees by their superiors to aid in enforcing employment rules and regulations. Random tracking is more of a voyeuristic activity that people might engage in just to see whose card is being used where. Random tracking might also include stalking. Additionally, it is important not to give just one party complete access to the data as this party could abuse its power, even with accountability mechanisms in place. Auditing procedures will prevent parties from illegally accessing data and/or altering data without proper consent. Auditing also ensures that data is only being used in accordance with the principles under which access data was being collected in the first place.
In reality, though the current policy requires that all requests for card tracking data be approved by the chief of police, many accesses to the data occur without ever coming to the attention of the MIT Campus police chief. Additionally, there is no written audit policy, nor evidence of a mechanism used to audit the practices of the MIT Card Office, and other MIT ID Card activities. It is these unauthorized accesses which we intend to curtail, and nebulous policies that we hope to define more precisely.
The technical design of the log of data accesses will be discussed in later sections. Rather than logging accesses to data manually, the new system will log them automatically to further streamline the audit process. Currently, there is no real system in existence for auditing all accesses to the tracking databases. Although the current policy stipulates that the Chief of MIT Campus Police must sign off on all requests to use student data, there have been many instances of accesses to the database that have occurred without the proper authorization. Additionally, there seems to be no real record of when such accesses have occurred; the closest semblance to a database access log is a manually maintained log of such accesses.
While protecting the privacy of individuals by including an audit process in data access procedure, we would still like to preserve the speed at which data can be accessed when necessary. The purpose of the tracked data is to aid in maintaining security on campus, and the auditing process should not impede this goal as much as it should aid in ensuring that this goal is effectively and efficiently achieved.
First, record of the username will allow for auditors to know exactly who was responsible for accessing certain data, and who to hold accountable in case of any deviations from policy. Auditors will also need the timestamp and knowledge of what data was accessed in order to determination whether or not a violation of policy occurred.
Along the same vein of responsibility among users, those who are auditing the system should have a vested interest in providing a quality auditing procedure to ensure that auditing is carried out properly. If the auditing process breaks down, then so does the integrity of the privacy protection built into the system.
One key question which arises in formulating an auditing policy is the designation of an auditing authority. We recognize that auditing the card access procedure with an outside auditing source could be costly, and that costs are one of the main limiting factors to the MIT ID Card system overall. However, the risks to privacy that misuse of tracking information poses are so great as to justify the additional costs of auditing the entire procedure. One of the main requirements of our policy, supported by undergraduates and other members of the community is that tracking information should only be kept if there is an auditing or procedure in place to ensure that the data collected is not misused. Guaranteeing that the data is not misused also means that all accesses to the data follow the procedures outline in our policy recommendations. Without such checks and balances in place, it would be impossible to prevent misuse of the tracking information from going undetected.
There are several options for which on or off campus entity should have the authority to responsibly audit card data access logs. This entity should be a trustworthy, on campus body with a vested interest in the card, and with a concern from privacy of card users.
According to Professor Arthur C. Smith, one of the first members of the MIT community to head a privacy committee at MIT, it is better to keep faculty in charge of many of the functions of card oversight. The primary reason to do so is that they are by far the most permanent members of the MIT community. Students, the MIT police force, and other offices on campus have very large rates of turnover, relative to the turnover in faculty. Because of low turnover among faculty, putting a faculty member in charge of auditing creates a position of influence for a faculty member who has an interest in maintaining rights on campus, and who will maintain that position for many years; another method of preserving institutional memory.
The first office that comes to mind as a potential auditor is the card office itself. One of the primary reasons for instituting and auditing policy is to ensure that the card office follows the policies and procedures to which it is subject. It is not feasible to allow this office to audit itself, as it would be inclined to find as little fault with its actions as possible. Also, audits should be conducted by an outside source that will not be biased in its findings.
Another option for auditing is to give this responsibility to enterprise services, the office which oversees the card office. Because this is the office which oversees the function of the card office, it would be one of the more logical choices for an auditing authority. Additionally, because enterprise services is the office in charge of dealings with outside vendors, they would also be able to use their access powers to perform system checks, and to make sure that the system was performing as promised by the vendor.
Campus police, which is responsible for approving accesses to student information, would most certainly be responsible in performing audit checks. In conducting criminal investigations, the MIT police are required to follow strict rules and regulations when accessing personal records, as regulated by the CORI laws. However, like the Card Office, the Campus Police would then be auditing many of their own actions.
The more practical yet costly solution to auditing is to hire a third-party auditing agency to review the access logs to make sure that policies and procedures are being followed by parties involved in card data access operations. One such third-party is the MIT Audit Division. MIT's Audit Division is an in-house office that can be used as an auditing resource for the tracking data access process. MIT Audit is an internal auditing office that performs audits and reviews for labs, departments, and centers across the Institute. The assessments performed by this office include reviews of compliance with Institute, financial, operational and information technology policies and procedures. Additionally, MIT Audit will provide follow up assessments of offices they have audited to make sure that any necessary changes that were needed to be made were made and that the changes were effective in remedying the problems they were intended to solve.
In this section, we give an overview of some of the major technology options available for ID card systems. One method of classification of the different technologies is according to whether the card is a contact card or a contactless card. Contact cards primarily in use are magnetic strip cards and contact smartcards. Among contactless cards, the two most popular options are contactless smartcards and proximity cards. In the discussion below, the different types of cards are described in detail according to the technology that they use: Magnetic strip, RFID, or smartcard.
A magnetic strip is a plastic-like film containing tiny iron-based magnetic particles on the back of many transaction and access cards. The strips are written by magnetizing the particles in the required orientation. There are three tracks (each 0.11 inches wide) on the strip. According to the ISO/IEC 7811 standard, the tracks contain information as described in table 5.1.
|
Usually only tracks 1 and 2 are used. On track 1, either of two formats may be used. Format A is proprietary use by the card issuer. Format B is a standard representation as shown in table 5.1. Table 5.1 also shows the standard format that is used for Track 2.
Magnetic strip technology is mainly used for transaction processing and access control. The strips come in two main varieties: High Coercivity (HiCo) and Low Coercivity (LowCo).12 HiCo provides highest protection against damage by magnetic fields, but it is harder to encode due to the higher power required to encode it. Most cards that are used for access control are HiCo, so as to provide greater protection against accidental modification and to survive repeated use.
Radio frequency identification (RFID) [11] technology comprises two main components: the tag and the reader. The tag acts as the identifier in the system; it contains a microchip with a coiled antenna, and can transmit the information held in its microchip's memory by sending radio waves to a reader, which also contains an antenna. The information is interpreted by the reader and relayed to a main computer system. These tags can vary in size, shape and form depending on the needs of the application, but the antenna has to be of the specific size required by the transmitting and receiving frequency.
The mechanism for communication for a typical RFID system works as follows:
The most common way of categorizing RFID tags is based on the power source, classifying them into three main categories: passive, semi-passive and active.
The transmission range of a tag depends on the frequency and power used; different antennae are used depending on the required communication frequency. Tags can be broadly categorized into three operating frequency bands: low-frequency tags (20kHz - 500kHz), high-frequency tags (13.56MHz) and ultra-high-frequency tags (850MHz - 900MHz). The read ranges vary according to frequency. The low-frequency tags can be read from up to about a foot away. High-frequency tags can be read from up to about three feet away. UHF tags can be read from 10 to 20 feet away. The low-end tags have very basic functionality emitting a static 64-to-256-bit identifier, while the higher-end tags may have the capability to perform active encryption.
One of the biggest problems with RFID technology is the lack of security in the system. RFID tags have very little computation power: they have a few thousand logic gates and no cryptographic functions are available for the passive tags. However, there have been a number of proposals for providing security. RSA Laboratories has provided two approaches: the minimalist cryptography approach [13] and the blocker tag approach [14] described further in this section. Other schemes that have been proposed include the Kill Command feature described by the AutoID center, the Hash Lock Scheme and Randomized Hash Lock Scheme by MIT, and the Anonymous ID Scheme by NTT DoCoMo, Inc.
Minimalist Cryptography: This approach uses a method of ``pseudonym rotation.'' The basic idea behind this mechanism is that each tag has a list of cryptographically unlinkable pseudonyms computed externally by a trusted verifier. This would require limited storage - around 10 pseudonyms; the tag cycles through these pseudonyms. The pseudonyms are coupled with a throttling mechanism that strengthens the restriction on adversarial queries. On the reader end, a valid reader provides new pseudonyms. These pseudonyms are protected against eavesdropping and tampering using encryption (readers have enough power to do this even though the tags do not). The pseudonyms are encrypted by the interleaving of one-time pads.
Each of the pseudonyms stored on a tag consist of a list of triplet-values. With the current restrictions on the size of RFID chips, this list would have about 10 entries. Each triplet contains three values 
. 
is sent to the reader by the card on query, and 
is the value that the reader responds with; 
is the final authentication value sent by the tag. In this protocol, the reader has the capability of updating the triplet values on a tag. The update is made using one-time pads that have been transmitted across multiple authentication protocols (to prevent malicious reader attacks).
This method is based on the fact that RFID adversaries are different from the usual adversaries in other systems. An adversary with full system access can easily break the system. But in the real world, the adversary must have physical proximity to the tag and, in this case, a valid reader. An adversary could use an invalid reader but the throttling mechanism would prevent them from getting all of the pseudonyms. Also, they would need access to the reader to gain the reader component of the pseudonym. The threat model for RFID tags supports the hardness of this method; it is not a foolproof cryptographic solution, but can be argued to be enough for most security purposes.
Blocker Tag Approach: A blocker tag simulates all (billions of) possible tag serial numbers. A `tree-walking' protocol for identifying the tags asks the tag what the next bit is; a blocker tag always says both 0 and 1. This makes it seem like all possible tags are present and stalls the reader. Blocker tags move can be selective and move tags to privacy zones, blocking certain ranges of RFID serial numbers. This type of tag is useful for protecting consumer privacy when RFIDs are placed on many items. After purchase, the tags can be transferred to privacy zones. The approach is not very useful for ID card systems that require repeated use and no change of zoning (or moving into privacy zones) is required, nor is it useful for authentication, however, it is useful for keeping the data on an identifying card secret when the card is not being used.
A smartcard is a card that has an embedded computer chip which is either a microprocessor with internal memory in it or a memory chip alone. Due to the presence of the embedded microprocessor, smartcards have the ability to store large amounts of data and carry out many functions including encryption and acting as digital signatures. The card connects to a reader in one of 2 ways:
The above classification method is based on the means of communication. Another way of categorizing smartcards is by the hardware on the card:
The international standard for smartcards is ISO13 7816. Among their many uses, smartcards are very useful for physical access as ID cards to open doors, gates or other controls. Many physical security systems today use a protocol called ``Wiegand'' to communicate with door locks and other security devices.
Contact cards14 require insertion into a smartcard reader or card acceptor device (CAD) with a direct connection to a conductive micro-module on the surface of the card. When the contact smartcards are inserted into the reader, the pins attached to the reader make contact with pads on the surface of the card and can read from and store information on the chip via this interface. The ISO 7816 series of standards provides the standard for this type of card. One of the disadvantages of contact cards is that they have been shown to suffer some degree of wear, limiting the life of the card. They are used in a wide variety of applications, including network security, vending, meal plans, loyalty cards, electronic cash, government IDs, campus IDs, e-commerce, and health cards. They have very strong security capabilities.
Contactless smartcards or non-contact smartcards have chips that communicate with the card acceptor device through wireless self-powered induction technology (106-424kbits/sec). The card acceptor device is also called a reader. Standards for the contactless protocol are specified by ISO/IEC15 14443 (type A and B) from the year 2001. There are proposals outstanding for ISO 14443 type C, D, E and F that have not yet been accepted by the ISO standards committee. An alternative standard for the contactless smartcard is ISO 15693. These standards are focused on microprocessor-based cards. These cards have at least 1 kilobyte of memory.16 The cards need to come within close proximity of the reader. Typically the range of operation varies from 2.5 to 3.9 inches (63.5 to 99.06 mm) depending on the reader.17 In order to communicate, the cards contain an embedded antenna that can be used for reading and writing information.
The advantages of contactless smartcards include expanded flexibility, more memory, higher security (than most other options), faster transactions, lower maintenance, and published standards. They provide both convenience and security. All the secure cryptographic capabilities that were previously available in contact cards are now available in contactless smartcards. Examples of widely used contactless smartcards are Hong Kong's Octopus card, Malaysia's Touch 'n Go smartcard (1997), Paris' Calypso card18 (October 2001), and London's Oyster card19 (January 2004). Other areas of growing use include student identification, electronic passports, vending, parking and tolls.
One of the main benefits of smartcards is the ability for most cards to support on-board cryptography. Since the actual cryptography is done on the card, the keys do not have to leave their storage place. smartcards have the capability to perform both symmetric and asymmetric public/private key cryptography. They provide support for the following: Symmetric cryptography is when two parties share a secret key that no one else knows. This key is used to both encrypt and decrypt messages (hence ``symmetric''). If the key is compromised, then the cryptographic method breaks. Asymmetric cryptography works using a pair of a public and private keys. The public key is freely available and can be used by anyone to encrypt a message that the owner of that public key later decrypts with their private key, which is safely stored on the smartcard. Symmetric cryptography is much faster than asymmetric due to the lesser amount of computation time required. Common symmetric key algorithms are DES (Data Encryption Standard), 3-DES, and AES and the most common asymmetric cryptographic technique is public key RSA (Rivest-Shamir-Adleman's algorithm). DES, 3-DES and RSA use 56, 168, and 1024 bit long keys, respectively. Often a combination of symmetric and asymmetric cryptography is used. A usual method of doing this is as follows: if you want to send a message to user 
, encrypt a new key 
(usually small and fixed-width) using 's public key. Then use to encrypt the message. then finds by decrypting it using her own private key (takes time) and then uses to decrypt the message (taking less time). The self-containment of smartcards makes them resistant to attack as they do not need to depend upon potentially vulnerable and exploitable external resources. Hence, they are useful for strong security protection and authentication. In order to examine the security of smartcards, we will consider the following four areas:20
Communication with the outside world: A smartcard and reader communicate via small data packets called APDUs (Application Protocol Data Units). The sophisticated protocol, low bit rate (9600 bits per second), bi-directional transmission line, and the fact that the data only travels in one direction at a time makes it harder to attack the system. A mutual active authentication protocol is used for authentication. The card generates a random number and sends it to the reader, which encrypts the number with a shared encryption key before returning it to the card. The card then compares the returned result with its own encryption. The pair may then perform the operation in reverse. Once communication is established, each message between the pair is verified through a message authentication code. This is a number that is calculated based on the data itself, an encryption key, and a random number. If data has been altered (for any reason, including transmission errors) message must be retransmitted. Alternatively, if the chip has sufficient memory and processing power, the data can be verified through a digital signature. Some of the algorithms used on these cards have been found to be breakable. [12]
Hardware Security: All data and passwords on a card are stored in the EEPROM (electrically erasable programmable read only memory) and can be erased or modified by an unusual voltage supply. Therefore some security processors implemented sensors for environmental changes. However, since it is difficult to find the right level of sensitivity and there is a voltage fluctuation when the power is supplied to the card, this method is not widely used. Other successful attacks methods include heating the processor to a high temperature or focusing UV light on the EEPROM, thus removing the security lock. Invasive physical attacks are the most destructive when the card is cut and processor removed. Then the layout of the chip can be reverse engineered. Differential Power Analysis (DPA), is a statistical attack on a cryptographic algorithm which compares a calculated guess with a measured outcome and can often extract an encryption key from a smartcard. Simple Power Analysis (SPA), which is the direct analysis of the recorded power data to determine actions and data, can also break some smartcards. Several solutions to these problems have been implemented. Technologies that have been developed for protection include the following: [12]
OS Security: Data on smartcards is organized in a tree hierarchy. There is one master file (MF) which behaves as the root directory. The root contains elementary files (EF) and dedicated files (DF). EFs are files and DFs are sub-directories (which can also contain more EFs), similar to any common operating system. The main difference is that DFs can also contain data. DF's, EF's, and MF's headers contains security attributes resembling user permissions associated with a file/directory. Any application can traverse the file tree, but it can only move to a node if it has the appropriate rights.
Attributes (Access Rights): There are five basic levels of access rights to a file (both DF and EF). Some OS provide further levels. Basic levels can be categorized, increasingly in security, as follows:
CHV1 and CHV2 correspond to the two security PINs stored in the card:
The PINs are stored in separate elementary files. When a wrong PIN is entered several times, the OS blocks the card. The number of times is fixed and depends on the OS. Once blocked, the card can only be unblocked with a specific unblocking PIN stored in the card. The unblocking PIN can become blocked in the same way. If this happens, card is said to be in irreversible blockage and may have to be scrapped for security reasons. If the PIN is blocked, the attribute of every file is changed to require CHV1. After the unblocking PIN is presented, the file attributes are returned to normal, the counter for the PIN is set back to its maximal value and the counter for the unblocking PIN is decremented. If the latter counter reaches zero, it cannot be used for unblocking the PIN any more. This provides additional security for the card. This PIN structure is used for advanced authentication.
Software Security: Software security is also important. Properly encrypted data and transfers are required which are done using hardware-based or OS-based instructions and libraries supporting advanced cryptographic algorithms.
Most attacks today are classified as class 3 attacks, which means that either the costs associated to break the system are far more than the cost of the system itself, or that the cracker has to spend several or hundred years of computing power to break into a single transaction. Technology is developing faster than cracker methods. Therefore, each new generation of technology usually prevents attacks that the previous generation was vulnerable to.
As can be seen from the discussion of ID card technologies in sectionrefextech, an ID card system is generally made up of three components:
The current MIT ID Card consists of a double-layered strip of PVC with a magnetic strip and an RFID chip. This card will also be referred to as a ``proximity card'' or ``prox card'' later in this paper. The front face of the card has the MIT logo and owner's name, MIT ID number, photograph, and an expiration date. The back face of the card has a magnetic strip, a serial number, the status of the owner (explained below), the MIT logo and contact information for the MIT Card Office, and a disclaimer. There are three types of card based on the status of the owner: student, affiliate (including spouse or partner), and alumni. Temporary cards can be issued for residence access, parking access, summer conferences, retirees, athletic center access, and other non-picture cards. Specialty cards can also be issued such as those for the Emergency Response Group, for Campus Police, and for Facilities. Currently, there are over 27,000 card records in the MIT system. [22] The integration of the card into the existing MIT infrastructure was done by MAC Systems of Avon, Massachusetts.
Indala Corp. of San Jose, California is the vendor who provided the card technology to MIT. It is part of their range of solutions for card systems. The type of card used for the MIT ID Card is the FlexISO Proximity Card.22 According to the Indala website, the FlexISO card is a credit card-thin identification card that is ISO 7813 compliant. ISO 7813 is a standard for identification cards that are used as financial transaction cards. The card has a graphics-quality surface on both sides of the card and can contain multiple ID technologies including a magnetic strip, Wiegand code strip, bar code, a multitude of smart chips, and MIFARE. Currently, all MIT ID Cards has a magnetic strip and an RFID chip but some of the newer cards have a bar code also. Information is printed on the card using a dye-sublimation printer. Figures 3 and 423 show the ISO standard specification for ID cards.
The Indala card in particular complies with these specifications. The card has the ability to include either a contact smart chip, a prox chip or a contactless smart chip. The MIT Card, in particular, contains the 125 kHz proximity antenna and chip, and a 3-track high-coercivity magnetic strip. The magnetic strip follows the standard described in section 5.1. Figure 5 shows a typical card from Indala, but this was slightly modified for the MIT ID Card when it was seen that excessive use of the magnetic strip led to the wear of the tag that lay directly beneath it. [22]
The read range of the card depends on the reader. According to the company specifications, with a mid-range reader (like most of the readers on campus), the read range is up to 12 inches (30.5cm). Informal measurements by members of our group have shown that campus readers can read cards from approximately 5-6 inches away. in experiments conducted by Mandel, Roach and Winstein, the cards could be read remotely at a distance of several feet.
Each card has an identifier that is a randomly generated 6-character string that is different from the owner's MIT ID number. This is the ID number stored on the magnetic strip. A new number is generated for every card, both new cards and replacement cards. This same number is used for the RFID chip on the prox card. The chip is passive and thus has no power source. The card is powered by a 125 KHz sine wave. [25] It responds with an AM broadcast of bits that can be received with a modified AM radio or with an oscilloscope. The broadcast contains 224 bits that are repeated. There are 30 zeros, 22 constant bits and 172 user bits. Out of the 172 user bits, 32 bits seemed to vary from card to card while the others remained constant between cards.
|
The panels were provided by SonicWALL, a provider of integrated network security and identity solutions based in Sunnyvale, California.25 They are part of the network described in the data management section. The panels can be connected to the MIT Card Office system allowing the card office to control access or they may be controlled by the department whose control that panel falls under. On request, the Card Office will help set up a client station that gives the department control over access. The department also needs to provide a PC, a network jack, and a lock-box. CS Gold 4.1 by Diebold, Inc. is responsible for the access control at the client stations; the software offers controlled access, electronic payments, and identification. Currently, there are 34 client stations spread across the MIT campus. There are plans to deploy over 20 more stations before Spring 2005. [22]
The data from the panels are all sent to the centralized server and access logs are made. The access data are stored for a period of two weeks. The two kinds of data stored are
After the data are stored on the server, they can be accessed by a request that must signed by the police. The CCURE system has an audit log so that every time someone runs a report of card usage, the system stores the user as well as the parameters of the report. These requests are maintained on file. [23] Only Dan Michaud of the Card Office has access to the log of changes to the entry log. [22]
The MIT ID Card is not secure by any stretch of the imagination; both the magnetic strip and the RFID tag portions of the current card are vulnerable to identity theft. A 1995 Tech article on a report submitted by André DeHon to then-director of Housing and Food Services (which is now separated into two different departments) Lawrence E. Maguire and several other administrators quotes DeHon as writing ``the level of security provided by the card is laughable.'' [8]
DeHon discovered that anyone with an appropriate magnetic strip card reader can readily extract the information from a card and make a copy, onto an old ATM card or the like. Says DeHon: ``Equipment to duplicate or synthesize MIT Cards can be readily obtained for less than $500 and requires no technical expertise to operate. The technically inclined can put together suitable equipment at a much lower cost.'' [8] As noted in section 6.1.1, the magnetic strip on the card contains the owner's MIT ID number and a 42-bit code identifying the owner.26
Unfortunately, a magnetic strip does not allow much in the way of flexibility in terms of how data is stored on the card. The data may be encrypted, for instance, but anyone can still copy the card's contents without knowing the key. The best security possible for this type of hardware, then, is ``security through obscurity,'' that is, security by preventing others from gaining physical access of your card and by preventing others from reading the contents of your card while the data is being transferred between the card reader itself and the access panel as described in section 6.2.1. While the problem of eavesdropping on reader-panel communication is more of a physical access issue than a technical limitation, and even so might possibly be solved by encrypting that communication, the problem of preventing others from accessing your card is more difficult.
On MIT's campus there is no more universal identification card than the MIT ID Card. The card can now be used to purchase food from campus vendors, is used to enter buildings, as an identification scheme by the Student Services Center and most other MIT administrative groups, as collateral for borrowing videos and keys at student dormitory desks, for parking, and so on. While not all of these uses require that the ID change hands, the use of the MIT ID for collateral does require surrender of the card. While surrendered, the owner has no control over whether the card is copied. And once copied, due to the wealth of services available with the card, not only is the owner's identity compromised but he can also lose monetarily. In his report, DeHon suggests not using the card as collateral precisely because the card is so easy to duplicate. In fact, this recommendation became policy shortly after his report was published, but the policy reverted back to the original shortly thereafter.
Because of its many uses, and because of the tendency for the MIT ID to be given to others for sufficient time for copying as a form of collateral, the security provided by the magnetic strip is not acceptable.
Unfortunately, the new MIT ID Cards that contain RFID tags only make the problem worse. Because the type of RFID used by the card, so-called ``passive'' RFID, always transmits the same data to the reader, the acquisition of the data sent in a single session can be used to make a duplicate of the card.27 This data can be read by a third party in two ways:
Method 1 above is difficult because the excitation range for card's particular RFID implementation is not very great, and your presence is likely to be noticed. Method 2, however, is not very difficult to accomplish with a little technical skill or an RFID reader. Because the range of the card's RFID tag is great enough to pass through a wallet or bookbag, the extraction of the RFID tag's data can be done without the owner's knowledge or even suspicion - affording the attacker a greater likelihood of escaping undetected and able to use the information he or she has gleaned.
Method 3 relies on the fact that the same information is kept on the magnetic strip as in the RFID tag. According to Dan Michaud, the rationale behind this decision was to avoid having to upgrade the access panels. Currently, the access panels have room to store about 20,000 identifiers. The card office has issued over 10,000 ID cards. If each card had multiple identifiers there would not be enough space on most access panels to keep all of the identifiers. In light of this limitation the card office decided to use the same identifier both on the magnetic strip and in the RFID tag. Unfortunately, this decision led to a serious vulnerability as well.
When MIT first contracted with Indala to bring RFID on campus, Indala assured them that the data stored on the cards was ``encrypted,'' however this was not the case. [22] As mentioned in section 5.2, only ``active'' cards are capable of real encryption, as real encryption relies on being able to perform computationally expensive (relative to the power used) tasks. ``Passive'' cards simply rebroadcast the same data each time they are activated, and are not capable of real encryption. This is not to say they are not useful, of course: in a system where there are no adversaries there is no need for strong encryption. If there is no incentive to spoof the system, there is no need for encryption. If you are counting cattle, the cattle are not going to impersonate each other; there is no need for strong encryption. Members of the MIT population are not cattle; we need strong encryption. The Indala system uses passive RFID tags, and thus cannot provide strong encryption. Under these circumstances it stands to reason that it would only be a matter of time before the ``weak'' encryption scheme were broken.
Keith Winstein, Austin Roach, and Josh Mandel showed in Spring 2004 that there is a trivial relation between the pattern of bits stored on the RFID tag and the identifier used on the magnetic strip of the same ID card. Now that this information is public, anyone who has access to the magnetic strip data of an ID card can recreate an RFID tag that emits the sequence of bits that the original card would have produced. Thus all of the issues surrounding the magnetic strip and its use as collateral apply even more so to the RFID portion of the card.
But even without this third method of gaining access to the data stored in the RFID tag, the passive tags used by the Indala system are vulnerable to replication and theft of identity simply by recording the signal they emit and playing it back. Winstein, Roach, and Mandel did this with $30 worth of hardware available at MIT's introductory electrical engineering laboratory. If MIT wishes to continue the use of RFID in the card, other options for secure transations need to be explored such as those mentioned in section 5.2.1.
...we also present what we feel would be an ideal new system for a future implementation:
This section is broken down by which part of the system that a given recommendation affects.
As we have already seen, the current implementation of RFID on the MIT ID Card is not secure and magnetic strip technology has fundamental properties that are irreconcilable with present uses of the MIT ID Card.
To summarize section 6.4, the two main liabilities of the RFID tag in the MIT ID Card are:
The second option solves the latter vulnerability by doing away with RFID in the entire system altogether. This option has the obvious advantage that the added vulnerabilities of RFID are not present in the system.
The third option is more complex because it requires the replacement of a large number of access panels. This option has the advantage that the RFID tags and magnetic strip data are divorced of each other, so that reading one will not tell you anything about the other. This can be useful for things like TechCash, which only uses the magnetic strip for the moment: even if an attacker gains access to the RFID tag (easier than the magnetic strip contents, since no physical access of the card is required), he or she will not be able to use the victim's TechCash account.
The first three options, while relatively inexpensive and implementable over the current system, still have many of the vulnerabilities that the magnetic strip and RFID tag have individually. Of these three, only the third is likely to be accepted by the MIT community. In our survey of the student body, approximately 41.7% felt that the convenience of RFID is worth the security risk. Now that RFID technology has been introduced, it is unlikely that (the student body, at least) will respond well to its withdrawal.
The fourth option is what we recommend for now. The MIT Card Office has already expended considerable effort in implementing the current system of prox card readers; students, faculty, and lab directors have all voiced the opinion that RFID is a generally useful tool, and they would probably not respond well to a removal of RFID. However, to eliminate the extra cost of installing a poor RFID system and needing to replace it later, we strongly recommend that expansion of the current RFID system be stopped.
The fifth option - the contactless smartcard - is ideal for a new system. The MIT ID Card's ``Passive'' RFID's intrinsic vulnerabilities are based on the fact that the tag emits the same data each time it is activated. However, ``active'' tags do not necessarily suffer from this vulnerability. In fact, ``active'' tags have been in use for authentication throughout the world since 1997, when Hong Kong implemented what is widely regarded as the first implementation of ``contactless smartcard'' technology, the ``Octopus Card.'' The ``Octopus Card'' can be purchased locally with cash, totally anonymously or with personal information recorded so the card can be revoked if lost. Because of the quantities of capital involved, the designers of the Octopus Card needed a system they were confident could not be broken into - imagine having the money in your pocket or wallet stolen through the very walls of your pocket or wallet! Clearly an unacceptable vulnerability.28
At the time when the designers of the Octopus Card were deciding on a system to use for authentication, the most secure mechanism available was the smartcard, a card with a little chip on it capable of performing strong encryption. When used, the smartcard receives power from the reader it is inserted into and with this power is able to have a secure conversation with the reader. As discussed in Sectionrefsmart above, smartcards ensure the integrity and privacy of the key data it stores (through various mechanisms) and perform challenge-response authentication with a reader.
Preferring a contactless solution, however, the designers of the Octopus Card designed a way to supply a card with enough power via induction coils to allow the card to perform strong encryption. In this manner, the designers were able to produce what is now commonly known as the contactless smartcard. Described in sectionrefclsmart, the contactless smartcard is an ideal solution to the problem that visibility of communications between a passive RFID tag and a reader leads to the ability of an eavesdropper to emulate the tag.
Another minor loophole that was identified in the current system, is the possibility of someone sitting at a client station to be able to see realtime data of entries and exits. This is made possible by keeping the client machine's screen turned on with a window of the access entries that are being sent to the central server. The number of entries that can be seen with this method depends on the buffer size of the window. The number of days worth of data that can be gathered is dependent on the amount that the readers served by that client station are used. The more frequently they are used, the lesser number of days worth of data will be shown on the screen. We recommend that this be changed so that client stations only show the most recent hour's worth of data. Our understanding is that this can be implemented easily, and we suggest that it be implemented as soon as possible to allay fears that administrators might use this information to track the movements of members of the MIT community.
In light of the more frequent need for access the log of general entry and other system data that is not user-specific, as well as the need for accountability regarding access that is user-specific, we recommend that the MIT Card Office keep a two-tiered database: the first level is a relational database with all the columns it already contains, except the username field is replaced with an ID string - unique to each entry in the database - that maps into a second database; the second database is simply a secure mapping between usernames and unique IDs that can only be accessed by the parties discussed in section 4.5. The two-tiered nature of the database allows the Card Office to access the data it needs on a daily basis without restriction, but only anonymously or in the presence of the individual whose data will be accessed. Of course, in the case of a request from the MIT Chief of Police, approved by the dorm housemaster in the case of dorm log data, the individual in question need not be present.
We recommend having two separate audit logs - an automated one and a manually created one. The first log is an automated one that automatically records every access that is made to the central database. This must be programmed into the system. Every time a connection to the database is initiated, the following details must be recorded:
This gives an automatic log of events that can be used for audits and corroboration. The log can be accessed by only one user account and the user account would be controlled by the Card Access and Oversight Board (CAOB). This would decouple responsibility for policy from the Card Office, ensure independence, and prevent changes to the audit log by unscrupulous elements.29 The second log must be stored at the Police Station and contains physical, documented evidence of requests that were made and granted by the Chief of Police. Whenever a request goes through the Chief of Police, it must be recorded here. The details of the request must include
This would provide the more comprehensive log of the request made. The CAOB would have access to these audit logs, but the auditing itself will take place as described in section 4.8.
There are other schools that encounter many of the same privacy and tracking data issues that MIT faces. The closest analogy to MIT is Harvard University, located in Cambridge, which experiences the same external threats to the students and members of the community, as the MIT community does because Harvard is located in the same city and the same urban environment. Actual uses for tracking data have occurred in situations and criminal investigations that are very similar to those which have occurred at MIT. These cases have included missing persons, vandalism, theft, and sexual assault. In some cases, students have requested their own data to aid in self-conducted investigations, but these requests for information have been denied. The existence of the card swipe logs has also helped to spur students guilty of academic fraud to admit to their crimes.
Harvard University currently operates a magnetic stripe card system similar to the one previously employed by MIT; the university has yet to switch to an RFID system. Like the MIT Card system however, data from card use is kept in logs, which can be accessed according to a policy that has never been formally distributed. This policy is described in an article that was first published in the Harvard Crimson Newspaper in 1993. This article is the only record of the policy which was created by student members of the Harvard University Civil Liberties Union and the Dean of Harvard College at the time, Fred Jewett. All of the information in the following sections on the ID card system used at Harvard was gathered from the article in the Crimson which described the policy, and an interview conducted with former Dean of Harvard College, Harry Lewis. Much of this information remains otherwise undocumented.
According to a Former dean of Harvard College, the actual policy has never been formally described anywhere although it was officially adopted by the Administrative Board. Upon discovering this fact as a result of inquiries for this report, Former Dean Lewis has advised his successor's to post the University's policy on card swipe data access on its website.
The policy stipulates that information can only be released with permission from the Dean of the College, or by the student whose information is to be released. Any data that is to be released to Harvard University Police will be released only ``under circumstances when the information is important in the investigation a crime or other incident related to campus security.'' Whenever information is released to any party, a copy of the released information must also be provided to the student. The CLUH felt that this policy struck the right balance between preserving information because it was useful and preserving the information simply because it was possible.
Since the policy was adopted, the question of whether it has been strictly followed is debatable. It is certain that the general spirit of the policy was followed, but strict enforcement has not occurred. During Dean Lewis' tenure as Dean of the College, all requests for information by the police or any other party were directed to him. The Harvard University Police Department (HUPD) knew to contact him whenever it was necessary to request card information. The Dean's jurisdiction, however, was limited to information of entry and exit from any of the University's dormitories. In one case, where the police requested entry/exit information from the dining hall, the Dean was asked for permission even though his jurisdiction did not extend to the dining halls. Those who requested information generally understood that the policy for making such requests required the permission of the dean. Dean Lewis felt that the provision of requested information to students was one of the requirements of the policy that was not always followed.
The data access policy only applies to dormitories because most students do not have access to other campus office buildings and labs after about 6 pm. This policy is beginning to change as students require more access to buildings on campus, such as labs and computer clusters, to complete work. Once card access is expanded to these areas, the policy for accessing data about students will also change as the data collected will include students not under the watch of the Dean of Harvard College, such as graduate students.
In most of the cases where card entry data was needed to help solve criminal investigations, most of the data was corroborated by witness accounts; the card swipe data did not serve as the primary piece of evidence. In these cases, the police requested very specific data from different locations during a fairly narrow time window on the order of a couple of hours. One of the provisions of the original policy allowed for student authorization for the release of data, but it seems that this was largely ignored over the years as student requests were often denied by the Dean of the college.
The data on these disks is recorded in a proprietary encrypted format, which prevents the misuse of the data therein by parties without access to the encryption methods or the Campus Card System Software. This software is apparently the only software that is capable of reading data from the storage disks. Stanford's Card system, much like the Indala system at MIT, is a completely proprietary system and the software and hardware employed are completely devoted to card operations. Registration information from the Stanford Axess system, equivalent to MIT's Websis, is fed into the card system, but all other records are kept separately from the card system. No other personally identifying information is given to the Card system from Axess.
In this section we hope to explore the feasibility of our proposed system. The recommendations we make above we have broadly classified as technical and policy recommendations. On the technology side of the card issue, there are three main factors to consider: security, convenience, and cost. On the policy side of the issue, the main concerns are privacy and accountability. With the continuation of an access logging system, the privacy of all members of the MIT community is at stake. Our proposed recommendations deal with these two issues by addressing both of them to the greatest extent possible and by ensuring that there are as few loopholes in the system as possible.
Our discussions with John McDonald of Enterprise Services have indicated to us that substantial changes to the current system are not feasible in the short term. To address this concern, we have ensured that out most important recommendations are inexpensive and easy to implement. We hope that the ideal system we have described in this document will be used as a template for any future system should MIT decide at some point to upgrade its current system to the state of the art.
We have presented here:
In order to develop fair and balanced recommendations, we consulted the thoughts and concerns of many different members of the MIT community, including students. To our knowledge, this report is the first report on the MIT ID Card to consider input from a large section of the student body. Considering that the MIT ID Card is almost 10 years old, this fact both surprises and concerns us, however, we are happy to announce that it has now been done. In addition to our survey, we have also collected the opinions of the many who have written on this topic before into a comprehensive collection.
We hope that our short-term recommendations are implemented in a timely manner, and that our long-term recommendations are seriously considered for any future system.
This appendix contains our survey questions and available responses, as well as how our survey respondents answered those questions.
The full contents of the survey page are given here, and each possible response is followed by the total number of respondents who selected that response and what fraction of total respondents this total represents (percentages may not sum to 100% due to rounding). In total, we received 513 responses.
This survey is designed to discover the privacy concerns of MIT students with regard to the MIT ID Card system. Our goal is to propose a system that will address the concerns of students and members of the faculty, lab directors, and the MIT campus police.
We appreciate your contribution.
The following questions are to gauge current opinions toward the MIT ID Card system.
At present, the MIT Card Office records when an individual enters a building or lab using their card and keeps these records for 2 weeks. This policy came into effect in the Summer of 2002.
The current system does not allow for different areas of campus to be treated differently for the purposes of tracking entry. The following questions refer to a hypothetical future system.
One group has suggested a policy of only recording unsuccessful attempts at entry, that is, only record a card swipe when entry to a location is denied.
The current 2 week policy may have been implemented in part because of on-campus labs' desire for increased security. As such, one suggestion is to limit tracking of entry to those areas alone.
Getting back to RFID, the current system allows cards to be read by a card reader in close proximity. This means that, hypothetically, someone can read your ID card's RFID identifier by walking near you with a reader (readers can be quite small). With this ID, they can access wherever you can access, can use your TechCash acount, and can discover your MIT ID number.
However, many argue that the vastly increased convenience of RFID (not having to take a card out of a wallet) outweighs the risks associated with reading-at-a-distance.
The following information is for demographic purposes. If you feel comfortable providing this information, we would appreciate it.
139 (27.1%)
115 (22.4%)
86 (16.7%)
90 (17.5%)
1 (0.2%)
29 (5.7%)
12 (2.34%)
15 (2.9%)
8 (1.56%)
5 (1.0%)
2 (0.4%)
If you have any comments about this survey or privacy at MIT in general, please share them with us here:
If you would like to be entered in our drawing for a $20 gift certificate to the Cambridgeside Galleria, please provide your username for us to contact you. Your username will not be associated with your responses in any way.
@mit.edu
Thank you for participating!
Priya, Neha, Chaitra, Al, and J.D.
If you have any questions, please send e-mail to privacy at MIT.edu
This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.70)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 mit_id.tex
The translation was initiated by J.D. Zamfirescu on 2004-12-11
