PCI Compliance - Payment Card Security Requirements

PCI SSC Technical FAQs for use with Version 6

UCP Unattended Payments is a PCI Compliance expert

A new November update to the PCI SSC Technical FAQs has been issued. It is listed below. We have also listed some other interesting questions.

For a full copy of this document, it is provided by the PCI Security Standards Council

November 2020: POI devices must support one or more of four specified techniques for the loading of private or secret keys. Methods a and b are for plaintext key loading and methods c and d are for encrypted key loading. The requirement specifies that EPPs and OEM PEDs intended for use in an unattended environment shall only support methods a, c, and d. It further specifies that SCRPs shall only support the loading of encrypted keying material. Are there any other restrictions?

A Yes. For all new evaluations (i.e., evaluations that result in a new approval) of POI v5 devices, the POI devices must support at least one of the encrypted key loading methods for the loading of private or secret keys

Requirement A9 stipulates that the device must provide a means to deter the visual observation of PIN values as they are being entered by the cardholder. What methods are acceptable?

A The POI Security Requirements provide for several options that may be used separately or in combination to provide privacy during PIN entry. These options are: ▪ A physical (privacy)shielding barrier. Note that in case the privacy shield is detachable, a user’s guide must accompany the device that states that the privacy shield must be used to comply with ISO 9564. Optionally, the user’s guide can also reference PCI device requirements; ▪ Designed so that the cardholder can shield it with his/her body to protect against observation of the PIN during PIN entry, e.g., a handheld device; ▪ Limited viewing angle (for example, a polarizing filter or recessed PIN pad); ▪ Housing that is part of the ATM or kiosk, cardholder’s hand or body (applies to handheld devices only); and ▪ The installed device’s environment.

May (update) 2018: PIN entry devices may physically integrate in the same device other functionality, such as mobile phone, PDA capabilities or POS terminal. Handheld configurations of PIN entry devices may accommodate the attachment (e.g., via a sled, sleeve or audio jack) of a mobile phone, PDA or POS terminal, where the attached device communicates with the PED. Such a configuration appears as a single device, with separate interfaces for input by the clerk and cardholder. What considerations must be taken into account for either of these configurations?

A For any device where the cardholder is expected to use the same interface for PIN entry as the clerk would use for phone, PDA, payment application, etc. purposes, or where there are multiple interfaces in a single integrated device, the integrated device must be physically and logically hardened in accordance with the PTS POI security requirements. In a handheld configuration with an attached device, there is a risk that the cardholder enters the PIN on the wrong interface. Furthermore, the communication interface between the PED and the attached device may give the latter access to MSR functions without cryptographic controls, allowing skimming of card account data. In this integration model, then either: ▪ Both devices are assessed and validated as compliant to the PTS POI requirements, or PCI PTS POI Evaluation FAQs – Technical – For Use with Version 6 November 2020 Copyright © 2013-2020 PCI Security Standards Council, LLC. All Rights Reserved Page 8 ▪ The PED device, which must also control the card reader(s), must implement and be validated against the PTS POI SRED module. The PED must enforce SRED functions for encryption of card data at all times. The PED is only allowed one state, and that is to encrypt all account data. It cannot be configured to enter a state where account data is not encrypted.

May (update) 2018: PIN Entry Devices that attach to a mobile phone, PDA or POS terminal via a sled, sleeve, audio jack, or wireless connection are required to support SRED. Does this apply to PEDs that are integrated with other devices (such as a tablet or mobile phone) that appear as a single device?

A Yes. An integrated device is one where two physically and electronically distinct devices (e.g., a PED and a commercial off the shelf (COTS) device such as a mobile phone) appear as a single device through the use of the plastics to mask the connectivity. In such a configuration, there is a risk that the cardholder enters the PIN on the wrong interface. Furthermore, the communication interface between the PED and the integrated device may give the latter access to card reader functions without cryptographic controls, allowing skimming of card account data. In this integration model, then either: ▪ Both the PED and non-PED are assessed and validated as compliant to the PTS POI requirements, or ▪ The PED, which must also control the card reader(s), must implement and be validated against the PTS POI SRED module and be both physically and electronically distinct from the non-PED system (for example, it is not acceptable to have the PED firmware execute within the same processor as the non-PED firmware). The PED must enforce SRED functions for encryption of card data at all times. The PED is only allowed one state, and that is to encrypt all account data. It cannot be configured to enter a state where account data is not encrypted. The Security Policy must also state that the non-PED has not been assessed under the PCI PTS program and security guidance is required to ensure the secure operation of the solution. An additional note will be added to the portal noting that the non-PED has not been assessed under the PTS program.

October 2018: Are there minimum requirements for the version of Android to be used within a PTS device?

A Yes, it is expected that the Android version is officially supported with security patches, at a minimum. Any reports, including deltas, where the Android version is not supported with regular security patches will be rejected. Where these patches are not provided by Google, evidence of security patches (implemented at least monthly) provided by the vendor must be documented in the report provided by PCI; evidence for this is expected to be validation of the update code by the laboratory for at least two previous patches, as well as validation by the laboratory that these patches have remediated existing known vulnerabilities in the version of Android used. Vendors should note that this means that consideration for the future patch status of any Android version used must be made during the initial design stages of the device, to prevent unexpected rejection of devices after an Android version becomes unsupported during the development of a solution.

What vulnerabilities must be taken into account for a touchscreen?

A If the sides are accessible, an overlay attack utilizing a second, clear touchscreen could be a problem. The connection/path from the touchscreen to the processor (and any devices used for decoding the signals in between) needs to be verified to be secure. Bezels around the touchscreen are especially dangerous because they can conceal access to areas of concern that are described above. The API for firmware and applications (if applicable) needs to be looked at carefully to determine the conditions under which plain-text data entry is allowed. Example: It should not be possible unless under acquirer display prompt-controlled devices, for a third party to display an image (JPEG) that states “press enter when ready for PIN entry” and then have a plain-text keypad pop up on the next screen. The extra caution is warranted for touchscreen devices because of the desire to make touchscreen devices user-friendly and to run many different, unauthenticated, uncontrolled applications. This is especially true for the devices that are intended to be held because of the tendency to regard them as a PDA that can perform debit transactions.

February (update) 2014: Does the use of protective keypad overlays impact the approval status of a device?

A Yes. In general, overlays are not supported by the device approval program due to the potential for keypad tapping or hiding tamper evidence. Overlays may be used where they do not cover any portion of the PIN entry area. For example, in a touchscreen device where the touchscreen is used for both signature capture and PIN entry, an overlay may be used to protect the signature area from excessive wear. In this example only the area used for signature capture may be protected. The material used must be transparent, and not merely translucent, so as not to obstruct the key-entry area when viewed from any angle

Some devices ship with firmware that may be convertible into a compliant version but is not compliant as shipped. When is this acceptable?

A This is only acceptable where the conversion is one way and cannot be reversed. A device can only be converted to a compliant version. It shall not be capable of converting a compliant version to a non-compliant version. The conversion must be performed at the initial key loading of the acquiring entity’s secret keys. The transformation must result in the zeroization of any previously existing acquiring entity secret keys. The compliant version of firmware must be clearly distinguishable from the non-compliant version. Merely appending a suffix (one or more characters) to an existing firmware version is not acceptable. Rather the conversion must result in a high order version number that is clearly distinguishable to purchasers of such devices. Only the compliant version shall be approved and listed.

January 2015: There are a number of FAQs on the use of wireless technologies, such as Bluetooth and Wi-Fi. What is the intent of these FAQs, and does PCI have any specific requirements for other types of communications technologies?

A The intent of the FAQs on all wireless communications for POI devices is to ensure that the interfaces of the POI are protected such that: ▪ Card data cannot be easily intercepted. ▪ Command interfaces to the terminal cannot be easily accessed, intercepted for attack (such as MITM), or used as an attack vector into the device. ▪ Compromise of the interface does not lead to, support, or facilitate further compromise of security assets of the POI. PCI does not mandate or require the use of any specific communication technology, but any implementation must meet the above requirements through some aspect of the physical or logical layers of communication. Physical or direct wired communication often achieves this through the nature of its physical interface. Wireless communications cannot rely on this and therefore must rely instead on security at the link or application layers through use of a Security Protocol to establish a trusted path for all communications over the wireless link. This Security Protocol must have been tested and approved under the open-protocols module of the PCI PTS evaluation of that device, and examples of acceptable Security Protocol implementations include WPA2 (implemented at the link layer), or VPN encrypted tunnels (implemented at the application layer)

December (update) 2016: Can a PTS device be used as a beacon (iBeacon or BLE beacon) transmitter?

A Beacons for any version of BLE (e.g., 4.0, 4.1) are allowed providing the following conditions exists and are validated by a PTS approved lab: ▪ The beacon is listed as a device interface in the PTS POI report. ▪ Over the Air (OTA) provisioning is not allowed at any time. Provisioning and updating of beacons must be consistent with existing PTS standards. (i.e., Section J, B4 or B4.1) ▪ Must be referenced in the security policy. ▪ Beacons are transmit-only. The lab must validate that BLE communication cannot be used to respond to any external requests, connect, pair, or otherwise provide two-way communication to any other device. ▪ The vendor provides documentation on the secure use and provisioning of the beacon and that the documentation clearly states the beacon is used for transmit only, and that OTA provisioning is not allowed. ▪ The vendor will document the purpose of use of the beacon functionality⎯i.e., its intended use. The documentation must include what data is transmitted and ensure that no sensitive data can be transmitted. ▪ The PTS device is never allowed to receive beacon transmissions.

Additional Links

Relevant PCI Compliance Member Links

PostCounter: 118