What Apple Pay tokenization means for PCI DSS compliance

Introduction to Apple Pay security

From the consumer's perspective, Apple Pay is an ideal way to conduct a transaction with a merchant because it preserves the consumer's privacy during the transaction.

[Apple Pay is] likely the first of many near-term innovations that will change how point-of-sale payments are processed and secured.

During a normal credit card transaction, the merchant reads the consumer's name and credit card number from the magnetic stripe on the back of the card. This system worked well decades ago when it was first invented because it provided a fast, convenient, standardized way to conduct payment card transactions. However, because mag-stripe card data is not encrypted, fraudsters have stolen billions of dollars in recent years by pilfering unencrypted payment data that they use to make fake payment cards or use in card-not-present online transactions.

During an Apple Pay transaction, the mag-stripe is entirely removed from the equation. Instead, the merchant receives only an anonymized one-time-use code (the token) that facilitates the transaction. Because the token is used in the transaction instead of the actual credit card number, unencrypted payment data is never used by the merchant, which of course is where so many payment card breaches occur.

Tokenization is a fascinating technology and a critical supporting technology, so let's spend some time digging into how Apple Pay tokenization works.

How does Apple Pay tokenization work?

Apple keeps the technical details of Apple Pay under tight wraps, but we can make some assumptions about how it works based upon similar tokenization-based products.

The basic concept is that when a user sets up the technology on his or her phone, Apple Pay authenticates the payment card and sets up a secure trust relationship between the Apple device and the bank that issued the credit card. Once the device establishes the trust relationship, it gains the ability to request tokens that serve as a proxy for the credit card number.

When the device is presented at the point of sale to conduct a contactless payment card transaction, the phone communicates with the payment terminal using Near Field Communication (NFC). The merchant issues a transaction request and the phone prompts the user to verify the transaction and authenticate.

What's unique about Apple Pay, at least on the iPhone 6, is that this authentication uses Apple's new Touch ID biometric authentication features. The phone then sends the merchant a one-time-use token that the merchant can pass along to its payment processor. The transaction then settles normally, without the merchant ever being exposed to the customer's personal information. (The Apple Watch doesn't support Touch ID, so it is believed that a different form of two-factor authentication will be employed in support of Apple Pay transactions.)

The actual technical implementation of Apple Pay may differ in some respects from this description, but the basic concept of tokenization remains the same. Tokenization preserves the privacy of the consumer's credit card data and prevents the merchant from handling raw payment data. Even if an attacker manages to infiltrate the merchant's systems and gain access to used tokens, those tokens would have no value; they do not reveal anything about the consumer and his or her payment data, and they should curtail payment fraud because they cannot be reused.

What does Apple Pay mean for PCI DSS compliance?

Apple Pay represents a clever mash-up of technologies that merchants have deployed for many years. PayPal Inc., Google and other firms attempted NFC payments years ago, but nobody has yet achieved the critical mass necessary to push NFC payments over the line to a mainstream technology. Apple's massive marketing machine may just change that by putting NFC payment technology in the hands of millions of iPhone users around the world. Market data from late last year indicated that Apple Pay accounted for 1.7% of payment card transactions just six weeks after launch, and the number of retailers supporting Apple Pay is likely to increase as more merchants update their point-of-sale systems this year to comply with the card brands' EMV liability deadline.

While consumers will benefit from the added security benefits of using Apple Pay, it only represents a marginal payment card security improvement for merchants, and won't reduce the PCI compliance burden. Why? Because any retail merchant must continue to accept traditional payment card transactions for the foreseeable future. As long as payment card data passes over a merchant's network, it must remain PCI DSS-compliant.

The only way Apple Pay can minimize PCI DSS compliance obligations is when a merchant combines it with a point-to-point encryption (P2PE) technology approved by the Payment Card Industry Security Standards Council (PCI SSC) for traditional card transactions. By eliminating clear-text payment data from their networks, merchants can potentially reduce the scope or number of devices and networks that must meet PCI DSS compliance requirements. As of now, it's unclear exactly how Apple Pay may interoperate with the PCI SSC list of validated P2PE products, but this is certainly an area merchants should follow closely.

While the emergence of Apple Pay doesn't change much for merchants right now, it's likely the first of many near-term innovations that will change how point-of-sale payments are processed and secured. Merchants won't need to do anything special to protect the security of Apple Pay transactions, as they are inherently more secure than traditional card transactions. However, until the PCI SSC says otherwise, a merchant's PCI DSS validation level will remain the same and its compliance processes will remain unchanged.

Eventually it may be possible to combine Apple Pay with other technologies designed to accommodate non-NFC transactions. Indeed, that combination of P2PE and NFC may be the real game-changer for PCI DSS compliance, but it is still at least several years away.

About the author:
Mike Chapple, Ph. D., CISA, CISSP, is a senior director of IT with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Chapple is a frequent contributor to SearchSecurity.com, and serves as its resident expert on enterprise compliance, frameworks and standards for its Ask the Experts panel. He is a technical editor for SearchSecurity.com and Information Security magazine and the author of several information security books, including the CISSP Prep Guide and Information Security Illuminated.