rdist

September 4, 2008

What probably happened with Mythbusters and RFID

Filed under: Embedded,Hacking,Security — Nate Lawson @ 1:24 pm

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.]

July 14, 2008

RFID industry tries to spin toll findings

Filed under: Crypto,Embedded,Hacking,Security — Nate Lawson @ 2:10 pm

I was interviewed today regarding my findings regarding the Fastrak electronic toll collection system.  It seems that the industry PR spin machine has already begun responding.

First, this article questions my credibility and claims that the Fastrak transponder is read-only.

‘If Lawson has not even established that FasTrak transponders are a read-only device (best called a “tag”) rather than read-write, then he’s totally unqualified to be talking about potential misuse.’

Apparently the author of the article has not even opened the cover on a Fastrak transponder.  They use an MSP430F1111A microcontroller, which is flash-based.  The firmware and all the data (i.e., your unique ID) are stored in flash.  I can easily authenticate this claim by revealing that your 32-bit ID appears at address 0x1002, which is part of the full “0x0001” Title 21 response packet.

Also reverse engineering this device is hardly much of an accomplishment since all the specifications and protocols of Title 21 are open source.

The base specification for Title 21 is freely available, but the extensions to it are not.  On disassembling a firmware dump from a transponder, I found some surprising things, including messages that allow a reader to update the transponder flash in the field.  Again, I can back up this claim with the message IDs that start this update process: 0x00DE and 0x0480.  To unlock the update process, you need to provide a global key that I will not reveal.

Second, I’ve heard that a vendor plans to issue a press release.  Expect the standard claims that privacy is protected because they “encrypt” your unique ID in their database and data is not retained for very long.  What they mean by “encrypt” is “replace each unique ID with a different one”.  The problem is, replacing the unique ID “CAR-A” with “WXYZ” does not change much.  There is still a unique ID that is stored which always corresponds to the same car, enabling tracking.  Somehow, that information is subject to subpoena, something few Fastrak users are aware of.  Corporations issue privacy policies describing exactly what information is collected and how long it is stored.  Where can I find that information about Fastrak?

Finally, I spoke last week to a consultant to Caltrans who offered to get the local MTC agency technical staff in touch with me.  I explained that I’d be happy to describe my findings and recommendations to them in advance of my Blackhat talk at no charge.  Anyone from those agencies can contact me via my company website here.

July 3, 2008

Dead-listing while on vacation

Filed under: Embedded,Reverse engineering,Security — Nate Lawson @ 10:21 pm

I just got back from a nice vacation with no laptop.  What do I do on long plane rides or while listening to the waves lap against the beach?  Dead-listing.

Dead-listing is analyzing the raw disassembly of some target software and figuring it out using only pen and paper.  This is great for vacations because your laptop won’t get sand in it.  You usually have a long period of time to muse about the code in question without interruptions, something hard to find at home these days.  And I’ve gotten some of my best ideas after setting aside my papers for a while and going for a long swim.

Before you leave, pick an interesting target: not too big, not too small.  Not just x86 either — ever wondered how one of your cellphone’s applications worked?  Never looked at a familiar application’s Java bytecode?  Then, get a copy of a disassembler for your target and run it.  I often use IDA but for less common CPU architectures, any one will do.  Remember that you don’t need full analysis at this point, although it’s useful to be able to separate data from instructions and get basic symbols resolved.

Search the assembly code for any external libraries that might be important.  Disassemble them too.  While you’re at it, see if you can find the source code or API reference for any of those files.  Code reuse helps you reduce the amount you have to reverse yourself.

Now take the listing file and do some cleanup.  I like to use a small font that prints well and convert all the call (subroutine) instructions to bold.  I insert some extra empty lines before each call target to allow me room to write notes.  Finally, I print the listing in landscape with two columns per page.  This leaves room for notes on the righthand side of each column and some at the bottom.  A binder clip makes it easy to keep pages in order or remove them to compare.

Since you won’t have access to the Internet, you’ll need to find some basic reference materials.  The key is to get the basics without carrying a ream of paper.  For an embedded system, I usually find or make a small instruction set reference sheet including status flags, I/O port table, PCB layout photos, and any integrated peripherals I find during a brief search of the data accesses.  Print these out and put a full copy of all the files on a USB flash drive.  You might stop by an Internet cafe if you find you really need to read a missing page.  I’ve never found that necessary though.  If I can’t infer the function of a particular I/O access, I’ll just look at the whole block’s general effect and take a guess.

The most important part is to stay light.  You don’t need exhaustive manuals (e.g., instruction timing).  Instead, treat these barriers as a challenge.  For example, most timing loops are relative to each other.  You can figure out that one loop is twice as slow as the other without knowing its exact delay in nanoseconds.  Doing hexadecimal conversions on paper builds character.

Once you’re away, enjoy doing a little bit at a time.  I’d often work through a subroutine or lay out a switch statement over coffee before the family gets moving, then set it aside for the rest of the day.  Before putting it down, keep a separate log of open questions and tasks, marking them off as you solve them.  I usually reserve a page in this notebook as my “symbol table”, marking down function names/addresses as I finalize them.

I mostly work through the code in two modes: looking for high level blocks or walking through a single subroutine in detail.  Was this compiled C or C++?  How does the optimizer work?  When accessing hardware, where did the author use inline assembly?  Draw arrows, bracket blocks, use highlighters if that’s your style.  Since it’s more free-form than working on a computer, you’ll find new ways to annotate it.  The amount of marks per page gives a good idea as to code coverage so you can start a day by refining an existing page or try to take a broad guess what a blank page does.

I am always surprised how much I accomplish in only a little bit of time using this method.  It’s also so much fun.  Throw in reading a few interesting but unrelated books and you may wax philosophical on the meaning of life or why the compiler suddenly switched to byte instead of word operations for a single function.

I hope you have a great summer.  Be sure to stop by my Blackhat 2008 talk, “Highway to Hell: Hacking Toll Systems“.  I’ll be posting more details about it here in the coming weeks.

June 5, 2008

Interview about DRM on Security Focus

Filed under: Embedded,Misc,PC Architecture,Security,Software protection — Nate Lawson @ 10:52 pm

Security Focus just posted this interview of me, talking about DRM. Here are a few choice quotes.

On authoring software protection for Vista:

The rules of the game are changing recently with Microsoft Vista kernel patch protection. If you’re a rootkit author, you just bypass it. If you’re a software protection designer, you have to play by its rules. For the first time in the PC’s history, it’s not a level playing field any more. Virus scanner authors were the first to complain about this, and it will be interesting to see how this fundamental change affects the balance of power in the future.

On using custom hardware for protection:

Custom hardware often gives you a longer period until the first break since it requires an attacker’s time and effort to get up to speed on it. However, it often fails more permanently once cracked since the designers put all their faith in the hardware protection.

May 30, 2008

Chris Tarnovsky demos smart card hacking

Filed under: Embedded,Hacking,Hardware,Security — Nate Lawson @ 3:21 pm

Chris Tarnovsky spoke to Wired and demonstrated his smart card hacking techniques. Chris became famous for hacking Echostar cards, which resulted in a multi-billion dollar lawsuit against News Corp. The trial ended in a pretty big win for DirecTV smart card supplier NDS, with the jury only finding them guilty of trying out a packaged attack that converted a DirecTV smart card to decrypt Dish Network video. The penalty for this? A whopping $46.95 (i.e., one month’s subscription fee) plus statutory damages.

In the video, Chris demonstrates some interesting techniques. It shows him decapsulating an ST16 CPU made by ST Micro from an IBM Java card. Then, he uses nail polish to mask the die and rust remover (i.e., hydrofluoric acid) to etch away the top metal layer of protective mesh to get at the CPU’s bus. He then uses a sewing needle to tap each line of the 8-bit bus in turn and then reassemble the data in software. He could just have easily driven the lines, allowing him to change instructions or data at will.

This attack is pretty amazing. It is simple in that it does not require an expensive FIB or other rework tools. Instead, a microscope and careful work with some household chemicals is all it takes. While the ST16 is a bit old, it was used in Echostar, hence the relevance of Chris’s demonstration. It will be interesting to see what happens next in the evolving capabilities for home-based silicon analysis.

May 6, 2008

Warning signs you need a crypto review

Filed under: Crypto,Embedded,Hardware,Security — Nate Lawson @ 10:59 pm

At the RSA Conference, attendees were given a SanDisk Cruzer Enterprise flash drive. I decided to look up the user manual and see what I could find before opening up the part itself. The manual appears to be an attempt at describing its technical security aspects without giving away too much of the design. Unfortunately, it seems more targeted at buzzword compliance and leaves out some answers critical to determining how secure its encryption is.

There are some good things to see in the documentation. It uses AES and SHA-1 instead of keeping quiet about some proprietary algorithm. It appears to actually encrypt the data (instead of hiding it in a partition that can be made accessible with a few software commands). However, there are also a few troublesome items that are a good example of signs more in-depth review is needed.

1. Defines new acronyms not used by cryptographers

Figure 2 is titled “TDEA Electronic Code Book (TECB) Mode”. I had to scratch my head for a while. TDEA is another term for Triple DES, an older NIST encryption standard. But this documentation said it uses AES, which is the replacement for DES. Either the original design used DES and they moved to AES, or someone got their terms mixed up and confused a cipher name for a mode of operation. Either way, “TECB” is meaningless.

2. Uses ECB for bulk encryption

Assuming they do use AES-ECB, that’s nothing to be proud of. ECB involves encrypting a cipher-sized block at a time. This results in a “spreading” of data by the cipher block size. However, patterns are still visible since every 16-byte pattern that is the same will also encrypt to the same ciphertext.

All flash memory is accessed in pages much bigger than the block size of AES. Flash page sizes are typically 1024 bytes or more versus AES’s 16-byte blocksize. So there’s no reason to only encrypt in 16-byte units. Instead, a cipher mode like CBC where all the blocks in the page are chained together would be more secure. A good review would probably recommend that, along with careful analysis of how to generate the IV, supply integrity protection, etc.

3. Key management not defined

The device “implements a SHA-1 hash function as part of access control and creation of a symmetric encryption key”. It also “implements a hardware Random Number Generator”.

Neither of these statements is sufficient to understand how the bulk encryption key is derived. Is it a single hash iteration of the password? Then it is more open to dictionary attacks. Passphrases longer than the input size would also be less secure since the second half of the password might be hashed by itself. This is the same attack that was usable against Microsoft LANMAN hashes but that scheme was designed in the late 1980’s, not 2007.

4. No statements about tamper resistance, side channels, etc.

For all its faults, the smart card industry has been hardening chips against determined attackers for many years now. I have higher hopes for an ASIC design that originated in the satellite TV or EMV world where real money is at stake than in complex system-on-chip designs. They just have a different pedigree. Some day, SoC designs may have weathered their own dark night of the soul, but until then, they tend to be easy prey for Christopher Tarnovsky.

Finally, I popped open the case (glued, no epoxy) to analyze it. Inside are the flash chips and a single system-on-chip that contains the ARM CPU, RAM, USB, and flash controller. It would be interesting to examine the test points for JTAG, decap it, etc.

Knowing only what I’ve found so far, I would be uncomfortable recommending such a device to my clients. There are many signs that an independent review would yield a report better suited to understanding the security architecture and even lead to fixing various questionable design choices.

« Previous PageNext Page »

Blog at WordPress.com.