What probably happened with Mythbusters and RFID

People seem to be upset at the potential censorship Mythbusters’ Adam Savage described when he said industry lawyers prevented him from creating an episode about security problems with RFID.  Now new accounts are being released both by TI and Adam indicating the situation wasn’t so coercive.

According to a TI spokesperson, this all began when:

“To move the process along, Texas Instruments coordinated a conversation with Smart Card Alliance (SCA) who invited MasterCard and Visa, on contactless payments to help MythBusters get the right information.”

And, instead of an army of credit card company lawyers, TI claims that:

“Of the handful of people on the call, there were mostly product managers and only one contactless payment company’s legal counsel member.”

Since I’ve developed for smart cards before and attended an SCA event, I can give more background information on the players involved.  I doubt anything sinister happened, and Mythbusters’ status as an outsider probably contributed to the misunderstanding.

There may be hundreds of different types of system covered by the name “RFID”, so when Mythbusters contacted TI, it’s likely they hadn’t identified exactly what they wanted to talk about.  Given the references to “contactless payment” in TI’s statement, they’re probably talking about ISO 14443 contactless smart cards.  However, there are numerous other implementations of “contactless payment”, for example, the proprietary (and broken) SpeedPass system.

Once they had narrowed down the discussion, it still would not have been clear which payment application Mythbusters would examine.  This is because ISO 14443 merely specifies the communication protocol and modulation, not how to talk to an application to perform credits, debits, etc.  This is probably what the spokesperson was referring to when he said:

“Some of the information that was needed to pursue the program required further support from the contactless payment companies as they construct their own proprietary systems for security to protect their customers.”

The most common application standard is EMV.  It describes a standard between readers and cards to perform payment transactions on top of the underlying wire protocol, whether it is contactless or not.  There are other payment applications supported on a single card.  EMV does describe cryptographic security (encryption and signatures) to authenticate the transactions, say, to prevent unauthorized debits.

But there may be more here when the spokesperson said “proprietary systems for security”.  Depending on the direction Mythbusters took, he could also be talking about attempts to prevent side-channel (DPA) or physical attacks (glitching, probing).  Those are usually very specific to a given implemenation of a device.  It would be interesting to see if Mythbusters was really that skilled to consider attempting those kinds of attacks.

The other interesting thing to note is the presence of product managers on the call.  Most of the time, a product manager can’t answer really technical questions about protocols, interfacing, etc.  Their job is a marketing role — to explain the features of the product in the most appealing light.  A product manager wouldn’t know how to help someone attack their system (nor would they want to), however they would be good at extolling the many great security features their product has.

So while Mythbusters was probably not threatened by the industry, they were definitely being provided a very RFID-positive perspective.  That’s obvious and what any company would do in the same situation.

The biggest question that remains is what exactly did Mythbusters hope to show?  Did they have some outside expert lined up to do the actual work?  If not, why did they start by asking the parties least motivated to help them?

[Update: I think the episode Mythbusters did air about RFID is this one.  They test that an implantable RFID chip does not heat up or explode when present during an MRI.  At the end, they hint that they might investigate payment systems (a quite different type of RFID), but dismiss that plan.]

Packaged virtual appliances in a nutshell

Virtual security appliances — because the vendor who can’t be bothered to package their software to work with multiple OS versions is completely trustworthy to throw in an arbitrary version of Linux, harden it, and keep it up-to-date also.

Chris Hoff has written a nice series of posts about this trend.  The approach of sticking servers from multiple trust domains on the same SAN is a lot like installing a firewall, then tunneling all your apps over http.  Won’t we ever learn?

Old Fastrak transponder design

While riding my bike, I saw the this board in the street.  It looked like a Fastrak transponder so I picked it up.

There are a couple interesting notes.  The board is labeled “TIRIS” (Texas Instruments RFID Systems), which explains the new company name, “SIRIT”.

In the older model, they used a custom Atmel chip instead of the TI MSP430 now in use.  They probably moved to the MSP430 to save money.  There are significantly less analog parts on the older design, which means more of the demodulation may have been done on the custom chip.  There are two clock crystals instead of one.  The buzzer was attached with external wires, not traces.

You can see a teardown of this same model but in nicer shape here.  It looks like the 0006 model was both a cost reduction and generalization of the 0004 model.  It would be interesting to look at the firmware of the Atmel microcontroller and see how it differs.

FasTrak talk summary and slides

Here are the slides from my FasTrak talk and a short summary of my findings.  I’m hoping what I’ve found can help officials improve the security and privacy of these systems.

FasTrak and related toll collection systems have been around since the mid-90’s.  I started looking at them because I had never signed up due to privacy concerns.  However, while the underlying Title 21 standard is public, I couldn’t find any details about the internal workings of the system or any security measures.  I bought a few transponders and took them apart to find out.

Besides support for the standard messages, I found no encryption.  So it’s easy for an attacker to  use a simple RFID reader to collect transponder IDs from cars in a parking lot, then replay them to bill tolls to the real owners.  By only using each stolen ID once, it would be difficult to track them down.

Even more surprising, I found support for a lot of proprietary messages that go far beyond toll collection.  By sending a few packets, an attacker can activate a hidden “update mode” that allows the ID to be wiped or overwritten with a different one.  This goes against claims that the transponder is “read-only” and “there is no memory to write anything to”.

The ability to clone and/or overwrite IDs over-the-air calls into question the admissibility of FasTrak logs as evidence.  They get regular subpoenas for these logs, and I wonder how many innocent people were convicted based on the claimed reliability of this system.  A non-technical attack is to steal a transponder from the victim and surrepititiously plant it in someone else’s car, creating fraudulent evidence that the victim was somewhere they were not.

Also, the 511.org service creates a massive collection of data, logging every section of freeway traveled by each car that has a transponder.  FasTrak has told a reporter (story) that this data is discarded after 24 hours but I can find no written evidence of this.  Since all this system does is generate statistics of average travel times, it could be significantly reduced from its current form.  Instead of querying and logging all cars, it could randomly sample cars so only 1 out of every 100 were used.  Each record could be discarded after 10 minutes or so since the readers are located approximately at each freeway exit.  A car that was logged at one sign but not the next probably exited.

This updated system would still achieve the stated goals while reducing the chances for a privacy compromise.  It also would only require changing the server software, not the readers or transponders.

I’m working on an add-on “privacy kit” to retrofit transponders.  It consists of a timer circuit and activation button, similar to a garage door opener.  It keeps the transponder powered off except for a minute or so after the user presses the button.  This protects the user from privacy exposure (except while paying tolls) and cloning or overwrite attacks.  The downside is it would require technical skills to attach to the transponder.  However, newer models are coming out that have an open battery bay, making it easy to add this privacy kit.

I hope to release schematics free of charge and create a kit that would be available at no profit to myself.  Hopefully this will convince transponder vendors to add an opt-out capability into future designs.

Transit agencies interested in more details on my research can contact me here.

FasTrak transponder and IO tap board
FasTrak transponder and IO tap board

FasTrak findings are serious

I haven’t revealed all the details yet about my Blackhat talk on RFID toll pass security.  One reason was I hoped to speak with Bay Area transit officials to alert them beforehand.  The other reason is that I’ve still been analyzing the potential impact of the flaws I found.

Well, the results are in and it’s pretty serious.  I’m reasonably certain an attacker can send a couple messages to a FasTrak transponder and wipe its internal ID.  Also, the ID can be overwritten with a different one.  There is a population of at least 1 million of these vulnerable transponders in California, sold over the past 15 years.  They conduct 50 million transactions per year on Bay Area bridges.  This does not include their use on southern California toll roads.

I think this is a big deal.  If anyone reading this is responsible for engineering at FasTrak, please contact me.  The messages I’ve sent via your website haven’t worked.  Thanks.