How Merchants Can Protect Card Data in the Mobile-Payments ‘Dead Zone’
Can merchants make payment applications that run on smart phones secure? Yes, but only after they take some steps they might find to be difficult, according to an expert steeped in the intricacies of the Payment Card Industry data-security standard (PCI).
“Smart phones were not built for taking payments, however, they are being used for taking payments,” Gary Glover of SecurityMetrics Inc., a compliance and data-protection firm, told an audience at the Merchant Risk Council’s annual conference last week in Las Vegas. Glover, who is director of security assessments at the Orem, Utah-based firm and is a PCI Qualified Security Assessor (QSA), said he was quoting a MasterCard Inc. executive when he made that statement, but he agrees with it completely.
“It [the smart phone] was never designed for taking payments, but boy it works and you might as well use it, and the industry is leapfrogging ahead of the security community here,” he said. “It’s here to stay.”
But smart phones used for card payments carry a host of hardware and software vulnerabilities when it comes to data security, many well-documented. Many early card swipes, or dongles, that fit in the phones’ audio jacks did not encrypt payment card data. The most notable example was was the first cube-shaped card reader from high-profile mobile-payments provider Square Inc. Square’s later versions fixed the problem, but Glover, who has one of those first dongles, suspects many remain in the market.
“They’ve never offered to change it for me,” he said. “They never said, ‘you should get a new one.’ How many of those are out there?” To some degree, the same problem exists for other mobile-payments providers. Secure readers are now “are more common than not … however, there is still a lot of old hardware out there,” said Glover.
Meanwhile, virtually all smart phones are using Secure Sockets Layer (SSL) encryption to transmit data, so interception by hackers of unencrypted data going out of the smart phone to the processor is not an issue, he said. But even with an encrypting card reader, there is still a very brief time when data can be exposed.
“Transmission risk is very low for credit card data coming from a mobile device; it’s really what happens between swipe and transmission that people are worried about and what we as security experts are worried about,” said Glover.
That’s where security issues can get complex. The best solution, according to Glover, would be if each phone had two rather than the usual one secure element—a computer chip that handles the phone’s major processing tasks. One would run the applications and Web browser and handle other functions, while the other would be walled off for payments.
“When you do that you lock things down,” said Glover. “That’s the thing that phones don’t have now but that they need to move to before we can feel really confident about running [payments] applications on the phones.”
Some manufacturers, such as Samsung and Motorola, now offer such phones, but it will be several years before they account for a significant amount of devices in the market, according to Glover. Plus, while the PCI Security Standards Council hasissued guidelines for mobile-payments software, it yet to actually approve any such apps for smart phones. So what can mobile-device-using merchants do to protect card data in the current “dead zone,” as Glover put it?
Besides assuring that their card swipes do indeed encrypt card data, two other best practices would be to dedicate a smart phone strictly for payments, and to limit the functionality its operating system. No other applications should installed and the phone should not be used for Internet browsing, sending of text messages, or other communications. “In that situation you can actually be PCI-DSS compliant,” Glover said. But he acknowledged that dedicating a smart phone for payments might not be popular with many part-time merchants who use their smart phones for both personal and business matters.
In any event, Glover recommended that merchants do not enter primary card numbers (PANs) manually onto a smart phone’s screen or keypad because of the potential exposure of account data.
Digital Transaction News