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.
- https://www.pcisecuritystandards.org/pdfs/pci_pr_110624.pdf
- http://www.digitaltransactions.net/news/story/3101
- http://risnews.edgl.com/retail-news/PCI-Council–Validation-of-Some-Mobile-Payment-Acceptance-Apps-Now-Possible73855
