My article in City A.M. about mobile and crypto payments: Apple Pay, one year later: Why mobile payments have failed to catch on as we're still looking for something better

This essay was previously published in VentureBeat on September 25, 2014. 
Updated with more details about tokenization implementation on October 3, 2014.

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.

Update on tokenization implementation, October 3: 

Apparently, Apple Pay uses "network tokenization" - a technology implemented by payment brands (Visa, MasterCard, Amex) and supposedly based on common "EMV tokenization" approach (the spec was released by EMVCo in March 2014). There is a confirmation at least from Visa for the first part. However, unfortunately, there is no official confirmation for this information from Apple as well as there are no technical details available about Visa Token Service or other brands' tokenization implementations (for example, whether they are compliant with EMVCo spec or not) . Anyway, such implementation scheme, with connection between "network tokenization" (like Visa Token Service) and "EMVCo tokenization", would make sense. Let's assume this is true so we could imagine how it works before we get the actual details. 

"Network tokenization" would address some concerns expressed in my original article and provide answers to some questions. For example, it explains the "device primary account number" field in the picture above. In the "network tokenization" scheme, the token looks the same as the original PAN (19 digits starting from the payment brand's identification prefix such as "4" for Visa) . "Device PAN" probably means that the token is encoded in this field rather than the original PAN. 

"EMV tokenization" uses the format-preserving token which looks like regular PAN but has a special BIN range dedicated by the payment brands for tokens. Thus, the fact that the token is used instead of the original PAN is transparent for existing merchant and payment processing systems. "De-tokenization" is done by payment network (Visa, MC, Amex, etc.) - after transaction authorization request passes the gateway, processor, and acquirer, but before it hits the issuer. This is the first main difference of EMV tokenization from "classic" tokenization implemented by payment gateways and processors, where transaction is "de-tokenized" before it even reaches the acquirer and the network.

Second difference is the way the token is generated and consumed. In "classic" tokenization, the token is usually generated at the back end (merchant's, gateway's, processor's, or acquirer's data center) - only after the authorization request is processed using cardholder data in clear text. This is necessary in order to deliver the original PAN to the point of tokenization which is located at the data center far away from the merchant's point of sale. So the cardholder data is still vulnerable for attacks, unless it is protected by point-to-point encryption, which is still relatively rare due to its high implementation costs for merchants. In Apple Pay, the token is generated and stored in iPhone (the exact details of this mechanism are still unclear so it is a whole separate topic for future research and post). Therefore, the cardholder data in clear text never travels through the merchants' systems. 

And third difference: since Apple Pay apparently uses EMV Contactless protocol for communicating the data between the iPhone device and merchant's payment terminal during transaction, the token is always accompanied by the cryptogram - a piece of additional dynamic encrypted data which changes for each transaction and allows the payment terminal and the tokenization system to authenticate the cardholder and validate the token. Hopefully, the token is invalid without the cryptogram, otherwise, it could potentially be used just as regular PAN for any transaction. 

Finally, some good news for consumers and merchants: there is an indication that "Apple Pay like" systems can be implemented by other mobile payment providers. Here is important quote from Visa website which is worth mentioning:

It means that the payment brands do not intend to keep their tokenization technology limited for Apple private use only, and so payment solutions similar to Apple Pay can be implemented by other mobile payment solution providers such as Google. 

Although all these assumptions sound reasonable, many of them still require official confirmation and additional explanation which are highly anticipated from Apple.

My first take on Apple Pay security in this article published by VentureBeat.

Apple Pay is looking pretty attractive so far from a security perspective. But it’s tokens could be cause for concern...

This is good article comparing Apple Pay and digital wallet cards.
I had two comments, though.

1. There is another startup (in addition to Coin) that tries to capitalize on reanimation of dying magnetic stripe technology - Loop. I have published an article about Coin and Loop in VentureBeat:  

2. I have PayPal debit card (by the way, it is MasterCard, not Discover). Now, as soon as I get my new shiny iPhone 6, theoretically, I can add this card to Passbook and pay with my PayPal account through Apple Pay! Wouldn't it be cool and funny? However, I don't think Apple will allow this because it looks like they are going to control which issuers are participating. I don't think that this is the case with Coin and Loop - they would love to allow as much cards and issuers as possible. Not that I like the concept of Coin and Loop - I am against any attempts to reanimate the dying magnetic stripe technology (by the way, Apple Pay is also based on magnetic stripe cards, but it does it in elegant form, as always). So the important point is that Apple Pay can be limited according to Apple preferences. We have to have a common standard that would be based on Apple Pay technology.

I am getting a lot of questions about my opinion on Apple Pay which was announced this morning along with iPhone 6 and Apple Watch. So here are some first thoughts, very briefly. 

Regarding the technology - unfortunately, there is no much technical details released by Apple so far, so a serious thorough assessment is impossible right now. However, it looks like Apple Pay uses some form of tokenization, which means that breaches like Target or Home Depot will be impossible as merchants will not be exposed to the sensitive cardholder data. A token, which is generated by the device when you add new payment card to the Passbook, will be stored in the secure element and used instead of actual magnetic track of the card. So far so good.

As far as possible effect on the payment industry - it's still unclear whether this system is open or closed. As many Apple things it can be proprietary, so if others can only imitate it rather than follow, its mainstream acceptance can be limited. NFC is open standard, but NFC is just a communication part of it. There are recent precedents, however, when Apple created a relatively open standard in retail - iBeacon. 

And finally, like many things made by Apple - it's simple, elegant, and convenient.

Anyway, I am going to try it as soon as I get my iPhone 6.

This essay was previously published by VentureBeat on August 20, 2014

Recent card data breaches at Supervalu and Albertsons retail chains are just the latest in a long series of high-scale security incidents hitting large retailers such as Target, Neiman-Marcus, Michael’s, Sally Beauty, and P.F. Chang’s. These breaches are raising a lot of questions, one of the most important of which is: Are we going to see more of these?

The short answer is yes; in the foreseeable future we will continue to see more breaches. Here’s why:

1. PCI DSS (Payment Card Industry Data Security Standard) is failing to protect merchants from security breaches. The original idea behind PCI DSS, which was created 10 years ago, was that the more merchants we have that are PCI compliant, the fewer breaches we’ll see. The statistics shows the exact opposite trend: Most merchants who recently experienced card data breaches are PCI DSS compliant. The problem is that, in the 10 years since PCI DSS debuted, the standard hasn’t evolved to address the real threats, while hackers, who have already learned all the point-of-sale vulnerabilities, have been constantly working to enhance their malware.

2. Merchants and service providers are still not widely implementing P2PE (Point-to-point Encryption) technology, which is the only realistic way to address the payment card security problem. Despite the strong support for P2PE from the payment security community, only four solution providers are certified with the PCI P2PE standard, and at least two of them are located in Europe. The problem with P2PE is that it is very complex and expensive and requires very extensive software and hardware changes at all points of transactions processing — from the POS (point-of-sale) in the store to the back-end servers in the data center.

3. Retailers introduce new payment hardware, including tablets and smartphones, that are neither designed nor tested for security issues they face in the hazardous retail store environment. PCI DSS does not address directly any mobile security issues.

4. Updates and new features to POS and payment software open up new risks. Merchants want more features in their software in order to stay competitive. POS software vendors provide those features atop of existing functionality by supplying endless patches. The complexity builds up, extending the areas of exposure, and security risks grow accordingly. Those risks are not necessarily mitigated by continuously updated software.

5. Vulnerable operating systems make it easier for hackers to penetrate a network and install malware. Most POS systems are running on Windows OS, and some retailers are still using Windows XP, which Microsoft has not supported since April 8, 2014. We don’t know how many “zero-day” vulnerabilities are out there, but we know for sure that those vulnerabilities, even if they are discovered and published, will never be fixed.

6. The traces of many card data breaches often lead to Russia. While the main motivation for all of these attacks is probably still financial, the modern Russian anti-Americanism also encourages Russian hackers to attack U.S.-based merchants more as an act of patriotism rather than a crime. This is a new reality that is different from what we had just a few years ago.

7. Finally, EMV technology, which is supposed to “save” the payment card industry, is not a silver bullet solution. Although this is a topic for full separate article, let’s at least just briefly review the EMV problems and see why it’s not going to bring a total relief.

    ● Even if the U.S. starts to transition to EMV immediately, it may take a few years until the majority of credit cards are chip cards. During this interim period and even beyond that, merchants will continue accepting the regular magnetic stripe cards, so they will be still vulnerable to existing attack vectors.

    ● EMV does not protect online transactions: You still need to manually key in the account number when shopping online. Online transactions will be still vulnerable even after full EMV adoption, and for many retailers ecommerce is a constantly growing sector.

    ● Although EMV is more secure than magnetic stripe technology, there are a lot of vulnerabilities in EMV, and many of them are still undiscovered, or their exploits are not yet well developed. Today, when there are so many U.S. merchants accepting magnetic stripe cards, hackers aren’t bothering to research EMV security issues. But once the EMV transition is done in the U.S., the global focus of attacks will shift away from magnetic stripe cards to EMV and ecommerce.

I'll be doing two one-hour book signings at Black Hat USA 2014 and DEF CON 22 conferences in Las Vegas:

Black Hat USA 2014: 
August 6, 2014, 5:30 pm
Mandalay Bay Conference Center, Tripwire booth 141
(I'll be doing a short presentation before the book signing)

DEF CON 22:
August 8, 2014, 11:00 am
Rio Hotel & Casino, No Starch Press community table in Vendor Area

Interesting view on U.S. EMV migration. 

I agree with #1, #2, and #4. 
As a technical guy, I don't care who pays for it (#3): eventually, it's us - consumers - who pay for everything. 
I disagree with #5: ACH and bank transfer threats (and solutions) are completely different from merchants' payments security problems. 
I would agree with #6 but I don't see "real opportunity": there is no mature payment technology available today that could become a real alternative to EMV. Crypto-payments (Bitcoin & Co.) is very promising trend but based on recent series of failures it is still on early proof of concept stages. And there is no single mobile payments technology that is secure enough to be accepted by mainstream consumers.

This essay was previously published by VentureBeat on March 13, 2014

As a payment security expert, I get a lot of questions from people about new payment technologies. Are merchants likely to accept them? How secure are they? A couple of recent startups in this space, Loop and Coin, have been generating quite a few of those questions, and my review of them shows some concerning vulnerabilities.

Loop and Coin are just two examples of mobile payments startups that try to bring an invention to market by marrying their new technology to an existing payment card system. The reason is simple: Their tech is more likely be accepted by the mainstream if merchants can reuse their existing payment hardware and software.

Both Loop and Coin are trying to keep alive the dying magnetic stripe payment system. However, they have another important “feature” in common: By replacing the original plastic cards with digital ersatz, they unintentionally simplify the flow of the stolen credit card data.

Loop

The core know-how of Loop is transforming the traditional magnetic stripe reader device (MSR), which merchants use to accept the magnetic credit and debit cards, into the contactless reader. The powerful magnetic field is generated by the mobile payment device (instead of the payment card’s magnetic stripe), so the card data can be transmitted wirelessly to the same reader.

Although this technique is very interesting from a technical point of view, there are several potential issues with accepting Loop as a mainstream method of payment. First, there is no real innovation here. It’s just a combination of old technologies. Second, from a security point of view, it’s the same nightmare as existing credit cards. It can be even worse because all my cards are now stored in one place. And the card data is not protected when it is transmitted from the mobile device and throughout the system, just like with traditional plastic cards.

Finally, Loop is less convenient than plastic cards, especially, with the fob required for iPhone. Instead of just swiping the card, I need to: hold both the fob and the phone, unlock the phone, find and start the app, select the card, then press the button on the phone and at the same time “swipe” the fob. Not to mention the fact that many card readers are deeply “hidden” inside the customer-facing hardware, such as a bank ATM or gas station’s fuel pump, and therefore cannot be reached by the Loop device.

But most importantly, this system is dangerous to merchants, issuers, and acquirers because it simplifies the credit card fraud process. Hackers don’t need to make the physical plastics anymore – they just load the dump of stolen card data into the single device, and voilà!

Loop’s developers say the app identifies the cardholder before the new card is added to the wallet, so it is impossible to add someone else’s card into your wallet. This “security control” is very weak, and anyone familiar with the design of magnetic payment cards can find a workaround. This protection measure is implemented by comparing the cardholder name, which is encoded on magnetic Track 1 of the credit or debit card, with the name on the Loop app account. A hacker who wants to enter and use the stolen track data can easily fake the name on the card and match it with the name on the Loop account because the cardholder name on the magnetic track is not protected by encryption or digital signature and can be changed to any combination of letters without affecting the payment approval process.

Coin

The idea of Coin is similar but more elegant: replacing several payment cards with a single card-like sophisticated device. The technology behind Coin is pretty impressive, but it raises exactly the same security concern as the Loop device. Normally, when carders want to use the stolen card data to make a purchase in a brick-and-mortar store, they need to produce the fake plastic card, which must look like a real credit card, and encode it with the stolen magnetic tracks. But with Coin, there is no need to produce a good looking physical plastic anymore. The stolen data can be encoded directly into the Coin device.

Carders would have to overcome one obstacle: taking a picture of the real card so they can enter the new card information into Coin through the iPhone or Android app. But I think generating a realistic virtual image of a credit card (so it can be photographed instead of the real card) is cheaper than creating a physical counterfeited card, which requires special equipment such as a PVC printer, an embosser, a tipper, etc.

I am sure that hackers, carders, and cashers will be among the first beta testers (and subsequently the most appreciative users) of such “innovative” technologies. More effective security controls — if they are feasible at all — must be designed for the mobile wallet apps that reuse the existing magnetic stripe technology.

The article is called These new mobile wallet apps will make it easier, not harder, for hackers to hijack your payment card and it's focused on two mobile payment solutions: Coin and Loop. When I started reviewing those technologies and their security features, I noticed that there are potential security vulnerabilities "hidden" in those solutions. The trick is that those vulnerabilities are not threatening directly the consumers or merchants, but they may affect the already weak security of the card payment system itself.