This is page 2 of:
PCI’s New Mobile Guidelines Acknowledge Huge Hurdles
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.”
Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code.
-Marc
