That's weird. I'm assuming that someone could actually have to get hold of someone's metrocard before they could do anything to it, am I right?
Let me know how you get on with his response back to you. Cheers
Wayne/ Katherine
We’ve got a bit of a risk that I’d like a bit of thought on please.
Per the email below James Turner has identified some security issues with our metrocard which have been known for some time. As mentioned in his email some researchers first identified the issues back in 2008. The researchers were PHD students from Holland who made some tests on cards in the UK as well as in Holland.
Both Darryl and I believe that James has simply identified the issue on the basis of the already published research and maybe trying to scaremonger to push our business toward one of the two companies he mentions. There is a risk that he does publicise the information in Christchurch on the date he mentions and that may lead to some people ditching their metrocards in fear. To my knowledge the research has not been widely published in newspapers so reporters may get a bit excited about it.
Many centres around the world continue to use the Mifare Classic cards (which we use) to good effect but our plan is to migrate new cards to the Mifare 4K DESfire card over the next year. INIT have committed to supporting this migration for no cost as part of the settlement for the ticketing system.
The other risk mitigation measure we have in place is that we routinely search on high value cards or those with strange transactions and if we identify any we are able to hotlist the cards so they cannot be used. We have only done this twice when back in the days of the ERG system we ended up with two cards with a value of around $1 mill. In each case the cause of the extreme value was in ERG’s opinion due to a hung transaction ie card presented to the device and transaction not completed, and hence corrupted.
INIT is also looking at other methods of detecting fraudulent transactions. Meanwhile we have noticed some database issues since 29 August which INIT is currently looking into that may have been caused by an attempt to defraud the system. We are as yet unable to confirm this.
We need to respond to James so I’ve drafted the following response up. Please feel free to suggest any changes.
James
Thanks for advising us of your findings. We are already aware of the findings of the researchers in Holland and have several mitigation strategies in place. The primary strategy is to transition to the Mifare 4K DESfire card which has a greater level of security. Our ticketing system provider has developed the software to allow our on-bus devices to read and write to the 4K DESfire cards and this is currently undergoing Factory Acceptance Test before deployment with another city.
We are also able to identify transactions that are of the nature you describe through routine analysis of the ticketing system reports which we have available. Once transactions of the nature you describe are identified we can then hotlist the offending card.
We would be interested in the reason why you have a timeframe for releasing the information by 9th of November. Are you able to clarify this for us? We would also be interested in understanding why you have undertaken the research when it has already been undertaken and publicised in Europe?
Thanks
David Stenhouse
Manager Passenger Services
The extract below is from the link to wiki that James has provided.
The encryption used by the MIFARE Classic card uses a 48 bit key.[16]
A presentation by Henryk Plötz and Karsten Nohl[17] at the Chaos Communication Congress in December 2007 described a partial reverse-engineering of the algorithm used in the MIFARE Classic chip. Abstract and slides[18] are available online. A paper that describes the process of reverse engineering this chip was published at the August 2008 USENIX security conference.[19]
In March 2008 the Digital Security[20] research group of the Radboud University Nijmegen made public that they performed a complete reverse-engineering and were able to clone and manipulate the contents of an OV-Chipkaart which is a MIFARE Classic card.[21] For demonstration they used the Proxmark device, a 125 kHz / 13.56 MHz research instrument.[22] The schematics and software are released under the free GNU General Public License by Jonathan Westhues in 2007. They demonstrate it is even possible to perform card-only attacks using just an ordinary stock-commercial NFC reader in combination with the libnfc library.
The Radboud University published three scientific papers concerning the security of the MIFARE Classic:
In response to these attacks, the Dutch Minister of the Interior and Kingdom Relations stated that they would investigate whether the introduction of the Dutch Rijkspas could be brought forward from Q4 of 2008.[23]
NXP tried to stop the publication of the second article by requesting a preliminary injunction. However, the injunction was denied, with the court noting that, "It should be considered that the publication of scientific studies carries a lot of weight in a democratic society, as does informing society about serious issues in the chip, because it allows for mitigating of the risks."[24][25]
Both independent research results are confirmed by the manufacturer NXP.[26] These attacks on the cards didn't stop the further introduction of the card as the only accepted card for all Dutch public transport the OV-chipkaart continued as nothing happened[27] but in October 2011 the company TLS, responsible for the OV-Chipkaart announced that the new version of the card will be better protected against fraud.[28]
The MIFARE Classic encryption Crypto-1 can be broken in about 200 seconds on a laptop,[29] if approx. 50 bits of known (or chosen) key stream are available. This attack reveals the key from sniffed transactions under certain (common) circumstances and/or allows an attacker to learn the key by challenging the reader device.
The attack proposed in[30] recovers the secret key in about 40 ms on a laptop. This attack requires just one (partial) authentication attempt with a legitimate reader.
Additionally there are a number of attacks that work directly on a card and without the help of a valid reader device.[31] These attacks have been acknowledged by NXP.[32] In April 2009 new and better card-only attack on MIFARE Classic has been found. It was first announced at the Rump session of Eurocrypt 2009.[33] This attack was presented at SECRYPT 2009.[34] The full description of this latest and fastest attack to date can also be found in the IACR preprint archive.[35] The new attack improves by a factor of more than 10 all previous card-only attacks on MIFARE Classic, has instant running time, and it does not require a costly precomputation. The new attack allows to recover the secret key of any sector of MIFARE Classic card via wireless interaction, within about 300 queries to the card. It can then be combined with the nested authentication attack in the Nijmegen Oakland paper to recover subsequent keys almost instantly. Both attacks combined and with the right hardware equipment such as Proxmark3, one should be able to clone any MIFARE Classic card in not more than 10 seconds. This is much faster than previously thought.
Thanks
david
From: [email address]
Sent: Monday, 26 August 2013 10:15 a.m.
To: David Stenhouse; Darryl Gay
Subject: FW: Private disclosure of vulnerability
Importance: High
Hi Guys .. received this Saturday
From: James Turner [mailto:[email address]]
Sent: Saturday, 24 August 2013 3:50 p.m.
To: [email address]
Subject: Private disclosure of vulnerability
Private disclosure of vulnerability
Dear sir/madam
While conducting recent research, I have discovered a number of quite serious security issues with the Metro Card system.
Before getting into the details of the issues, I want to explain the nature and purpose of this communication. I am informing you as a courtesy, in the hopes that it will help you address the issues. It is not in any way intended as a threat.
At this point, I have not told anyone else of these issues, to avoid malicious parties exploiting the vulnerabilities before you can fix them; however, I have a hard deadline where I must publish my findings on 9th Nov 2013.
Another reason it is important to fix these issues as soon as possible is that there could be malicious parties already exploiting them.
Vulnerabilities:
1. Ability to arbitrarily increase/decrease credit on a Metro Card
2. Ability to add new unauthorised cards to the system
3. Ability to copy any other user�s card and use their credit
Background:
You will hopefully already know everything in this section, but I want to cover some background about the technology used by the Metro Card system.
The contactless card used for the Metro Card is called Mifare Classic. The Mifare Classic was first released in 1994, which means it is quite old now, at least by technology standards.
Each Mifare Classic card is divided into 16 �sectors� of data. The system uses two authentication keys per sector to only allow authorised reader devices to access the data on the card; these are called A and B keys. This makes for a total of 32 keys per card. Most of the sectors on a card can be rewritten, however the first part of the first sector contains a special number called the UID, the UID is unique to each card and cannot be changed.
In 2008 researchers reverse engineered the Mifare Classic and were able to copy cards. For more details see http://en.wikipedia.org/wiki/MIFARE#MIFARE_Classic
The researchers found a number of weaknesses with the Mifare Classic system. One of the weaknesses allowed anyone with access to a card to retrieve the authentication keys used on the card. To do this however took significant time. There is another weakness where if an attacker already knows at least one key for one sector, they can retrieve all the remaining keys very quickly i.e. in less than a minute. This is called the �nested attack�.
There is also an important vulnerability involving the card reader device. The attack allows the keys used by the reader device to be retrieved if the attacker can record, �snoop�, the failed (or successful) authentication traffic between a card and reader. To read the details of these attacks see http://www.sos.cs.ru.nl/applications/rfid/2008-esorics.pdf
There are two notable tools which were used to take advantage of these weaknesses. The first is called a �proxmark3�; it is a general purpose reader/writer device. It also allows eavesdropping on other reader/card transactions.
The second device is called a �magic Chinese card�. These are special Mifare Classic cards which allow the UID to be changed; effectively making them appear to be any other card.
Vulnerabilities:
Vulnerability 1:
As you can see, the Mifare Classic system is very insecure. Using the first weakness listed above, we could retrieve the keys from any Metro Card in a number of hours, which would allow us to read the data stored on the card and to change the data.
This task is made harder by the fact the each metro card uses different keys, so we would need to rerun the attack for every card we wanted to access. However, every metro card uses the same A key for sector 0 i.e. FFFFFFFFFFFF, which means we can use the �nested attack� to find the keys for any metro card in under a minute.
This allows us to easily read and change the data on any Metro Card we have physical access to. Since the data on Metro Cards is not encrypted, it is easy to find and change the important values, such as the card etched number and the balance. It seems there is no online checking of balance when a card is presented to a reader, so changing the balance on the card will make the reader accept the new value. Worse is the fact that there seems to be no server side balance verification either, which means that changing the balance on a card also updates the balance stored by the server the next time the reader device on the bus is synced.
Vulnerability 2:
As mentioned there is another attack against Mifare Classic involving a reader device. With this attack we can get the keys a reader tried to authenticate with when it attempts to read a card. Using this attack we can present the reader with a blank Mifare Classic card and find out what keys the card should be programmed with to allow other Metro Card readers to access it, we can then format the card to appear to be a valid metro card and it will work just like a legitimate card i.e. we can add unauthorised cards to the Metro Card system and use the first issue described above to set whatever balance we want.
Vulnerability 3:
The final issue is that we can �clone� any other user�s Metro Card without ever having physical access to it. Each metro card has two different IDs, the number printed on the top left of the card, and UID.
Although there is a mapping from the card number to the UID, the UID is the id which the balance is associated with. By loading the url https://metrocard.metroinfo.co.nz/account/get_balance/card:<card number>?callback=x, where <card number> is any six digit number, the server will return the UID and balance for the card, if it is active. This means that we can get the card number, UID and balance for every card in the Metro Card system. Using one of the �magic Chinese cards� we can clone any card in the Metro Card system and use that user's credit. Because of the first vulnerability mentioned, when the owner of the card next uses the card, the system balance will be reset, in effect making the legitimate user commit fraud.
Conclusions:
As mentioned above I have not told anyone else of these security issues, so that you have a chance to fix them before the public and any malicious parties become aware of them. I will be releasing all information related to this research on 9th Nov 2013. Although I won't release any details before then, the title/summary of this research will be released prior to the publication. It is therefore possible others may attempt to recreate what I have found. I suggest fixing these issues as soon as possible.
Companies and governments are informed about security issues everyday by independent researchers like myself, how you react to this information is of cause up to you, but below I outline the recommended response.
The professorial response to being informed about security issue in one's system is to thank the researcher, fix the issue as soon as possible, and then inform the researcher when it is safe to let the public know. The benefits to this type of response are: other researchers will feel comfortable about informing you if they find issues in the future. Good public relations as people see you fixing a problem as soon as you learn of it.
I assume you have skilled technical staff that will be able fix these issues. If you need further advice you might think of asking me, although I happy to provide more details of what I have discovered in this research, I do not work for you and am under no obligation to help fix these issues. You might think of hiring me to do contract work, but that would be very inappropriate. If you do need technical advice on how to fix these issues, I recommend contacting Lateral Security (http://www.lateralsecurity.com) or Insomnia Security (http://www.insomniasec.com), both well respected local computer security companies.
Please respond to this email to confirm you received it.
Yours, James Turner