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.
Friday, August 19, 2011
Monday, August 15, 2011
NFC Timing Restrictions
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.
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
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.
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.
Wednesday, August 3, 2011
Card Emulation on the Nexus S
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):
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:
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.
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).
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 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.
Tuesday, August 2, 2011
Poster
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!
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!
Friday, July 29, 2011
Plan B Complete
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.
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.
Wednesday, July 27, 2011
Plan B
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.
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.
Subscribe to:
Posts (Atom)