The rapidly expanding mobile payments market is attractive to merchants because of the low entry barrier to obtain a smartphone or tablet device. Dozens of companies, acquirers, and payment entities offer mobile payment solutions, and hundreds of thousands of merchants use them. Despite its convenient and futuristic qualities, the mobile platform was not designed as a secure application environment and seriously lags behind in payment security.
If I were a hacker, I would invest my time in devising ways to attack mobile smartphones. Think of the sensitive data stored or entered in your smartphone, such as bank login information, credit card numbers, and your personal information. Because it is connected to the Internet at all times, a smartphone is at great risk for malware designed to grab sensitive information. There are two principal problems I see in processing payments through personal mobile/tablet devices.
Problem 1: The apps
The drawback with processing payments through a personal smartphone is that application installation cannot be controlled. App stores do their best to thoroughly review apps, but it's almost impossible to guarantee every app will play nicely in the sandbox. A point-of-sale transaction using a smartphone requires a card reader (e.g., Square) to read the data from the card's magnetic stripe. Hardware may clip into the audio input port or access the phone keypad. On most mobile platforms, access to incoming data from input devices may not be locked and could potentially be read by another running app. That rogue app could be listening for and intercepting unencrypted credit card numbers.
Here's a real-world example. A merchant who accepts credit cards through their iPhone downloads a flashlight application written by an ill-intentioned hacker. This hacker wrote the application to periodically "wake up" to listen for data via the audio port. When the iPhone is used to accept payments, the malicious code embedded in the flashlight app could potentially gain access to incoming payment card data from the unencrypted card reader or from the phone keypad, and send the card numbers back to the hacker who developed the flashlight app.
Problem 2: The phones
Mobile payments blossomed overnight before the phone industry was truly ready. Smartphones were never designed for data security like full-fledged computers are. To truly secure the mobile payments space, smartphones must change. In the future, payments may be processed on a separate secure chip integrated into phone hardware, inaccessible by other applications. When that happens, secure processing on mobile devices will be no problem, But until that time, security for mobile payments is extremely limited.
Best practices for mobile payments
The best scenario for merchants who wish to accept mobile payments is to dedicate the use of a smartphone or tablet solely to payment processing. This means the ability to install apps, access phone settings, send or receive texts, make or receive a call, or take photos must be disabled. When the device is on, it strictly runs the POS application, and at the end of the day all devices are collected and kept in a secure location. If done correctly, this solution can be completely PCI compliant. I have personally seen taxicab companies successfully implement this mobile payment solution. The disadvantage of device dedication is it completely defeats the purpose of owning a smartphone that doubles as a communication device.
How can I safely use my personal device for mobile payments?
The safest option using a personal mobile device to accept payments is to use an encrypt-at-swipe hardware reader. Early adopters of swipe devices were virtually throttled by the security industry for not encrypting data before it entered the phone, so companies like Square have recently upgraded their hardware to encrypt-at-swipe. Encrypting at swipe indicates that the device encrypts card information before it goes into the smartphone, and the mobile processing service decrypts it after it leaves the phone. Even if someone hacks the smartphone, or if a smartphone app listens to the audio port, all that would be detected is a useless string of ciphertext. A word of caution: manually keying a card number is not a safe alternative if the hardware doesn't read and encrypt the card data. Merchants should perform due diligence when selecting mobile POS hardware to ensure it supports encrypt-at-swipe.
The Payment Card Industry Standards Security Council (PCI SSC) is the organization responsible for defining mobile payment security requirements. Until the final standard for mobile payments is defined, the PCI SSC counsels merchants to "make their own risk assessments around the use of mobile payment solutions, considering the advice of their QSA and in consultation with their acquirers and applicable payment brands" (PCI Security Standards Council, 2011). Even after guidelines are released, there will be a transition period between current smartphone devices and future smartphone devices with secure chip technology.
To summarize: mobile is a pernicious and promiscuous environment for payments. Until future mobile payment regulations are published, the most secure ways of mobile processing are dedicating a device or using encrypt-at-swipe hardware.
Gary Glover is director of security assessment at SecurityMetrics and participates on the PCI SSC mobile task force. He began his career at McDonnell Douglas developing AI and expert systems for rocket and propulsion systems. He spent nearly 10 years in software engineering and is the author of two U.S. patents.