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.
This contactless reader is supported for different operative systems. Specifically, I will use Mac OS and python 2.7 for these examples. The Smartcard library 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:
MF = Master File
PSE = Payment System Environment
PPSE = Proximity Payment System Environment (Contactless Only)
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
How a terminal detects a contactless card? Imaging the wireless charging technique. The Coupling specifically, the terminal’s coil has a constant magnetic field :
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:
Starting the communication
With the contactless card structure, we have to select the Proximity Payment System Environment (PPSE) 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 PPSE constant “filename” value, 2PAY.SYS.DDF01, so we have to convert it:
2PAY.SYS.DDF01 = PPSE = [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(PPSE) and the length of the possible response. Putting everything together to make a request:
apdu = SELECT + [len(PPSE)] + PPSE + [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_PPSE)] + DF_PPSE + [0x00]
response, sw1, sw2 = send_apdu( apdu )
> 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
We can use an EMV Decoder to interpret the data response:
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)
> 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
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!
Part 2: NFC – Contactless Cards: Brute Forcing Processing Options
Salvador Mendoza 