In a not so widely disseminated and tough to find statement, the PCI SSC has basically put the kibosh on the PA-DSS certification of any mobile payment applications for the time being. The second paragraph of the statement says it all.
“Until such time that it has completed a comprehensive examination of the mobile communications device and mobile payment application landscape, the Council will not approve or list mobile payment applications used by merchants to accept and process payment for goods and services as validated PA-DSS applications unless all requirements can be satisfied as stated.”
The statement indicated that the Council will be taking up the topic of how to certify these applications and addressing any changes to the PA-DSS program that may be required. However, there was no idea as to when this topic would be addressed until recently when the PCI SSC further clarified their position on this matter through a statement made to Evan Schuman’s StorefrontBacktalk stating that any decision on mobile payment applications will not be issued before April 2012.
The threat from mobile payments made through a Web site modified for mobile devices is no worse than the threat presented by a customer’s home PC. However, applications developed for the Apple or Android marketplaces are a problem. They are totally new applications and these platforms have keyboard loggers embedded in them, so they make PA-DSS compliance difficult, if not impossible. And then there is the question of who is responsible for ensuring they are PA-DSS compliant? The developer? The marketplace? Apple? Google? Then there is the whole issue of ensuring that the application is installed to ensure compliance with the PA-DSS. These are just some of the issues that the PCI SSC and their mobile payments working group have to address.
As I stated in a previous post, mobile payment processing, no matter how you define it, is not the easiest environment to secure. I am glad to see that the Council has seen the light and is approaching their analysis in a careful and considered manner. However, until there are guidelines issued, it is the “Wild, Wild, West” as vendors from the card brands to Google to open source deliver mobile payment solutions. All of which have their issues when it comes to security and PCI compliance.
Google recently introduced their “Wallet” application that runs on a smartphone and uses near field communications (NFC) technology to conduct payments similar to contactless credit cards. For those of you not up to speed on NFC, a bit of background. NFC is a wireless technology that operates in the 13.56 MHz band and can transmit data at 106kbps to 848 kbps at a distance of 1.5” (4cm) to almost 8” (20cm). NFC works similar to proximity cards used with access control systems and, as such, an NFC reader can provide power to the device so that it can be used. In the case of Google Wallet, since the platform is an Android smartphone and can provide power, I would assume that for Google Wallet the phone powers an NFC transmitter. The big difference with NFC from proximity cards is that NFC devices can be rewritten, although for contactless credit cards, they are read-only. NFC also shares some communication characteristics with Bluetooth, but NFC has less range.
The biggest problem with the NFC standards is that they do not specify security protocols, so out of the box, NFC is not secure. That means that security must be added by the developers and that is where we tend to get into trouble. When security is not part of a standard, I get the opinion that a lot of developers look at security as a kludge and therefore do not provide it until an incident happens. The other problem we can encounter is the developer that creates a proprietary security solution. I remember a number of years ago talking to a group of developers about potential security issues their application could encounter and one of them spoke up and said, “Why would anyone want to hack our application?” Indeed, why would anyone? But a number of hackers point to mountain climbers and use their quote, “Because it is there.”
The next largest problem is developing the application to comply with the PA-DSS. Based on how the Google Wallet announcement was written, since there was no reference to the PA-DSS in that announcement, I seriously doubt Google Wallet was developed to be PA-DSS compliant. Since there was no reference to the PA-DSS, I have serious concerns about Google Wallet security. And my concerns get further heightened when I consider Google’s business model of selling information to the highest bidder. No, Google will not be selling credit card numbers, but do you think the PA-DSS stops them from selling your spending habits? If you do, think again.
And finally, being a wireless technology, the obvious threat for NFC is eavesdropping and man-in-the-middle attacks. NFC vendors made the eavesdropping threat all the more easier by offering “developers” free developer toolkits. Up until last year, if you registered at most vendors’ Web sites as a “developer,” the vendor would send you a free developer toolkit that was comprised of software, drivers, samples of cards and the all important reader. It turned out that some enterprising individuals were using these developer toolkits to electronically skim cards. The process was simple enough. Load up a notebook with the necessary drivers and applications, attach the antenna, put that in a backpack and walk the streets. Some were hiring teenagers that worked at convenience stores and the backpack was placed directly under the real reader.
That is not to say that there are no PA-DSS certified mobile payment solutions available. There are some certified solutions from Verifone and other vendors that basically bypass the iPhone, iPod Touch, Android software and use it strictly as a display with no input capability. However, in order to make these solutions work, you or your processor has to support the method of end-to-end encryption that these mobile payment solutions use to secure their transactions.
Hopefully what we get from the PCI SSC regarding mobile payments will be worth the almost year long wait.
UPDATE: This post by Evan Schuman indicates that the PCI SSC may have something of a standard for certain mobile platforms in August or September of this year.
The PCI SSC has released a press release and some articles on this topic.
PCI Guru 
You talked about skimming credit cards by loading a notebook and antenna in a backpack to eavesdrop on transactions. I’m curious where you heard/read about that. Thanks.
Most were proof of concept tests conducted by researchers walking around various cities as well as conducting the under counter tests. However, there have been a very few actual attacks reported by the media, but if the attacks were skimming by walking around or done under a counter was not discussed. The reason more attacks were not likely conducted is the limited number of contactless cards that have been issued.
The attack potential for the current implemented contactless payment device issued in the USA today are difficult to implement. First, standard skimming is not possible, each “track 2” data that is generated by the card is unique, once it has been used it cannot be used again. It is possible to skim the PAN data, but PAN only fraud is easily thwarted if the transaction requires CVV input from the card holder. In the protocol between a contactless card and payment terminal a random number is generated by the terminal and sent to the card and is part of the cryptographic algorithm to calculate the unique track 2 data. This helps prevent the skimming attack of obtaining track data from the card and then using it at a payment terminal.
There is an attack that is more likely that involves two people. One person uses a device that is capable of contactless transactions, NFC could be used. This person takes merchandise to the check
out and pays using this device. The second person is close to someone that has a contactless card. This person has a repeater and antenna that can communicate to the unsuspecting cardholder. The transaction is processed from the payment terminal to the card through the repeater.
Also, not only is the number of contactless card limited, there are not many merchants that accept contactless transaction. Even those merchants that have payment devices that accept contactless cards are not enabled to process the transactions.
The problem with your logic lies in the flaws in transaction processing. A lot of transaction processors only require a valid PAN and an expiration date within the real expiration date range. As a result, with a real PAN, you can use the current month and year as well as whatever for a cardholder name and a large majority of the time, the transaction will be approved. Until that is fixed, I would agree with your analysis.
I could not reply to the interesting reply from the Guru.
“The problem with your logic lies in the flaws in transaction processing. A lot of transaction processors only require a valid PAN and an expiration date within the real expiration date range. As a result, with a real PAN, you can use the current month and year as well as whatever for a cardholder name and a large majority of the time, the transaction will be approved. Until that is fixed, I would agree with your analysis.”
Yes, it does make it difficult to secure data when the banks do not implement the security measures provided by the product. Its amazing to me that the “experts” in the card brands and issuers can’t even do their part of the security correctly.
Not to give the card brands, banks and processors cover, but to be fair, they are businesses as well and they are not able to update their infrastructure and applications any easier than any other business. However, I agree with your summation that it’s difficult for merchants to do their part when the others in the chain are not doing their part.
Correct me if I am wrong, the Google Wallet is a card holder device and card holder’s are not in scope of the PCI DSS. If this was the case, since the data on the magnetic stripe is stored and transmitted in the clear, then the cards would clearly be out of compliance, therefore no merchant or acquirer could ever be PCI DSS compliant.
The PA-DSS are requirements for the payment application used by the merchant.
Google Wallet is an Android Applet that stores your cardholder information securely (not certain as to how that is accomplished). The Android phone must have a near field communications (NFC) capability to broadcast your cardholder information to a receiver when you wish to pay for something. See http://www.google.com/wallet/#utm_source=HA&utm_medium=ha_sem_bk&utm_campaign=en-US&utm_term=%2Bgoogle%20%2Bwallet for more information on the Google Wallet.
Exactly, to my point, this is the payment origination device, not the payment acceptor. The payment device (card, electronic wallet, PC, etc) is out of scope of a PCI DSS audit. What would be in scope is a smart phone application that accepts payment that a merchant would use.
While I concur with your interpretation of the current PCI DSS, you mean to tell me that such an application should be exempt from complying with the PA-DSS under the premise that it is pre-authorization data? That’s a pretty short view in my opinion. This is how we continue to get into trouble, we don’t think ahead to what will happen next. I think this is why the PCI SSC is taking a long look at what might happen next. I am betting that electronic wallets and the like will ultimately be covered under some sort of PCI standard just from a security and privacy standpoint. If they do not, it will become a mess that will create bigger problems.
Well now, that is a totally different question. As long as the card brands and issuers continue to make the security of “sensitive card holder data” a problem for all involved in transaction processing except themselves, then this trend will continue. Anywhere card holder data exists, except on a magnetic stripe or in the issuers servers, will be out of PCI DSS compliance and those entities are subject to fines and legal actions. There is no way to full protect track data when processing transactions since it starts out in the clear from the magnetic stripe.
The card brands only have a relationship and power over the acquirers, they cannot directly go after the merchants. However, the acquirers then pass on the liability to the merchants so ultimately the merchant ends up being the bad guy. If other payment devices are introduced (i.e. smart phones using NFC) then the liability will fall on the issuer. Which so far has been exempt from the PCI DSS requirements, since it is impossible for an issuer to be compliant.
I guess if a merchant will be on the hook for any data breaches relating to smart phones and other NFC tokens, then I guess the only way to ensure they are not breached and held liable is to not take those types of transactions, again stalling the use of alternate payment methods for the card holder.
Since the card brands have successfully made the card holder data so valuable then the only solution is to move away from static data which means the magnetic stripe has to go away. Since that is not happening anytime soon, we just keep putting band aids on the problem.
The problem I see is that people are so cavalier with their data under the mistaken belief that it is someone else such as Amazon.com, Zappos.com, the government, their bank, etc. will take care of protecting their sensitive information. When you start adding in Google and the like that are creating electronic wallets to not only store card information, but then create an ability to transmit it over 802.11 or near field communication, who ensures that Google et.al. are ensuring the security of that information? I think that ultimately these electronic wallet applications will have to be written to the PA-DSS standard and also be certified. Otherwise, you will have everyone and their brother creating applications and who knows if they are secure? For all the user knows they could be sending every account in them to Timbuktu as well as paying for your Big Mac.
I agree, but I am not sure how the brands and issuers will enforce this. And without enforcement there will be no strong security mechanism developed.
I think they need to move away from the current methodology for the payment product, since this product is so easy to counterfeit. To put it in perspective, the US govt has changed US currency 3 times in since 1990 because of counterfeit issues. The static magnetic stripe technology dates back to the 50s.
I also think that the consumer would be willing to pay for a more secure technology, so that the “it costs to much to move to smart card” argument from the issuer goes away. However, if the consumer is going to pay for a more secure payment device, it will have to be one that supports different payment cards and brands. So the marketing departments of the brands will have to get over that.
Is the press release stating the April 2012 date online? Can’t find it. Can you post it? Thanks.
See this posting.
http://storefrontbacktalk.com/social-networks/pci-mobile-payment-guidelines-to-not-appear-before-april-and-probably-much-later/