Archive for March 2012

Interfacing with a PayPass card under Linux using LibNFC

March 14, 2012

This morning, I received an Orange Cash prepaid debit MasterCard, and preceded to see if I could use its ISO/IEC 14443-A interface to access its EMV application directory.

After spending some time searching the Web, I realised that not many people have successfully attempted to do so using LibNFC (or if they have, they’ve decided to remain quiet about it, for reasons unknown); and resorted to trying to use CardPeek‘s EMV script – which worked successfully with the ISO/IEC 7816 contact interfaces of all of the cards that I’ve tried (until I accidentally broke one of the contact interface pins), but doesn’t work with my reader’s RFID transceiver…

Using LibNFC’s nfc-list -v command, I was able to obtain the following information regarding the contactless interface:

1 ISO14443A passive target(s) found:
    ATQA (SENS_RES): 00  04
* UID size: single
* bit frame anticollision supported
       UID (NFCID1): 29  8b  cf  51
      SAK (SEL_RES): 28
* Compliant with ISO/IEC 14443-4
* Not compliant with ISO/IEC 18092
   ATS: 78 80 82 02 80 31 80 66 b0 84
 12 01 6e 01 83 00 90 00
* Max Frame Size accepted by PICC: 256 bytes
* Bit Rate Capability:
  * Same bitrate in both directions mandatory
* Frame Waiting Time: 77.33 ms
* Start-up Frame Guard Time: 1.208 ms
* Node ADdress not supported
* Card IDentifier supported
* Historical bytes Tk: 80 31 80 66 b0 84 12 01 6e 01 83 00 90 00
  * Tk after 0x80 consist of optional consecutive
      COMPACT-TLV data objects;
    the last data object may carry a status indicator of one,
      two or three bytes.
    See ISO/IEC 7816-4 8.1.1.3 for more info
Fingerprinting based on ATQA & SAK values:
* JCOP31 v2.3.1
* SmartMX with Mifare 1K emulation

I’ve modified the formatting of that command’s output slightly, so that it fits within this blog’s template boundaries –  but the data is identical to what I see when running it.

Since I couldn’t find any useful example code in C or C++ for exchanging ISO/IEC 7816 APDUs with contactless cards, I decided to investigate the possibility of modifying one of the TAMA scripts (UltraLightRead.cmd) in the LibNFC repository, and discovered that by prefixing the EMV commands mentioned in Saush’s blog post with 40 01, I was able to make the card respond to a request for the Payment System Environment.

The resulting script looks like this:

02; // Get firmware version
4A 01 00; // 1 target requested
// Select the payment system environment
40 01 00 A4 04 00 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31;

And the resulting packet received from the card reader’s PN532 chipset looks like:

If I get chance, I’ll probably see if I can modify CardPeek’s EMV script somehow to generate APDUs with InDataExchange (0x40) framing, and hopefully get contactless mode working with my reader (so that I don’t have to implement EMV by myself, in order to test other commands) – but I have my doubts, somehow.

In the meantime, I hope that this discovery is vaguely helpful for others…

Advertisements

New Wireshark USB CCID Dissector Functionality

March 4, 2012

As I mentioned in my previous post, I’ve been working on improving support for dissecting smartcards-related protocols in Wireshark, and delivered preliminary support for the USB CCID specification in November 2011.

Since then, I decided to implement support for switching the protocol used for dissection of payloads sent from the PC to the card reader using Wireshark’s preferences mechanism, after reading the source code for the I2C dissector.

This functionality was accepted upstream in SVN revisions 41151 and 41156, and consisted of two patches – one of which implemented it in a hackish manner, and the other served to clean things up in the hopes of making the code more readable and maintainable.

Prior to implementing this, I decided to conservatively treat data flowing to and from a card and reader in a generic manner, since users are likely to use a diverse range of standardised and proprietary protocols – the result of which looked like:

Now, right-clicking on the “USB CCID” row of the protocol tree reveals a “Protocol Preferences” submenu, which contains another one entitled “PC -> Reader Payload Type“:

The Protocol Preferences Submenu

As you can probably tell, I’ve retained the generic dissection support, in addition to providing the option of dissecting payloads using the dissector for the GSM SIM profile of the ISO/IEC 7816 contact smartcard standard, as developed by the Osmocom SIMTrace project.

Upon activating the SIM dissector, PC_to_RDR_XfrBlock (0x6f) packet payloads should be dissected in a slightly more useful manner:

The GSM SIM dissector

Obviously, there are still some outstanding bugs that I’m aware of (the CCID dissector’s info column text overrides that of the selected dissector, and the GSM SIM dissector itself doesn’t cope with packets without status words well, at present), although I aim to resolve those in time – along with adding support for new payload protocols.

In the meantime, I hope that others will find this enhancement useful.