From the Confidential Memo Prepared for the MBTA which was publicly disclosed by the MBTA is court filing:

This seems to break all the rules of integrity of sensitive data storage. How could someone store money on a magnetic stripe in 2008 and not store an identifier that references the account in a central database?

The tickets do have a unique identifier generated when the card is initially purchased so a fraud detection system could be in place or is planned. But this would require tracking the value on the ticket or the usage of the ticket centrally so it isn’t clear why the value is stored on the card in the first place.

There are so many question about the security of this public system.  Fraud costs the Massachusetts taxpayer money and refitting an insecure, ill-designed system costs the Massachusetts taxpayer money. [Disclosure: I am a Massachusetts taxpayer.]

It should be a requirement that the current system or the (hopefully) upgraded system be tested by an independent organization that specializes in cryptosystems.  If the independent testing uncovers vulnerabilities, they need to be fixed before the system is fielded. Then the system should be retested to verify the fixes.  Once the system is deemed secure by an independent organization, a summary of the test document should be published for public inspection.  It should include the types of testing conducted and the results.

The public trust requires inspection of taxpayer funded projects to make sure they meet acceptible standards and vendors held responsible for deficiencies.  Projects that use computers and software should not get a free pass. It will be interesting to see if the CharlieTicket system is ever held up to public scrutiny.

From the Confidential Memo Prepared for the MBTA which was publicly disclosed by the MBTA is court filing:

This seems to break all the rules of integrity of sensitive data storage. How could someone store money on a magnetic stripe in 2008 and not store an identifier that references the account in a central database?

The tickets do have a unique identifier generated when the card is initially purchased so a fraud detection system could be in place or is planned. But this would require tracking the value on the ticket or the usage of the ticket centrally so it isn’t clear why the value is stored on the card in the first place.

There are so many question about the security of this public system. Fraud costs the Massachusetts taxpayer money and refitting an insecure, ill-designed system costs the Massachusetts taxpayer money. [Disclosure: I am a Massachusetts taxpayer.]

It should be a requirement that the current system or the (hopefully) upgraded system be tested by an independent organization that specializes in cryptosystems. If the independent testing uncovers vulnerabilities, they need to be fixed before the system is fielded. Then the system should be retested to verify the fixes. Once the system is deemed secure by an independent organization, a summary of the test document should be published for public inspection. It should include the types of testing conducted and the results.

The public trust requires inspection of taxpayer funded projects to make sure they meet acceptible standards and vendors held responsible for deficiencies. Projects that use computers and software should not get a free pass. It will be interesting to see if the CharlieTicket system is ever held up to public scrutiny.

We write to express our firm belief that research on security vulnerabilities, and the sensible publication of the results of the research, are critical for scientific advancement, public safety and a robust market for secure technologies. Generally speaking, the norm in our field is that researchers take reasonable steps to protect the individuals using the systems studied. We understand that the student researchers took such steps with regard to their research, notably by planning not to present a critical element of a flaw they found. They did this so that their audience would be unable to exploit the security flaws they uncovered. . . .

The restraining order at issue in this case also fosters a dangerous information imbalance. In this case, for example, it allows the vendors of the technology and the MBTA to claim greater efficacy and security than their products warrant, then use the law to silence those who would reveal the technologies’ flaws. In this case, the law gives the public a false sense of security, achieved through law, not technical effectiveness. Preventing researchers from discussing a technology’s vulnerabilities does not make them go away - in fact, it may exacerbate them as more people and institutions use and come to rely upon the illusory protection. Yet the commercial purveyors of such technologies often do not want truthful discussions of their products’ flaws, and will likely withhold the prior approval or deny researchers access for testing if the law supports that effort. . . .

Yet at the same time that researchers need to act responsibly, vendors should not be granted complete control of the publication of such information, as it appears MBTA sought here. As noted above, vendors and users of such technologies often have an incentive to hide the flaws in the system rather than come clean with the public and take the steps necessary to remedy them. Thus, while researchers often refrain from publishing the technical details necessary to exploit the flaw, a legal ban on discussion of security flaws, such as that contained in the temporary restraining order, is especially troubling.

It will be interesting to see what arguments the MBTA uses to keep the students from speaking on a topic where all the important vulnerability information seems to have already disclosed. Sure the students haven’t presented a cookbook exploit tool but they have also stated they have no intention of doing so.

Perhaps the court will investigate what the MBTA’s and their technology vendors response has been to the MiFare card vulnerabilities that were disclosed responsibly. If there has been no vigorous response to responsibly disclosed vulnerabilities of many months ago how can they say with a straight face that are truly responding to new security information and just need more time.

We write to express our firm belief that research on security vulnerabilities, and the sensible publication of the results of the research, are critical for scientific advancement, public safety and a robust market for secure technologies. Generally speaking, the norm in our field is that researchers take reasonable steps to protect the individuals using the systems studied. We understand that the student researchers took such steps with regard to their research, notably by planning not to present a critical element of a flaw they found. They did this so that their audience would be unable to exploit the security flaws they uncovered. . . .

The restraining order at issue in this case also fosters a dangerous information imbalance. In this case, for example, it allows the vendors of the technology and the MBTA to claim greater efficacy and security than their products warrant, then use the law to silence those who would reveal the technologies’ flaws. In this case, the law gives the public a false sense of security, achieved through law, not technical effectiveness. Preventing researchers from discussing a technology’s vulnerabilities does not make them go away - in fact, it may exacerbate them as more people and institutions use and come to rely upon the illusory protection. Yet the commercial purveyors of such technologies often do not want truthful discussions of their products’ flaws, and will likely withhold the prior approval or deny researchers access for testing if the law supports that effort. . . .

Yet at the same time that researchers need to act responsibly, vendors should not be granted complete control of the publication of such information, as it appears MBTA sought here. As noted above, vendors and users of such technologies often have an incentive to hide the flaws in the system rather than come clean with the public and take the steps necessary to remedy them. Thus, while researchers often refrain from publishing the technical details necessary to exploit the flaw, a legal ban on discussion of security flaws, such as that contained in the temporary restraining order, is especially troubling.

It will be interesting to see what arguments the MBTA uses to keep the students from speaking on a topic where all the important vulnerability information seems to have already disclosed. Sure the students haven’t presented a cookbook exploit tool but they have also stated they have no intention of doing so.

Perhaps the court will investigate what the MBTA’s and their technology vendors response has been to the MiFare card vulnerabilities that were disclosed responsibly. If there has been no vigorous response to responsibly disclosed vulnerabilities of many months ago how can they say with a straight face that are truly responding to new security information and just need more time.

Doesn’t this seem backwards to you? Shouldn’t the MBTA be suing the vendor who sold them the flawed system? Security problems go away by mandating independant security testing before a product is accepted, not by trying to get security researchers to be quiet. This is a good example of how the reactive approach doesn’t work. The flaws are still in the system and suing researchers has just shined a bright light on them.

Update 08/09/2008 6:00pm EST:

The EFF is appealing the injunction which is blocking the students from speaking about the results of their testing.

A telling quote from Kurt Opsahl, staff attorney at the EFF gets to the heart of the issue:

“Courts have found that the First Amendment covers these things. We believe that this is a protected speech activity. When you discuss security issues, if you are telling the truth, that is something that should be protected.”

Apparently the MBTA has known about this problem since at least March, 2008 when a graduate student from the University of Virginia announced he was able to break the encryption system.

The U of VA researcher gave an interview where he described why security by obscurity is not a valid security approach for a cryptosystem:

Q: What are your thoughts on security by obscurity? Is NXP using this method of protection?

A: Security-through-obscurity hardly ever works. The lack of proper peer-review often even hurts the security of the system. Our Mifare work discovered several vulnerabilities that could be fixed without increasing the cost of the cards. NXP did for a long time rely on obscurity for the security of some of their products, but now decided against this outdated design approach and instead bases the security of newer RFID cards on publicly scrutinized cryptography and independent evaluations.

Q: Can you explain “Kerckhoffs Principle” and why it applies to your work?

A: Kerchoff, who lived in the 19th century, observed that keeping anything secret is really hard. So instead of relying on the secrecy of your whole system, it would a lot easier to only rely on the secrecy of a small secret key. Security systems should hence be publicly known and analyzed, and only the key should be secret. When properly realised for RFID cards, Kerchoff’s principle means that by analyzing their own cards, thieves cannot compromise your cards. This is contrary to our Mifare work, where we only analyzed a few copies of the the secret algorithm that is found in all cards and were consequently able affect the security of all the other billion cards out there.

The MBTA not only accepted a security system which relied on security by obscurity but once accepting this flawed model must try to maintain this obscurity with the court system.

The documents detailing the presentation are here.

Here's the story. Every Oyster card has a radio-frequency identification chip that communicates with readers mounted on the ticket barrier. That chip, the "Mifare Classic" chip, is used in hundreds of other transport systems as well — Boston, Los Angeles, Brisbane, Oslo, Amsterdam, Taipei, Shanghai, Rio de Janeiro — and as an access pass in thousands of companies, schools, hospitals, and government buildings around Britain and the rest of the world.

The security of Mifare Classic is terrible. This is not an exaggeration; it's kindergarten cryptography. Anyone with any security experience would be embarrassed to put his name to the design. NXP attempted to deal with this embarrassment by keeping the design secret.

The group that broke Mifare Classic is from Radboud University Nijmegen in the Netherlands. They demonstrated the attack by riding the Underground for free, and by breaking into a building. Their two papers (one is already online) will be published at two conferences this autumn.

The second paper is the one that NXP sued over. They called disclosure of the attack "irresponsible," warned that it will cause "immense damages," and claimed that it "will jeopardize the security of assets protected with systems incorporating the Mifare IC." The Dutch court would have none of it: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

Exactly right. More generally, the notion that secrecy supports security is inherently flawed. Whenever you see an organization claiming that design secrecy is necessary for security — in ID cards, in voting machines, in airport security — it invariably means that its security is lousy and it has no choice but to hide it. Any competent cryptographer would have designed Mifare's security with an open and public design.

Secrecy is fragile. Mifare's security was based on the belief that no one would discover how it worked; that's why NXP had to muzzle the Dutch researchers. But that's just wrong. Reverse-engineering isn't hard. Other researchers had already exposed Mifare's lousy security. A Chinese company even sells a compatible chip. Is there any doubt that the bad guys already know about this, or will soon enough?

Publication of this attack might be expensive for NXP and its customers, but it's good for security overall. Companies will only design security as good as their customers know to ask for. NXP's security was so bad because customers didn't know how to evaluate security: either they don't know what questions to ask, or didn't know enough to distrust the marketing answers they were given. This court ruling encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers.

It's unclear how this break will affect Transport for London. Cloning takes only a few seconds, and the thief only has to brush up against someone carrying a legitimate Oyster card. But it requires an RFID reader and a small piece of software which, while feasible for a techie, are too complicated for the average fare dodger. The police are likely to quickly arrest anyone who tries to sell cloned cards on any scale. TfL promises to turn off any cloned cards within 24 hours, but that will hurt the innocent victim who had his card cloned more than the thief.

The vulnerability is far more serious to the companies that use Mifare Classic as an access pass. It would be very interesting to know how NXP presented the system's security to them.

And while these attacks only pertain to the Mifare Classic chip, it makes me suspicious of the entire product line. NXP sells a more secure chip and has another on the way, but given the number of basic cryptography mistakes NXP made with Mifare Classic, one has to wonder whether the "more secure" versions will be sufficiently so.

This essay originally appeared in the Guardian.

10:00-11:00 FX, Developments in Cisco IOS Forensics.

11:15-12:30 Oliver Friedrichs, Threats to the 2008 Presidential Election (and more).

13:45-15:00 Option 1: Scott Stender, Concurrency Attacks in Web Applications. Option 2: Travis Goodspeed, Side-channel Timing Attacks on MSP430 Microcontroller Firmware.

15:15-16:30 Option 1: Alexander Sotirov and Mark Dowd, How To Impress Girls With Browser Memory Protection Bypasses. Option 2: Karsten Nohl, Mifare - Little Security, Despite Obscurity. This is one of the toughest time slots as you also have McFeters/Carter/Heasman and Grossman/Evans in the lineup. Choices, choices.

16:45-18:00 Option 1: Bruce Dang, Methods for Understanding Targeted Attacks with Office Documents. Option 2: Christopher Tarnovsky, Inducing Momentary Faults Within Secure Smartcards/Microcontrollers.

Lots of intriguing hardware talks on Day 2. A lot of it is probably over my head and my first options are more applicable to my day job. There might have to be some room hopping.

I fly out to Vegas tonight — see you all there!

10:00-11:00 FX, Developments in Cisco IOS Forensics.

11:15-12:30 Oliver Friedrichs, Threats to the 2008 Presidential Election (and more).

13:45-15:00 Option 1: Scott Stender, Concurrency Attacks in Web Applications. Option 2: Travis Goodspeed, Side-channel Timing Attacks on MSP430 Microcontroller Firmware.

15:15-16:30 Option 1: Alexander Sotirov and Mark Dowd, How To Impress Girls With Browser Memory Protection Bypasses. Option 2: Karsten Nohl, Mifare - Little Security, Despite Obscurity. This is one of the toughest time slots as you also have McFeters/Carter/Heasman and Grossman/Evans in the lineup. Choices, choices.

16:45-18:00 Option 1: Bruce Dang, Methods for Understanding Targeted Attacks with Office Documents. Option 2: Christopher Tarnovsky, Inducing Momentary Faults Within Secure Smartcards/Microcontrollers.

Lots of intriguing hardware talks on Day 2. A lot of it is probably over my head and my first options are more applicable to my day job. There might have to be some room hopping.

I fly out to Vegas tonight — see you all there!

In fact, I found the article to be rather upsetting. Not because of the article’s thesis that strong authentication through a national ID program would not necessarily pose a threat to privacy; but rather, because of their naive (and irresponsible) handling of the realities of the biometric authentication challenge. They gloss over the real security challenges with creating a national biometric infrastructure. Here are the two quotes that are most misleading:

• “Confusing privacy with anonymity has delayed implementation of robust, virtually tamper-proof biometric authentication to replace paper-based forms of ID that neither assure privacy nor reliably prove identity.”
• “This emerging technology makes it virtually impossible to assume someone else’s unique identity.”

The problem that the authors are glossing over is that no such technology exists today, and it is unlikely to ever exist. Now, to be fair, I am assuming that a critical success factor for any national biometric program, as described, would be that the authentication devices have to be available, and usable, anyplace paper-based IDs can be used today. This of course implies that the authenticator must be an inexpensive, commodity device, easy to purchase, maintain, and operate. Such a device would have to be even more ubiquitous than the electronic credit card machine.

The problem is that the authenticator itself may be in the possession of the attacker (Perhaps after you authenticate your legitimate purchase the clerk desires to use your identity herself…). In the history of security controls, when the attacker has unsupervised at-will physical access, the attacker wins. Here are a few examples:

• Defeated copy protection on DVDs ( more & more info)
• Cold Boot Crypto Attack on hard disk encryption (more info)
• MiFare RFID Cards (more info)
• Skimming devices attached to ATM machines to steal card and PIN data (more info)

Of course, all of these systems worked in the lab. But when a security system is widely deployed, it has to withstand an enormous amount of scrutiny, and minor flaws will be exploited. And of course, the greater the financial gain, the greater the time and energy attackers invest in trying to defeat the system. The authors of the article ignore these issues, idealistically assuming biometrics will just work.

Now, of course there are lots of examples where biometrics work very effectively. But I would propose that biometric authentication is most useful when the authentication device is physically secure and the authentication itself is supervised. The MiFare example above also demonstrates two other issues:

• The system chose not to implement a reviewed and standard cryptographic algorithm - always a bad idea
• MiFare was able to sell 1 billion cards and authenticators before the system failed

The cost of investing in a national biometric authentication program, and then having the security fail, is enormous. Can you imagine deploying a biometric authentication infrastructure to every bank, police car, restaurant, shop, etc. and then having video on YouTube of it being defeated ?

- Erik

BTW, Maybe the attacker doesn’t even need to tamper with the device -> ftp://ftp.ccc.de/pub/video/Fingerabdruck_Hack/fingerabdruck.mpg

Art of Information Security would love your feedback !

What do the Cold Boot Crypto Attack, DVD Players, and MiFare tell us about the Future of Biometrics?