Intro

Throughout this post, I will explain how the contactless and NFC technologies work, how they differ depending of the their own technology, and how some terms and basic processes apply to both of them.

To understand how the PoS(Point of sale systems) or terminals interact with a contactless card or NFC/digital payment methods(Apple Pay, Samsung Pay or Android Pay, …), I will use the USB ACR122u. Some of the most important libraries to implement with this reader are the RFIDIot, and a forked variation from Peter Fillmore. The Peter’s has specific scripts designs for paywave and paypass(Visa and Mastercard) implementations.

61bwoopv-2l-_sl1500_
USB ACR122u

This contactless reader is supported for different operative systems. Specifically, I will use Mac OS and python 2.7 for these examples. The Smartcard libraty that I will use with python is pyscard.

To explain how the communication process is between a contactless card and a terminal, I will create a scenario: imagine that you are the terminal or PoS and your computer is a contactless card. When you want to use the computer, you turn it on. The computer answers with an image on the display or login screen. You input a password, if it is wrong the computer gives you error. If it is right, it gives you access. Well, same happens in the contactless world: the terminal is in charge to start the communication with the card and asking for information. To do that, it implements commands: the APDU(Application Protocol Data Unit) communication protocol.

APDU protocol is basically a set of commands that the terminal and the card implements to interact each other. But to understand better the concepts and commands, let’s analyze the structure of a contactless card. Seems like a folder with different subdivisions. To have access to each ramification, the terminal has to ask the card for “id-keys” or for the route to get into the information to be able to make a transaction. Structure and terminology:

fig7-4

MF = Master File

PSE = Payment System Environment

ADF = Application Definition Files

AEF = Application Elementary Files

This is the main idea: “You can quickly select an ADF with the Application Identifier (AID). Within an ADF, you can select AEFs with the Short File Identifier (SFI).”

We will talk later about AIDs, and how each company has their owns to identify their cards but also to select info accordingly of their structure.

To explain some APDU commands, I will use some general information from openscdp.org:


Command APDU

The terminal sends a command APDU to the card. This command has a mandatory header and an optional body.

CLA INS P1 P2 Lc Data Le
Header Trailer
Field Description
CLA Class byte
0x00
INS Instruction byte
0xA4:Select Command
0xB2:Read Record Command
P1 Parameter 1 byte
The value and meaning depends on the instruction code (INS).
P2 Parameter 2 byte
The value and meaning depends on the instruction code (INS).
Lc Number of data bytes send to the card.
With the Smart Card Shell the value of Lc will be calculated automatically. You don’t have to specify this parameter.
Data Data byte
Le Number of data bytes expected in the response. If Le is 0x00, at maximum 256 bytes are expected.

Response APDU

The card will execute the command and send a response APDU back to the terminal. The response APDU has an optional body consisting of data and a mandatory trailer with two status bytes “SW1” and “SW2”. SW1 and SW2 combined are the status word (SW). If the status word has the value 0x9000 (SW1 = 0x90, SW2=0x00), the command was successfully executed by the card.

Data SW 1 SW 2
Body Trailer

Case 1 to 4

There are four different cases of APDU:

Case 1
Command: Header
Response: Trailer
Case 2
Command: Header + Le
Response: Data + Trailer
Case 3
Command: Header + Data
Response: Trailer
Case 4
Command: Header + Data + Le
Response: Data + Trailer

We will use these tables as reference for our examples.


Detect, Power and Wake up the contactless card

coilonmodule

How a terminal detects a contactless card? Imaging the wireless charging technique. The Coupling specifically, the terminal’s coil has a constant magnetic field :

figure1.jpg

When a second coil, the contactless coil, gets close to the terminal’s a portion of the terminal’s magnetic field passes through the card’s coil(D2) that activates the contactless card:loosely-coupled-coils-different-diameters.jpg

Starting the communication

With the contactless card structure, we have to select the Payment System Environment(PSE) if there is any, to start the process. To do this, we have to create a command using the APDU header and trailer which are specified in the ISO-7816-4.

Class byte = 0x00 (CLA)
Select command = 0xA4 (INS)
Select by name = 0x04 (P1)
The first record = 0x00 (P2)

So we can create a constant header with this data:
SELECT = [0x00, 0xA4, 0x04, 0x00]

In the trailer part, we need to indicate the byte’s length of data that we will send to the card, the data, and the length of the possible response.

The data is a PSE constant “filename” value, [1-2]PAY.SYS.DDF01, so we have to convert it:

2PAY.SYS.DDF01 = PSE = [0x32, 0x50, 0x41, 0x59, 0x2E, 0x53, 0x59, 0x53, 0x2E, 0x44, 0x44, 0x46, 0x30, 0x31]

Now, we have to add the length of data, the data(PSE) and the length of the possible response. Putting everything together to make a request:

apdu = SELECT + [len(PSE)] + PSE + [0x00]

The last 0x00 means expecting 256 bytes: maximum response length. We have a completed command to test it with Android Pay NFC:

apdu = SELECT + [len(DF_PSE)] + DF_PSE + [0x00]
response, sw1, sw2 = send_apdu( apdu )

Screen Shot 2017-09-12 at 2.17.15 PM

> 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00

< 6F 6A 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 58 BF 0C 55 61 26 4F 07 A0 00 00 00 03 10 10 50 0A 56 69 73 61 20 44 65 62 69 74 87 01 01 9F 2A 01 03 5F 55 02 55 53 42 03 46 50 98 61 2B 4F 07 A0 00 00 00 98 08 40 50 0F 55 53 20 43 6F 6D 6D 6F 6E 20 44 65 62 69 74 87 01 02 9F 2A 01 03 5F 55 02 55 53 42 03 46 50 98 90 00

We can use an EMV Decoder to interpret the data response:

Screen Shot 2017-09-12 at 2.38.41 PM

Now, we have an Application Identifier(AID = A0000000031010): this identification means what type of the card and what company(Visa, Mastercard, Amex, etc.) is assigned to. Also from which country and type of technology. AIDs are very important to keep digging to get more information.

We can create another APDU command to obtain information with that AID:

aid = [0xa0,0x00,0x00,0x00,0x03,0x10,0x10]
apdu = SELECT + [len(aid)] + aid + [0x00]
response, sw1, sw2= send_apdu(apdu)

Screen Shot 2017-09-12 at 2.59.47 PM

> 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
< 6F 6A 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 58 BF 0C 55 61 26 4F 07 A0 00 00 00 03 10 10 50 0A 56 69 73 61 20 44 65 62 69 74 87 01 01 9F 2A 01 03 5F 55 02 55 53 42 03 46 50 98 61 2B 4F 07 A0 00 00 00 98 08 40 50 0F 55 53 20 43 6F 6D 6D 6F 6E 20 44 65 62 69 74 87 01 02 9F 2A 01 03 5F 55 02 55 53 42 03 46 50 98 90 00
> 00 A4 04 00 07 A0 00 00 00 03 10 10 00
< 6F 6A 84 07 A0 00 00 00 03 10 10 A5 5F 50 0A 56 69 73 61 20 44 65 62 69 74 87 01 01 9F 38 36 9F 66 04 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 9F 01 06 9F 09 02 9F 15 02 9F 16 0F 9F 1C 08 9F 1E 08 9F 33 03 9F 35 01 9F 39 01 9F 4E 20 5F 2D 02 65 6E BF 0C 0F 9F 5A 05 10 08 40 08 40 BF 63 04 DF 20 01 80 90 00

Screen Shot 2017-09-12 at 3.06.36 PM

Sometimes, the decoder does not interpret the response correctly; here it is where a researcher has to investigate about new tags or implementations. What else you can do with APDU commands? read records or brute force attacks against AIDs, SFIs(Short File Identifier) or other things.

Eventually, you will need shortcuts to find information that is hard to get from the card structure. Good luck!