There’s one bright spot to the payments industry being encased in a massive overly complex, glacially slow bureaucracy, with certification approval times approaching eons.
That bright spot is that fixing even one tiny element of the process can have a tremendous impact. And the PCI Council has just made such a move, when it sanctioned moving PIN acceptance to merchant-controlled mobile payment devices.
That one small step, moving the PIN process from a countertop unit to a smartphone or tablet, could make all the difference for micromerchants, especially outside the U.S. And payment facilitators will be at the very front of the line to help.
“This will open up MPOS worldwide in a way we’ve never seen. It’s absolutely groundbreaking for micromerchants” who process “less than (the equivalent of) $50,000 U.S. a year,” said Todd Ablowitz, CEO of Double Diamond Group.
Ablowitz argued that the costs and fees involved in payments makes adding a PIN pad—along with its PCI certification—unacceptable for many non-U.S. micromerchants, who have always struggled with chip and PIN. “In a place where PIN is mandatory, micromerchants have been left out,” he said.
Let’s drill into what the PCI Council has done. For merchants who have already made the move to EMV—and EMV full acceptance is a prereqequisite for mobile PIN under the new PCI rules—they are now permitted to move the PIN acceptance mechanism to a merchant’s mobile POS offering. (To hear these details in the council’s own words, we’ll start with few details—the council’s news release—to more details [the council’s surprisingly helpful Q&A] to full details with the actual requirements.)
The council has put in place some security to try and maintain the anti-fraud mechanisms of existing systems. For example, it has “introduced the requirement for a back-end monitoring system for additional external security controls such as attestation (to ensure the security mechanisms are intact and operational), detection (to notify when anomalies are present) and response (controls to alert and take action) to address anomalies” the council said.
It is also adding “a requirement of software-based PIN entry (which) is that the account data is received and encrypted by a Secure Card Reader for PIN (SCRP) attached to the COTS [mobile] device. That is a new form factor that will be introduced within PCI PTS POI v5.1, which will be released soon.”
Part of the magic here is the separation of the Primary Account Number (PAN) from the PIN, at least initially.
“This isolation happens as the PAN is never entered on the COTS device with the PIN. Instead that information is captured by an EMV Chip reader that is approved as an SCRP that encrypts the contact or contactless transaction,” the council said. “The standard requires that the PIN is further protected by the continuous monitoring of the environment to confirm the integrity of the PIN CVM Application that receives the PIN as well as for anomalies in the COTS environment.”
Troy Leach, the PCI Council’s chief technology officer, said this separation effort is critical.
“A key security objective is to isolate the PIN within the COTS device from the account identifying information, which might be used in a correlation attack,” Leach said. “A correlation attack occurs when a fraudster can obtain some payment data elements, such as magnetic stripe track 2 data, from one part of the payment ecosystem (e.g. skimming of payment card), and another data element such as a PIN from a separate attack, and then manages to link these data elements to enable a fraudulent transaction.”
The continuous monitoring mentioned is hardly overkill. Remember that these are mobile devices, with different mobile OSes and absolutely different handset manufacturers.
Consider this comment from the standard itself: “There are individual components of a software solution where there is limited control—for example, the underlying mobile device hardware platform and operating system. Given that these are COTS devices, there is an assumption that these components (e.g., COTS operating system, configuration of hardware components of a phone, etc.) are unknown or untrusted. It must be assumed that an attacker has full access to the software that executes on any unknown or untrusted platform (where that “software” may be a binary executable, interpreted bytecode, etc., as it is loaded onto the platform).”
“Therefore,” it continued, “it is considered important for the software to provide inherent protections that complicate reverse engineering and tampering of the code execution flow. This may include, but is not limited to, protections using ‘obfuscation’ of the code, internal integrity checks for code and processing flows and encryption of code segments, etc..”
In short, the council is planning on making vendors pushing a mobile PIN approach to jump through a lot of hoops. The news is that PCI will permit it, but there’s nothing there about making it easy. Quite the contrary. Therefore, it’s incumbent on PFs to get moving fast — the PFs who can get through those hoops first will have a huge advantage.