Intro

Researching the NFC payment technology could be a difficult task and sometimes a nightmare without the adequate toolset. Even when we can implement an emulation technique to analyze a transaction, sniffing without altering the data might be a laborious job.

Some people utilize the ACR122u RFID reader to research the NFC technology, but the main limitation is the sniffer support; how to sniff without altering the original data behavior. Sounds funny, but it is like smelling a delicious cake without tasting it.

Proxmark3 has a fantastic functionality to sniff data, and we will test it with Apple Pay. Any piece of hardware or software has limitations or flaws which could be exploitable, and Apple Pay is not the exception.

This year, Tim Yunosov presented a very impressive research in Black Hat USA about Apple Pay. His methodology and reversing techniques were impactful. Narrowing his investigation to the software side attacks, I will focus on what happened in the hardware|signals side after an user validated a transaction. Clearly, I will not discuss any flaw or methodology that an attacker could implement against Apple Pay.

Hardware & Software

I will use the Proxmark3 RDV2, Mac OS 10.13.1 and the Proxmark library: https://github.com/iceman1001/proxmark3. The installation details are in its wiki page. After we installed and configured Proxmark3, we are able to start.

Running Proxmark3:

> proxmark3 /dev/tty.usbmodemXXXX

We can see a list of hardware details about the device after running the initial command:

[ Hardware ]
–= uC: AT91SAM7S512 Rev B
–= Embedded Processor: ARM7TDMI
–= Nonvolatile Program Memory Size: 512K bytes, Used: 199629 bytes (38) Free: 324659 bytes (62)
–= Second Nonvolatile Program Memory Size: None
–= Internal SRAM Size: 64K bytes
–= Architecture Identifier: AT91SAM7Sxx Series
–= Nonvolatile Program Memory Type: Embedded Flash Memory

At this point, I used the hf(high frequency) command to list the help section:

pm3 –> hf
help This help
14a { ISO14443A RFIDs… }
14b { ISO14443B RFIDs… }
15 { ISO15693 RFIDs… }
epa { German Identification Card… }
legic { LEGIC RFIDs… }
iclass { ICLASS RFIDs… }
mf { MIFARE RFIDs… }
mfu { MIFARE Ultralight RFIDs… }
mfdes { MIFARE Desfire RFIDs… }
topaz { TOPAZ (NFC Type 1) RFIDs… }
tune Continuously measure HF antenna tuning
list List protocol data in trace buffer
search Search for known HF tags [preliminary]
snoop Generic HF Snoop

Because we want to sniff a NFC transactions we should use the ISO14443A support, selecting the 14a:

pm3 –> hf 14a
help This help
list [Deprecated] List ISO 14443a history
reader Act like an ISO14443 Type A reader
cuids Collect n>0 ISO14443 Type A UIDs in one go
sim — Simulate ISO 14443a tag
sniff sniff ISO 14443 Type A traffic
raw Send raw hex data to tag

With the “sniff” option, we will be able to capture the transmission data. Remember to use the button in the Proxmark3 to stop the sniff feature after the transaction occurred.

pm3 –> hf 14a sniff

Running this option in background, we should approach the Proxmark3 close to the PoS/terminal and the iPhone device to make the transaction. The Proxmark3 has to be very close to both devices during the transmission to obtain all the native and APDU commands. After we finished the transaction, we should press the button in the Proxmark3 to stop the sniffing order. After pressed the button, we see this:

#db# cancelled by button
#db# COMMAND FINISHED
#db# maxDataLen=6, Uart.state=0, Uart.len=0
#db# traceLen=571, Uart.output[0]=000000f2

Now we are able to see the transaction log implementing the “list” feature:

pm3 –> hf 14a list

In this table we have the initial/ending timing, source, data, CRC(cyclic redundancy check) and annotation fields:     screen-shot-2017-12-20-at-6-05-40-am.png

If we used to read APDU commands, we can notice that they are not just pure APDU orders anymore. It is a combination of native commands and APDUs. The interesting part of the transaction started after the WUPA(Wake Up) section. We have the anti-collision part and the selection of the Apple Pay UID.

Dismembering the APDUs

After the selection of UID, we have the RATS(Request Answer To Select) command. From here, we can notice some familiar APDUs:

“2PAY.SYS.DDF01” PPSE directory:

68400064 | 68426656 | Rdr | 02 00 a4 04 00 0e 32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 00 e0 42

The terminal/PoS is requesting the “2PAY.SYS.DDF01” PPSE directory information to initialize the transaction.

Apple Pay answer:

68562164 | 68593524 | Tag |02 6f 4d 84 0e 32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 a5 3b bf 0c 38 61 1a 4f  07 a0 00 00 00 03 10 10 87 01 01 9f 2a 01 03 42 03 41 36 93 5f 55 02 55 53 61 1a 4f 07 a0 00 00 00 98 08 40 87 01 02 9f 2a 01 03 42 03 41 36 93 5f 55 02 55 53 90 00 12 13

This APDU could be interpret with a TLV decoder:

Screen Shot 2017-12-29 at 7.20.05 PM.png

Select the AID(Application Identifier):

68688960 | 68707488 | Rdr |03 00 a4 04 00 07 a0 00 00 00 03 10 10 00 bc 41

This command select the AID(Application Identifier)  a0 00 00 00 03 10 10 00 that we obtained from the last answer. You can learn more about APDU structures from my first NFC post.

Apple Pay answer:

69097588 | 69111604 | Tag |03 6f 3e 84 07 a0 00 00 00 03 10 10 a5 33 9f 38 1b 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 4e 14 bf 0c 12 42 03 41 36 93 5f 55 02 55 53 9f 5a 05 11 08 40 08 40 90 00 be 7e

Using the TLV decoder:

Screen Shot 2017-12-29 at 7.31.10 PM.pngThe PDOL details:

9F66 = Indicates reader capabilities, requirements.
9F02 = Authorized Amount
9F03 = Amount
9F1A = Terminal Country Code
…

Processing Options:

69238144 | 69246432 | Rdr |02 80 a8 00 00 37 83 35 b2 80 40 00 00 00 00 00 01 00 00 00 00 00 00 00 08 40 00 00 00 00 00 08 40 17 12 17 00 8a b9 2d 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  f6 cc

This section is one of the most important and crucial in the transaction. Here is where the cryptogram challenge takes place, and the Secure Element(SE) will respond with the proper information. This command is structured with PDOL from the last response.

If you want to learn more about processing options, take a look at my second post about NFC.

Apple Pay answer:

71376548 | 71429796 | Tag |02 77 60 82 02 20 40 9f 36 02 00 06 9f 26 08 05 81 c8 11 14 17 25 ba 9f 10 20 1f 4a 01 32 a0 00 00 00 00 10 03 02 73 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5f 34 01 00 9f 6c 02 00 80 57 13 41 36 93 00 20 39 02 71 d2 31 22 01 00 00 05 12 99 99 5f 9f 6e 04 23 88 00 00 9f 27 01 80 90 00 4d f8

We can decode this response:
Screen Shot 2017-12-29 at 9.00.38 PM

In this answer, we have essential information to complete the transaction: ATC, Cryptogram, Track 2 or equivalent: 4136930020390271D23122010000051299995F

One important thing to have in consideration is the timing! take a look at the time-line from processing options until the answer. Why it takes longer?