Author: Nate Lawson

Security researcher and consultant, writing about embedded security, crypto, and software protection.

FTC workshop on RFID

~ Nate Lawson ~ 1 Comment

If you’re in Washington, DC on September 23, check out this workshop on RFID.  It aims to explore the security and privacy ramifications.

Workshop participants will discuss the increasing prevalence of contactless payment devices in everyday consumer transactions, including credit card purchases and public transit.  Panelists will further discuss the growing utilization of item-level tagging in the retail sector.  The workshop will explore security and privacy threats and proposed solutions, as well as consumer awareness and education initiatives regarding these developments.

I’ve never attended one of these workshops but one phrase is troubling.  The focus on “consumer awareness and education” seems to represent an attitude that the only problem with RFID is PR.  I doubt any of the security or privacy problems with RFID can be solved by user education.  Transcripts of the last workshop the FTC held on this subject can be found here.

The event will be webcast if you can’t make it and comments can be submitted until October 23.

Xbox 360 security talk

~ Nate Lawson

This recent video of Michael Steil and Felix Domke talking about the Xbox 360 security scheme is the best overview I’ve seen so far.

Michael previously gave a nice talk summarizing the security flaws in the original Xbox.

The CPU itself supports hashing and/or encryption of physical pages, based on flags set in the upper word of the 64-bit virtual address.  They talk about how Felix was able to leapfrog off shader-based DMA to write to an unencrypted register save state structure, jumping through a syscall gate (sorta like return-to-libc) that was improperly validated by the hypervisor.  The end result was arbitrary code execution in the context of the hypervisor.  Quite impressive.

I’ve always wondered how different security features like encrypted RAM that have long been present in smart cards would take to “trickle-up” to the more complex platforms like game consoles.  While the Xbox 360 security is much better than the original Xbox, it seems like the big-systems people are reinventing techniques already tested and worked out in the microcontroller world.

For example, the 360 was vulnerable to a timing attack, where an internal secret key can be guessed by timing how long it takes to validate the submitter’s HMAC.  I’d be extremely surprised if any mainstream smart card were vulnerable to such a well-known legacy bug.

I have yet to see anyone publish information about applying power or RF-based side channel analysis to a game console, despite smart cards adding countermeasures to these almost 10 years ago.  Even earlier attacks on encrypted RAM have still not been attempted on modern systems.

These attacks probably haven’t been needed yet since software bugs were still present. However, the push by game consoles and cellphone manufacturers to increase their resistance to software attacks means it won’t be long before side-channel resistance becomes a must-have feature.  It will be interesting to see how long it takes big-system manufacturers to add countermeasures and whether they’ll choose to learn from the hard lessons we have seen in the smart card world.

What probably happened with Mythbusters and RFID

~ Nate Lawson

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

~ Nate Lawson

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

~ Nate Lawson

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.

Thunderbird and cygwin annoyances

~ Nate Lawson ~ 6 Comments

When I find a functional bug in an application, I think it’s useful to post the solution for others to find.  Here are two recent problems I solved.

Thunderbird allows you to switch SMTP servers.  However, sometimes it appeared like the setting change wasn’t taking effect.  While I’d change the server, some mail would still use the old setting and some would use the new.  Even plug-ins designed to help with this didn’t work reliably.

I tracked this down to the Identities feature.  It allows you to set up different identities (email addresses) under a single account.  This means that with two identities, there are actually three different places the SMTP server and other information is set.  The global account settings panel (Tools -> Account Settings -> Outgoing Server (SMTP)) and all identities (… -> Manage Identities -> Edit each profile) need to be changed in order to switch servers.  While I agree that some things make sense to make local to an identity (e.g., signature file), SMTP server should only be a per-account setting.

I like using cygwin on Windows for a somewhat reasonable Unix-like environment.  There are two shells that can be used: bash and rxvt.  The bash shell runs within a Windows command prompt instance, and inherits the same annoyances from there.  Text selection works differently, there is no real terminal emulation, and scrollback is not reliable.  I switched to rxvt to fix a lot of those problems, but had to keep bash around for one reason.  When I tried to run Windows python from rxvt, it would just hang during startup.  The cygwin python worked fine.

It turns out that the rxvt code allocates a pty.  You can see this by typing “tty” in both bash and rxvt.  The former reports “/dev/console” and the latter, something like “/dev/tty1”.  I believe the reason is that Windows consoles (and thus bash) actually use a separate API for working with the user.  Thus, Windows python calls to that API hang if the shell isn’t actually running in the console.

This is similar to an experience I had trying to do asynchronous IO with a Windows console.  I had written a small serial port comms tool that would work interactively, printing output when the device generated it and accepting input from the user.  It worked fine until the user started typing, then the input routine would block.  Nothing worked with it, not WFMO, setting asynchronous mode on the stdin handle and polling, or even threads.  A read from the console blocks all process execution, including all the process’s threads, until the input is completed.

I hope this helps you if you encounter similar problems.