Does the Apple Pay token contain cardholder data?

Apple Pay could be a big deal for the payment industry because — besides all the other business and marketing considerations — it looks pretty attractive from a security point of view. Here’s why:

1. Two-factor authentication on every transaction — “something you have” (iPhone) + “something you are” (fingerprint). The security level is higher than Chip & Signature — “something you have” (your card) — and is similar to chip and PIN — your card as “something you have” plus PIN as “something you know”. However, the biometric fingerprint is usually stronger than 4-digit PIN, which can be guessed or stolen through skimming. Therefore, the Apple Pay’s cardholder authentication is stronger than even chip and PIN, meaning that there are fewer fraud risks for merchants, issuers, card brands, and service providers.

2. Using tokenization technology, however it is implemented or called, means that merchants are not exposed to card data in clear text, which in turn means that the merchant’s payment acceptance systems do not have to be PCI compliant anymore. Unfortunately, this does not help traditional retailers much, since their systems (POS + payment terminal) must be PCI compliant anyway in order to process regular payment cards. However, it opens the door for a new way of payment acceptance — virtually, any device with NFC chip (for example, a business or even consumer grade laptop or tablet) can “legally” accept Apple Pay and not worry about PCI compliance. Of course, this statement requires some proof, that’s why I am looking for more details about Apple Pay’s tokenization system.

The security of Apple Pay’s tokenization system is still questionable. Based on information I found so far, the payment token (at least the one used for in-app purchases, as the company has not released enough technical details about in-store purchases) contains encrypted cardholder data — primary account number, expiration date, and cardholder name — which in my opinion reduces the Apple Pay security score a bit.

Below is the fragment of Payment Token Format Reference from the PassKit reference.

It is still unclear whether this is the token format that is being sent from the iPhone device to the payment terminal during an “in-store” Apply Pay session. However, according to Apple, “The PassKit framework provides APIs for Apple Pay. The StoreKit framework provides APIs for In-App Purchase.”

There is another statement from the same Getting Started with Apple Pay document that proves that the payment tokens (and therefore iPhone’s secure element) contain encrypted card data: “The alternative is to provide your own server-side solution to receive payments from your app, decrypt payment tokens and interface with the payment provider.”

Note that this statement specifically targets the in-app purchases, and I am not sure whether the same token is used for in-store purchases or whether the in-store token, even if it has the same format, in fact contains the card data. In any case, it looks like at least the in-app purchase token does contain the encrypted cardholder information.

This fact contradicts Apple’s claim that no card data would be stored on the iPhone device. Usually, “no card data” means that there is no cardholder data at all, even in encrypted form. Some tokenization implementations, for example, use randomly generated tokens that cannot be reversed back to the original PAN (primary account number).

How difficult is to trick the Apple Pay system in order to decrypt the payment token and retrieve the original card data? That’s still an open question, but I am sure hackers have started thinking about it already. Another question is whether Apple is using the same token (or the same data inside the token) for in-store purchases, i.e. whether the in-store token contains the same card data elements as the in-app token.

I hope Apple will release more technical details about its “in-store” tokenization technology to the public so security experts can review it, calculate the risks, and determine the level of security.

(Disclaimer: The views and opinions expressed in this article are mine and do not necessarily reflect the official policy or position of HP.)

Slava Gomzin is a security and payments technologist at Hewlett-Packard and author of the book Hacking Point of Sale: Payment Application Secrets, Threats, and Solutions (John Wiley & Sons, Feb. 2014). He also has a blog on payment security and technology, PayAppSec. In his role at HP, Slava helps create products that are integrated into modern payment processing ecosystems using the latest security and payments technologies. Prior to joining Hewlett-Packard, he was a security architect, corporate product security officer, R&D and application security manager, and development team leader at Retalix, a Division of NCR Retail. As PCI ISA, he focused on security and PA-DSS, PCI DSS, and PCI P2PE compliance of POS systems, payment applications, and gateways. Before moving into security, Slava worked in R&D on design and implementation of new products including next-generation POS systems and various interfaces to payment gateways and processors. Slava currently holds CISSP, PCIP, ECSP, and Security+ certifications.