In this post, we will analyze the NFC protocol to find the differences between the two of the most important Android digital payment systems: Samsung Pay and Android Pay. I will not write about NFC issues or flaws. This post is about NFC communication and frameworks.

Background

Samsung Pay implements two protocols: MST and NFC. MST has some flaws and limitations. You can read my MST white paper from the Black Hat website.

In the other hand, Slawomir Jasek presented in HITB conference about the limitations of the HCE(Host Card Emulation) system that implements Android Pay to make purchases using NFC.

Idea

When you add a card to Samsung Pay or Android Pay, a framework behind scenes will enroll that card into the system. This framework could be Visa, Mastercard, Amex or other depending of the card. This process gives a tokenization process to make transactions implementing NFC.

tokenization1

Scenario

I will add the same Visa card in both platforms: Samsung Pay and Android Pay to see how the tokenization works. Also to demonstrate how they implement the same framework behind scenes. This could apply to other systems or platforms as well.

 

This slideshow requires JavaScript.

After I added the card in both payment methods, I will read the NFC transactions using an USB ACR122u and a modified RFIDIOt library to see the characteristics and differences.

Samsung Pay NFC log:Screen Shot 2017-10-08 at 10.37.32 PM

Android Pay NFC log:

Screen Shot 2017-10-08 at 10.39.19 PM

If we analyze both logs, we are able to indicate that Android Pay NFC has some extra records than Samsung Pays. We could find them implementing a brute force attack against the processing options. But what exactly are these records?

The first record is an EMV Proprietary Template containing Public Key Certificate(9F46), and we can decode it:

70 81 B8 9F 46 81 B0 DE 10 51 0D C6 BF DD 34 DC EE E7 50 47 3D 1B 3E 01 C6 0A E2 C9 4C C6 39 A2 0F D2 31 07 E5 C8 BC 55 DE C5 1E B9 0C 24 30 1A 9E EE 0C 7E 27 43 89 AB C2 A9 0E B8 F0 84 1E CD CD 44 B4 E2 7D 8E 2F 0E 23 4D 71 06 9E 19 FD 00 9A 5A 9D B7 41 8F 64 7D 3C 05 E9 05 73 C3 3B 62 BC 31 44 C7 E8 23 AB 2E 4C 2C 71 ED 0E 4E 4C A8 20 FC 69 25 2B B2 6B 0A 36 00 63 FE 0D BE 7D 2F 36 07 7A 20 DD E2 55 78 12 C6 CF A3 DA AA 00 72 00 00 05 02 69 72 C6 75 6A C0 1E FE 7B 56 AD 21 99 4D 3A F1 AE D0 3A 08 9F CE 32 C2 CA 0F 03 C3 36 26 E6 1B 7D 3D 76 9F 47 01 03 90 00

The second record is an EMV Proprietary Template which contains Signed Dynamic Application Data(9F4B). Decoding it:

70 81 B1 5F 24 03 24 03 31 5A 08 46 50 98 29 81 58 73 00 9F 07 02 FF 80 9F 69 07 01 20 56 75 9B 01 80 5F 28 02 08 40 9F 4B 81 80 67 0B C3 E5 63 20 08 94 19 46 1E 2D 86 19 6B A2 9E 2D C3 15 59 4B C2 F8 BA 34 5D 91 5D ED C0 58 6B 69 EE 6A D7 52 69 B5 3C 6C DB 21 23 33 87 1E 2F DC C1 BE 28 90 6D AF CF 58 4F F4 48 8E 8D E2 A2 51 32 8A 2A 9A 98 E9 F6 13 AA FE 79 52 3E 79 C9 39 D8 74 45 B6 26 9F FC E5 14 65 A3 77 AF 0C 3E 4B EE 7C 24 CB CF C9 C9 9B 66 A8 0F 77 57 6B 96 A8 40 5D 1F 8C 5B 63 FC C2 20 6A 79 52 C9 CB 9F 19 06 04 00 10 07 50 01 90 00

If I compare the first token from Android Pay and Samsung Pay, I can notice something interesting:

Android Pay:  46 50 98 29 81 58 73 00 d2 40 32 01 67 50 00 00 01 00 6f
Samsung Pay: 46 50 98 29 81 58 72 92 d2 40 32 01 67 50 00 00 02 37 7f

Seems that the card is a consecutive, and the difference in the last part of it is minimum. If you are asking yourself, why the Samsung Pay token starts with 02(red numbers) instead of 01 like Android Pay? It is because Samsung Pay assigned the 01 to the MST technology and for NFC 02. We can get valuable information to understand their processes.

If you want to learn more about NFC, please take a look at my post about intro to NFC.

What about Apple Pay, is it implement the same framework to add the cards?

Sal.