Fin

Thursday, August 25, 2011

My last day is tomorrow. I'm sad to go, but happy to get back to Oregon. Here are some links to the more informative posts:

You can find the poster that Olga and I worked on here, and my final report for DREU here.


Bank PICC Features

Friday, August 19, 2011

Bank smartcards typically function according to the Europay, MasterCard, and Visa (EMV) standard, which describes the interaction between a smart card and a terminal. Protocols most people have heard of, such as PayPass or ExpressPay, build on the EMV standard. The EMV standard was originally designed with ISO/IEC 7816 smart cards in mind, but has since also been applied on top of ISO/IEC 14443 contacless (NFC) smart cards.


The core of the EMV protocol is based on the transmission of Application Protocol Data Units (APDUs). The PCD pushes a Command APDU to the PICC, and then the PICC computes the response and pushes a Response APDU to the PCD. Most of the APDUs sent between the two are transmitted in plaintext. Cryptographic security is only employed in the authorization phases of a transaction.


In many implementations there exist safegaurds to deactivate the PICC in the event of a brute-force attack on the authentication system. This same sort of safegaurd even exists on the Secure Element in the PN65N chip for the Nexus S. Because of this, it is impractical to attempt any sort of brute-force attack with the aim of key recovery. To do so with any success would require a very large number of credit cards. Even if this was achieved, Point of Sale terminals are capable of blacklisting certain keys and downloading new ones from Issuers.


This makes bank PICCs difficult to crack, but they are still susceptible to relay attacks and information leakage when interacting with a spoofed terminal. While we were unable to complete the relay attack implementation because of complications with card emulation on the Nexus S, I did manage to successfully spoof a terminal and retrieve private information from a card. Newer implementations of bank PICCs are keeping a tighter lid on private information, so they may only be practically susceptible to relay attacks in the future.

NFC Timing Restrictions

Monday, August 15, 2011

One major limitation to relay attacks are connection time-outs and distance-bounding protocols. It takes time to process incoming traffic, modify it as necessary, and send it along. Even if traffic was passed through without modification, the increased distance between the two target systems necessarily increases latency. Usually time-outs are implemented in systems without security in mind; typically with the purpose of ensuring responsiveness. No matter the intent, such time restrictions put upper bounds on the distance between two devices and how much computation can be performed on through-traffic in real-time.


ISO 14443-4 defines timing restrictions for communications between a proximity integrated-circuit card (PICC) and a proximity coupling device (PCD). The Request Guard Time and Frame Guard Time are lower bounds for communication, so they can be ignored for in the context of a relay attack. The Startup Frame Guard Time (SFGT) imposes a maximal limit of 4949 ms to a PCD's response to a PICC's Answer to Select (ATS). The Frame Waiting Time (FWT) can range from 302 μs to 4949 ms, and determines the minimum time between two consecutive frames.


The value of the FWT is sent by the PICC to the PCD during the ATS phase of the Activation Sequence, in the TB(1) byte. It is possible to modify the TB(1) byte in transit since it is sent in plaintext and is unsigned, but it still can not exceed 4949 ms.


If the relay attack system was smart, the Activation and Deactivation sequences would be handled by the proxy reader and proxy card without being sent over the network between the two. This would bypass the SFGT limitation.


There's a way to get around the FWT limit in the PICC-to-PCD direction. A PICC can request more time (up to 292 seconds!) to respond by sending a S(WTX) message, and these messages can be chained in order to get the PCD to wait indefinitely. Since PICCs are mass produced and cheap, manufacturers may cut corners and solely rely on the PCD to enforce the FWT limit. If this is the case, the FWT limit can be bypassed completely.


An NFC relay attack that implemented both ideas could extend the range between a PICC and PCD indefinitely, and have considerable time to process traffic before forwarding the data. There may be additional timing limitations in the standard that I've not yet found, and I'm sure there exist timing limitations at the application layer between NFC devices. However, this may still be a significant weakness of the protocol as is currently defined. I hope to test this in practice sometime in the future.

Wrapping Up Soon

Monday, August 15, 2011

It looks like we won't have enough time to fully implement a relay attack, so we're settling for the partly-simulated implementation. I've been hunting down corner-cases and potential pitfalls in both my EMV library and UDP-wrapper, and Olga's been working on better integrating the program with the Android OS and reworking the UI. We're aiming for a complete, robust system by this Friday.


Last week I started work on an application that could be used in a survey project that compiles scrubbed data from volunteered cards in the wild. The same EMV library is used as in the relay attack, and I think the logic and UI are nearly complete. The system requires an additional program that runs on a host PC attached to the phone, and unfortunately I won't get around to that before I leave.


Next week Olga and I will start on the Final Report, which has a similar format to a typical academic research paper.

Card Emulation on the Nexus S

Wednesday, August 3, 2011

While the Nexus S is capable of emulating both NFC-A and NFC-B cards, but there are significant barriers in place to prevent user applications from gaining access to this feature.


The phone uses the PN65N chip from NXP, which is combination of the PN544 chip and a SmartMX secure element. There are two ways to make this chip behave like a smart card (PICC):

  • Through the secure element.
  • With a UICC (aka SIM card) that supports the Single Wire Protocol (SWP).

The SmartMX secure element runs the ever-popular Java Card OS, which is essentially a very small JRE. On top of this sits the GlobalPlatform Card Specification, which allows for the management of multiple software card applets. New applets can't be installed into the secure element without knowing the secret keys that Google or Samsung configured the GlobalPlatform card manager with.


If these keys were known, it would be possible to install a simple relay-style applet that forwarded APDUs to and from the Android OS as they were received.


Enabling card emulation through SWP is probably easier, but the UICC used in this set-up won't be able to talk with Android.


Aside from discovering the secure element's secret keys, I see two solutions:

  • Replace the PN65N with another that you know the secret keys to.
  • Attach the SWP pin on the PN65N to a pin accessible by the Android OS rather than than to a UICC.
  • Attach an external USB NFC modem capable of card emulation.

The second solution requires some explanation. The SWP protocol is well defined in TS 102 613. The NFC chip sends information along the single wire by modulating current, and the UICC does the same by modulating the voltage. If a full-duplex I/O pin exists somewhere on the Nexus S that is accessible by the OS, it may be possible to re-purpose it to interface with the PN65N. Of course, such a change would require modification of Android's source code.


The third solution is probably the least messy. Android 2.3.4, which can be run on the Nexus S, has optional support for the Android Open Accessory platform. This allows the phone to behave as a host to a USB device. Such a device might be an NFC modem capable of card emulation.


If I had more time, I'd pursue one of those methods to enable the Nexus S to emulate an NFC card. With only three-ish weeks left, I have to settle with a simulated terminal.

Poster

Tuesday, August 2, 2011

Olga and I discussed the content of a poster we need to turn in soon. It was difficult pruning information down to what was relevant and what fit! For such a large format, space runs out very quickly. I threw everything together based on a template yesterday, and had to shuffle everything around again because the flow of the layout was a bit crazy. Andres is proofing it right now, which is nice of him.


The demo implementation should be complete in time for the poster session, and it will be fun showing our work to interested people. Olga will be finished reworking the UI tomorrow, and I'll integrate the update before the session. Fun, fun!


Update: The session was a success! Wendy Cooper took a great photo of me presenting. Yes, I am dual-wielding phones.

Plan B Complete

Friday, July 29, 2011

I finished up the program yesterday, and Olga is going to make the user experience for it much nicer. The system consists of two phones: a dumb relay that forwards traffic to and from a CICC and a UDP socket, and a terminal that speaks EMV over UDP (as opposed to NFC).


I had to implement a rudimentary handshake in the protocol in addition to basic APDUs in order to control the flow of data. The terminal emulator sends an "I'm ready" packet to the target IP every 6 seconds until it receives an "I'm ready" from the target, at which point it starts sending APDUs. The relay responds to a single "I'm ready" packet when a target CICC is found, and then ignores all additional "I'm ready" packets.


I'm going to start looking into using a Proxmark to emulate an NFC smart card. If we had more time, I'd like to replace the PN544 chip on the phone with one that we know the secret keys of and then modify the Android source with SEEK, so we can use a phone for card emulation. Perhaps we can utilize the Open Accessory kit and glue the Proxmark onto a phone.


Plan B

Wednesday, July 27, 2011

We ran into too many problems with modifying Android, so we're falling back to an emulated terminal in order to complete something by the deadline.


Luckily, my earlier work included an EMV terminal emulator, so it was simple for me to glue everything together yesterday and this morning. I haven't yet tested the system because one of our phones needs to be flashed with official firmware. I'm doing that now.

Building an Android

Monday, July 25, 2011

Compiling Android from source takes hours! Olga and I first built it on Friday, but dependency issues corrupted the output. I think I satisfied those this morning, so we should find out if the hardware was successfully unlocked by later today or tomorrow.


On a different note: I have five plane trips in August, and three of those are cross-country. Fortunately, I have A Dance with Dragons and Pattern Recognition to keep me company.

Field Trip

Friday, July 22, 2011

All of the REU students at UMass went to Cambridge yesterday to check out Google, Microsoft Research, and the MIT Museum.


The most interesting stop was Google, where we talked with Steve Vinter, were led through the offices, and ate at the on-site cafeteria. Everyone was well-prepared and very nice, and I think I'll apply there soon.


There were a few neat exhibits at the museum; I never thought I'd see Kismet in person. (Nor Adi Shamir and Ron Rivest!) The collection of mechanized sculptures ate up most of my time when I was there.


Card Emulation

Wednesday, July 20, 2011

It looks like we'll have to modify the firmware for the phone in order to unlock additional features like CICC emulation. A few other people have done this successfully before and were kind enough to share their modifications. Hopefully we'll have a working device by the end of the week.


It couldn't hurt to apply to the Open Source Software World Challenge if we think we can finish in time.


On an unrelated note: The weather here is so much more extreme than Oregon! Thunderstorms one day are followed by oppressively hot days the next. Even the temperature difference between day and night is crazy. No wonder the roads need repair so often.


Update: I forgot about a field trip to Boston on Thursday, so we'll probably have it done by next week.

Focus

Tuesday, July 19, 2011

We nailed down a project for our project last week: a man-in-the-middle attack. I completed the bridge between the reader and the tag simulator yesterday, and Olga is working on how to get the device to simulate a tag. Today I'll start on the user interface and combine the bridge with the reader.


Only a month left! I hope I can contribute enough in time.

So many refinements!

Thursday, July 14, 2011

I've been tweaking the EMV library all week, and I can finally start reading records from contactless ICCs. For some reason, my code cuts out after the first record.

I figured out why I couldn't talk to some cards: they shut off after about 65,000 uses. If I can get my hands on some fresh cards, I may be able to communicate with them without raising that counter.

Olga and I will be giving a presentation today to the other REU students here about our project. Kind of nervous.


Update: My code successfully reads all available data from financial cards that follow the EMV standard. Hooray! Now time to deal with the issuers that like to tweak things.

Project Update

Friday, July 8, 2011

I've been working on an EMV library with contact-less cards in mind, and it's actually pretty fun to implement a specification. So far it can only talk with one type of credit card. I don't know whether this is because my reader doesn't supply enough power to the other cards or because the other card manufacturers' were too liberal in their application of the EMV standard. I think it may be both.


I finally got a key to the building a few days ago, so I won't have to bother the very nice cleaning ladies that get here early in the morning.

Specifications

Tuesday, July 5, 2011

Dr. Ravi Pappu's talk on how standards are formed during RFIDsec was both enlightening and disheartening. An otherwise beautiful specification becomes bloated to massive proportions in order to support compatibility with existing systems in which the private sector has made considerable investment. I get to wade through 823+ pages of dry specification standards that are riddled with exceptions, and it's nice to know who's responsible for making them so horrible.

After RFIDsec

Wednesday, June 29, 2011

I just finished attending RFIDsec 11 at UMass. Most of the talks were very interesting, and the hands-on tutorial sessions on Sunday were a blast. I have so many ideas now!


I attended a dry-run of the side-channel attacks tutorial on Saturday, which was very interesting. I had heard of the technique before, but it was never discussed in any amount of detail in school. Unfortunately, we ran out of time once everyone learned how to use oscilloscopes.


On Sunday I went to the first two parts of the programmable RFID tags tutorial, run by Shane Clark and Ben Ransford. I hadn't ever worked with microcontrollers before, and it was a great introduction. I then attended the physics of RFID session, which pushed the boundaries of RFID read range.


I won't go too much into the talks themselves, since they'll be available online in maybe a month. Suffice to say, Adi's keynote and a few others were outstanding.


Negin pulled her previous work on my current NFC project yesterday and walked me through it. Much thanks to her!

First Week

Friday, June 24, 2011

Everyone's been very busy this week with RFIDsec, but Andres gave me enough information to start collecting information and playing with code.


I spent the first two days researching NFC itself and the platform I'll be working on. ECMA 340, 352, 356, and 362 will probably be the most useful.


On Thursday I completed a small application that notifies the user when an NFC tag is detected and displays all the tag's available protocols. I extended that today to parse NDEF messages.


All of the tags I tested didn't readily give up NDEF messages on discovery, so the next step is to find out how to communicate with them. Since I don't even know the protocol the tags expect, I'll have to record the traffic between a proprietary reader and the tags. Luckily, a reader is available, but a way to record the traffic is not.


Overall, this week's been a blast. Now it's time for the hard part.

CSS Template By RamblingSoul. Slightly modified by Erin McBride.