PCI's New Mobile Guidelines Acknowledge Huge Hurdles
The PCI Council officially released its mobile payment guidelines Thursday (Feb. 14), a document that turned out to be anything other than a Valentine to retail IT execs who'd love to know the "all-clear" path to doing mobile payments and staying PCI compliant. Instead, it's more of a pragmatic acknowledgement of the various mobile hurdles that the council sees as currently insurmountable.
The recommendations, of course, also offer the generic list of best practices for mobile device security (such as strongly encouraging full-disk encryption), which is certainly a handy checklist for chains just starting to seriously explore mobile payments.
One key point of the report is to acknowledge the very complex nature of mobile systems, which have far more players than traditional fixed POS systems. For example, the report speaks of the desirability of lab validation for mobile devices and why it's simply—and regrettably—not practical.
"Numerous manufacturers, carriers, software developers, and vendors take part in developing a single mobile device. The various combinations of these entities result in an extremely large number of unique mobile devices. The resulting lack of vertical integration would make a lab validation program difficult," the guidelines say. "All the intervening steps during the production of a mobile device build upon components of the previous steps. For instance, a mobile network operator sells a mobile device manufactured by a specific handset company that contains a chip manufactured by one of several chip-manufacturers and that runs an operating system created by another third party. At each layer, the components added can either increase or decrease the security of the device. For the devices to be adequately tested and validated, proprietary information would have to be shared among all the contributors. If a manufacturer, software developer, or carrier refused to share security-critical proprietary information, validation would be unrealizable. Consequently, the validating of these devices would be problematic."
Therefore, that section concludes: "The unknown trustworthiness of mobile devices for which no independent, standardized security validation is done remains a residual risk."
The report also speaks extensively about the attractiveness of remote wipe—also known as zeroizing—to negate security problems the instant it's detected that a mobile payment device has gone missing. But it also concedes the limitations of such a strategy for many global chains.
"Preventative measures implemented in one jurisdiction may be unlawful to implement in another. For instance, remotely zeroizing a device (i.e., rendering it inoperative) may be legal in the U.S. but not in the European Union, since it may be unlawful to zeroize or otherwise do anything to a mobile device that would remove the user's ability to make emergency calls," the report says. "Adjustments made to accommodate jurisdictional legal issues may adversely affect security. This is likely to remain an intractable residual risk."
Of greater concern, though, are efforts by cyberthieves to guard against such remote wipe efforts. "A mobile device may be shielded in such a way that it may not have the capability of being zeroized remotely (e.g., a Faraday cage). For instance, today mobile phones are being stolen and immediately put into metallic bags that shield them from sending/receiving commands, thereby removing the ability to zeroize the device remotely before the device can be used to divulge sensitive information," the guidelines document says. "This type of attack could also remove the ability to track the device."
Associates trying to steal data directly—or who act as an accomplice for external thieves—is an age-old retail problem. Unfortunately, the guidelines say, the mobile vendor community has no practical way of defending against this.
"At each step in the process of producing a mobile device, the potential exists for a renegade employee to introduce exploitable security vulnerabilities," the report says. "Currently, no commercial vendors perform the level of hardware or software review necessary to assure detection of this kind of sabotage."
And current anti-malware applications, which have become such a critical part of desktop security, are also not ready for primetime with mobile yet. "Current anti-malware products would be impractical to employ because of the tremendous amounts of resources required to run them (e.g., battery life significantly decreased)," the guidelines say. "Additionally, such products would have no assurance that they could complete their testing before being terminated by the OS to release resources for other tasks."Memory management and mobile operating systems are also of minimal help. "Mobile devices are developed for the ease of use of the consumer with optimized usability. As a result, the memory-management techniques of mobile devices will shut down applications and discard data based on the needs of the system as a whole. These memory-management techniques will likely result in a payment-acceptance application being shut down before account data could be securely deleted," the document says. "Most mobile devices do not come with a secure subsystem (e.g., secure element) that could be used to isolate and store account data. Therefore, depending on the permissions of the application, any application can access any memory location on the mobile device."
Like all elements of security strategy, retailers have to realistically calculate the effort-to-benefit-ratio on mobile protections. What types of attacks are likely, and which are not worth paying to protect against? The guidelines offer one example of something that, at least today, is not worth defending against.
"In order to bypass security mechanisms such as a secure element or various biometric mechanisms, a person or organization might require very expensive and technologically advanced equipment," the guidelines say. "Today, attacks on security mechanisms like these are too difficult and not financially beneficial for the development of extensive countermeasures. However, in the future, this may not be the case and protecting against such attacks may become a higher priority."
Several potential mobile weaknesses were specifically flagged as worthy of extra attention:
"Should not implement (packages) that permit PIN entry directly into the mobile device. If the system incorporates PIN-entry capability, it should only occur through a PTS approved PIN Entry Device or EPP (Encrypting PIN Pad)."
"Should not use the mobile payment (package) to authorize transactions offline or store transactions for later transmission, for example, when the mobile payment application on the host is not accessible."
"Data captured by an embedded camera may prove to be an exploitable weakness."
"Even with USB debugging disabled, other ways exist in which sensitive data can be accessed on a mobile device. Depending on the device, sensitive data may be accessible through the UART port, audio ports (e.g., headset connection and/or microphone), HDMI ports, IR ports, hardware test points (e.g., JTAG), or through various (non-native) phone states accessed by key sequences or combinations."
"When a mobile device is in a non-native state like emergency recovery mode, it can often be backed up, re-flashed, or have its memory wiped. These actions can usually be performed from the user interface or an external device (e.g., a side-loaded ROM or executable from an SD card)."
"Mobile devices come with resets from the chipset manufacturer, device manufacturer, and the carrier. These resets can be referred to as public or private resets. Public resets are generally available to the user and can be accessed through the device's user interface. Private resets are generally not available to the user and require a key sequence, a passcode, or the device to be in a non-native state. Both public and private resets are usually not harmful to a device's security features, although many of these resets delete large amounts of data and access different memory locations. Therefore, resets could adversely affect the security and the basic functionality of the device. For instance, a harmful reset may remove the requirement for users to be authenticated to the device."
The guidelines also touch on various other suggestions, under the best practices school.
"If the reader fails, is there a manual key-entry process to accept payment card data securely?"
"This is the scenario where an employee brings a device to work that the employee (who is not the merchant) owns and controls. Since the BYOD scenario does not provide the merchant with control over the content and configuration of the device, it is not recommended as a best practice."
"The merchant should verify that the mobile device accepting account data is an authorized device by validating its hardware and electronic serial numbers. Additionally, the software, firmware, and application version numbers should be verified before account data is entered. The (vendor) should supply the merchant with documentation that explains to the merchant how to accomplish this verification."
"To help identify devices and control inventory, the merchant should mark each device with a unique identifier. For instance, mark the device with a ultra-violet (UV) security pen or an embedded RFI tag."