Document Diff - PCI Watch

Added p. 6

A Yes. This would invalidate the approval status of the device for any implementation making such changes. Any such change must result in the device successfully undergoing a delta evaluation in order to maintain approval.

• Card data cannot be easily intercepted.

• 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 …

Added p. 8

June 2012: The approval requirements for an SCR or Non-PIN device do not include PCI PTS DTR A1, which requires active tamper-response mechanisms. Is it possible to meet the physical security requirements of an SCR or Non-PIN device using only tamper resistance and tamper evident characteristics, if the attack costing can be shown to exceed the minimum levels required for each of the physical security testing requirements? A No. It is a requirement that all devices implement active tamper detection mechanisms to meet the physical security requirements of PCI PTS. SCR and Non-PIN devices must have permanently active tamper detection mechanisms that monitor for intrusion and respond to such events with the immediate erasure of sensitive information within the device, rendering the device inoperative.

A device cannot meet PTS POI requirements without having an active tamper response mechanism to zeroize secret and private keys during a penetration attack regardless of which …

Added p. 11

July 2017: For purposes of PCI acceptance, a draft standard is a document that either has been published as a draft for trial use⎯e.g., ISO FDIS⎯or has been published as a draft for public comment⎯e.g., NIST drafts.

Added p. 12

October 2018: DTRs state, “Evidence-based reporting, demonstrating device compliance through robust testing, is the fundamental basis for achieving device approval.” What are the minimum expectations for testing/test evidence for any device resistance to attacks involving physical penetration/modification? A Although evidence of cutting and/or drilling into the device (exterior case, interior parts) is a primary test activity in most evaluations, cutting and/or drilling alone is rarely sufficient to demonstrate satisfactory resistance to all/any Security Requirements where a viable attack path has elements of physical penetration/modification. It is necessary for the evaluating lab to show, additionally, robust evidence of the device’s resistance to physical attacks attempting to circumvent, for example (but not restricted to), tamper switches, meshes, PCBs, tamper circuits, keyboards, screens, card readers, boards, etc., and these device parts’ components and/or components connecting these.

March 2021: POI v6 firmware expires on 31 December every third year subsequent to the year initially approved. …

Added p. 21

September 2013: Can a device be validated to SRED if it receives account data that is entered on a non-integrated module or device•for example, where a device receives account data that is key-entered on another device? A The external module or device where the account data is captured can receive SRED approval if evaluated in conjunction with the POI device. The SRED approval would be contingent on both devices meeting all applicable SRED requirements, including the protection of cryptographic keys. Account data (as defined in the glossary of the PCI PTS POI Security Requirements) traversing the communication path from the external point of capture must be encrypted in accordance with these requirements. Both devices would be part of the approval listing, and the substitution of the external device with another that is not validated to SRED invalidates the approval of SRED as a function provided.

November 2012: Where a whitelist is …

Added p. 24

• If both firmware versions fail authentication, the device fails in a secure manner.

B22 states it is for remote access only and does not include a manual element, a security protocol would be required to ensure the interface cannot be exploited.

September 2023: DTR B2.1-Application Authenticity, states that application authentication must be performed within the secure firmware of the POI. On split processor designs where an open OS (e.g., Android) is running on the Application Processor (AP), can the AP run Google Play store or equivalent? A PCI PTS requires all executable code and configuration updates (such as software and scripts) to be authenticated in accordance with DTR B2, using cryptographic keys managed under requirement B9. Any mechanisms which can be used for loading script or software must be validated to these requirements, preventing the distribution of applications not directly signed by Vendor supplied methods validated to DTR B2.2, including applications …

Added p. 27

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. POI devices must support at least one of the encrypted key loading methods for the loading of private or secret keys.

November (update) 2022: ANSI X9.143 defines three keys. A key-block protection key (KBPK), a key-block encryption key (KBEK) and a key-block MAC key (KBMK). The KBPK is used to calculate the KBEK and the KBMK. Can the KBPK be used for any other purpose? A No. …

Added p. 30

November (update) 2022: In support of the conversion of deployed devices to the use of ANSI X9.143, can a key previously loaded for another purpose, such as a KEK, be re- statused as a ANSI X9.143 Key Block Protection Key? A No. Loading of a key into a slot (register) must set the slot to its given function. If the slot’s function is changed, or if a new clear-text key is loaded into the slot without authentication using dual control, all other keys in the device (or at least all keys that were previously protected under the key that was previously in the slot) must be erased. This mechanism helps ensure that a device cannot be maliciously taken over.

November (update) 2022: ANSI X9.143 or equivalent support is required as an option for any device that allows the loading of symmetric keys that are encrypted by another symmetric key as a …

Added p. 31

November (update) 2022: When a device is converted to or otherwise implements ANSI X9.143, the conversion must be one way. On a device supporting multiple independent key hierarchies, such as one designed to support multiple acquirers, does the implementation apply to all key hierarchies on the device? A No. A device supporting multiple independent hierarchies may implement ANSI X9.143 (or equivalent) on a hierarchy-by-hierarchy basis.

Added p. 34

a) A key version number that prevents the use of older or expired keys.

b) Support for key “direction” (uni-directional keys) so that a MAC key may be identified as “verify only,” or a data key as “encrypt only.”

c) Support for key purposes other than PIN, MAC, and Data.

d) Support for both TDES and AES (where devices implementing the key blocks only support one of these algorithms⎯transitional only⎯new devices must support AES).

f) Support for asymmetric algorithms.

Added p. 35

• The Key Block Binding Method.

December 2022: For Key Blocks, is the same MAC key allowed to be used across different MAC algorithms, or is a key unique to each algorithm implemented required? A A key unique to each implemented MAC algorithm must be used as specified in ANSI X9.143.

July 2023: Key blocks must prevent the determination of key length for variable length keys using random key length obfuscation padding. Does the POI need to check the length of the binary key data after receiving the key block and reject the block in the case of a padding error? A Yes. To prevent the determination of key length for variable length symmetric keys, the POI must check the length of the binary key data and reject the block whose length does not meet key length obfuscation padding to the maximum length for the algorithm, 192 bits for TDEA and 256 …

Added p. 39

POI Requirement B18 What are acceptable methods of meeting this requirement? A The use of accepted key-management techniques will typically satisfy this requirement:

However, when the device is intended to support multiple acquirers and the acquirer is selected by a user⎯i.e., merchant pressing a button⎯the device must verify that the correct acquirer has been chosen.

Is it acceptable for a device that supports multiple key hierarchies to meet B18 by ensuring that specific applications can only access keys that are associated with them? A Yes. It is acceptable provided each application can only access a single key-hierarchy’s keys.

Is it acceptable for PIN keys to be externally selected indirectly by selecting the acquirer if the acquirer selection is performed with a cryptographically authenticated command? It is assumed that there are multiple key hierarchies related to PIN encryption under each acquirer.

• Key hierarchies for PIN encryption are only established directly by the vendor at …

Added p. 41

August 2022: Vendors can have various options for both hardware and firmware that may be either security or non-security relevant. For non-security relevant options, vendors are allowed to designate in their hardware/firmware identifiers a lower case “x” in the relevant position. Security relevant options must have specific numbers and/or letters assigned and listed as part of the approval. The program guide specifies that options, both security and non-security relevant must be clearly defined and documented as to the options available and their function in the device’s Security Policy. Through oversight, some Security Policies do not have this information. Does this information need to be included? A Yes. All report submittals, whether “New” or “Delta” must ensure that the device’s Security Policy required for the PCI website includes this information. This includes necessary updates to existing Security Policies.

June 2025: Security Protocols must use mutual authentication. There are several qualifications associated with …

Modified p. 1

Payment Card Industry (PCI) PTS POI Security Requirements Technical FAQs for use with Version 5

Payment Card Industry (PCI) PTS POI Security Requirements Technical FAQs for use with Version 6

Removed p. 4

Q 1 The security requirements now use a modular approach based on device functionality instead of specific form factors (e.g., EPPs, PEDs, etc.). How do I determine which requirements are applicable to my product? A The PCI PTS modular approach supports the submission of devices in accordance with the product types and approval classes defined in Appendix A of the PTS Device Testing and Approval Guide. In order to determine the modules and requirements within those modules that are applicable to a specific product, the vendor should:

• Review the “PTS Approval Modules Selection” diagram in the PTS POI Modular Security Requirements to determine which modules are applicable

• Go to “Appendix B: Applicability of Requirements” of the PTS POI Modular Security Requirements. Based upon the functionalities provided by the target of evaluation, determine what requirements within each applicable module apply.

Q 3 September (update) 2015: When is an “N/A” response to a …

Modified p. 4 → 3

~~Q 2~~ If a device application includes prompts for non-PIN data and the device enforces PCI Requirement ~~B16~~ compliant controls, can it be listed as an ~~acquirer controlled~~ prompts device with the application excluded from the device identifiers? A Yes, if an application cannot impact any of the functionality needed to comply with PCI requirements. Code within the device that does not provide and cannot impact ~~security,~~ need not be represented by the identifiers of the approved device.

General Questions If a device application includes prompts for non-PIN data and the device enforces PCI Requirement B15 compliant controls, can it be listed as an acquirer-controlled prompts device with the application excluded from the device identifiers? A Yes, if an application cannot impact any of the functionality needed to comply with PCI requirements. Code within the device that does not provide and cannot impact security need not be represented by the identifiers of the approved device.

Removed p. 5

Q 6 What type of epoxy is acceptable for encapsulation? A Acceptable epoxy will possess the following characteristics:

• Opaqueness: Epoxy must be opaque in the visible spectrum.

• Hardness: Epoxy must be hard enough so that a sharp object cannot be used to penetrate the epoxy to the depth of the underlying circuitry.

• Tamper Evidence: The epoxy must show visible evidence of tamper when an attempt to penetrate the epoxy with a sharp object is made.

• Adhesion: Epoxy must resist attempts to forcibly separate it from the circuit board. When enough force is applied to remove the epoxy, severe damage should result such that the device is non-functional.

Q 9 What is a “Delta” Revisions to approved devices are termed “deltas.” Delta reviews involve the laboratory assessing the changes based on the current major version (e.g., 1.x, 2.x, 3.x etc.) of the requirements that were used for the approval of the device. …

Modified p. 5 → 3

~~Q 7~~ Is it assumed that the surface of the potted area is visible without disassembly of the device? A No. The potted, security sensitive components of the device are within the device enclosure and are ~~therefore,~~ unlikely to be visible without opening the enclosure.

Is it assumed that the surface of the potted area is visible without disassembly of the device? A No. The potted, security sensitive components of the device are within the device enclosure and are therefore unlikely to be visible without opening the enclosure.

Modified p. 5 → 3

~~Q 8~~ Is it acceptable for a device to include removable components and add-ons provided by the vendor? A Any removable components (privacy shields, docking stations, interface modules, etc.) must be evaluated by an approved laboratory to determine that they do not present any additional security risk. However, individual components will not receive a separate approval.

Is it acceptable for a device to include removable components and add-ons provided by the vendor? A Any removable components (privacy shields, docking stations, interface modules, etc.) must be evaluated by an approved laboratory to determine that they do not present any additional security risk. However, individual components will not receive a separate approval.

Removed p. 6

Q 10 July (update) 2014: Does the device have to show the version numbers of the hardware, firmware and Application? A The device must show the version numbers of hardware and firmware like they have been approved and they are shown in the list of approved devices. The hardware number must be shown on a label attached to the device. The firmware and application version numbers, and optionally the hardware version number, must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open Protocols. If the hardware version label is not visible when the device is installed, such as on an EPP in an ATM, then other means must exist to display the version number. This shall be illustrated by photographic evidence provided in the evaluation report.

Q 12 Is it acceptable to make changes to an approved …

Modified p. 6 → 3

~~Q 11~~ 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 ~~whereby~~ the touchscreen is used for both signature capture and PIN entry, an overlay may …

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 …

Modified p. 6 → 4

~~Q 13~~ May (update) 2018: Does the entry of the authentication ~~code (e.g., password) that~~ is used for settlement/balancing at an ATM require the use of the secure EPP, or may it use an alternate mechanism such as the keyboard at the back of the ATM? A The entry of the authentication code used for settlement/balancing at the ATM does not need to be entered through the EPP, ~~but~~ may use the keyboard installed in the rear of the ATM. …

May (update) 2018: Does the entry of the authentication code⎯e.g., password⎯that is used for settlement/balancing at an ATM require the use of the secure EPP, or may it use an alternate mechanism such as the keyboard at the back of the ATM? A The entry of the authentication code used for settlement/balancing at the ATM does not need to be entered through the EPP, and may use the keyboard installed in the rear of the ATM. However, in all cases …

Removed p. 7

Q 15 February (update) 2014: When submitting hardware and/or firmware changes on existing approved devices, must a vendor submit the device to the same lab as the one that did the initial evaluation? A Vendors may select a different lab then the lab that was used to perform the initial evaluation. However, the subsequent lab is free to determine the level of reliance they wish to place upon the prior lab’s work, which may result in additional work than would otherwise be necessary. For Version 3 or higher reports, the delta lab or the final form factor lab shall have access to the prior lab’s report(s), including any delta or OEM component reports subsequent to the original evaluation. If those reports are not available, the delta lab or final form factor lab shall decline the engagement or else must complete a full evaluation of the device.

Q 16 The DTRs indicate …

Modified p. 7 → 4

~~Q 14~~ 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. …

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 …

Removed p. 8

Q 19 Are PC-based instruments like protocol sniffers, USB attached oscilloscope adapters and graphical multimeters, etc. considered standard or specialized equipment. A PC-based instrument like those mentioned above shall be considered standard equipment, especially if they do not require dedicated hardware or adapters.

Q 20 Some attacks are technically simple in that they do not require an extensive identification, like sniffing a communication on standard interfaces like USB/Ethernet between devices. How is the attack value calculation to be performed then? A For technically simple attacks that do not require an extensive identification, like sniffing a communication on standard interfaces like USB/Ethernet between devices, all cost factors besides time and expertise should be disregarded. Also, attack time and expertise is to be considered only for the identification of the general device setup and the property to be attacked (e.g., the interface type).

Q 21 If a device is submitted for evaluation of offline …

Modified p. 11 → 5

Changes that occur in the final form factor ~~itself (e.g.,~~ the ~~housing) because~~ of the complexity of integration must undergo testing as a new evaluation against a version of requirements that has not been retired from use for new evaluations.

Changes that occur in the final form factor itself⎯e.g., the housing⎯because of the complexity of integration must undergo testing as a new evaluation against a version of requirements that has not been retired from use for new evaluations.

Modified p. 11 → 5

~~Q 30~~ Does it make any difference if the OEM component vendor is also the vendor who gets the overall UPT approval, vs. a scenario where the OEM vendor sells its components/drop in module to other vendors such as kiosk or AFD vendors who then pursue an overall UPT approval? A No. The OEM components can be manufactured by any vendor, even if that vendor is different than the UPT vendor. However, if the vendors are different, those components must …

Does it make any difference if the OEM component vendor is also the vendor who gets the overall UPT approval, vs. a scenario where the OEM vendor sells its components/drop in module to other vendors such as kiosk or AFD vendors who then pursue an overall UPT approval? A No. The OEM components can be manufactured by any vendor, even if that vendor is different than the UPT vendor. However, if the vendors are different, those components must have already …

Removed p. 12

Q 32 July (update) 2014: The program manual stipulates that "Vendors or other third parties licensing approved products from other vendors to market or distribute under their own names are not required to pay a new evaluation fee if the only change is to the name plate. If firmware and/or hardware changes are made that require a PCI-recognized test laboratory to evaluate the changes for potential security impact, then the licensee shall be required to pay the new evaluation fee. In all cases the licensed device will receive a new approval number and the licensee vendor or third party shall be billed the annual listing fee for each such approval." What are additional considerations for a third party to license an approved product from a vendor, whereby the third party wants to distribute it as their own product? A There are several additional considerations:

1. The licensee vendor cannot directly make …

Modified p. 13 → 10

a) Both devices are assessed and validated as compliant to the PTS POI requirements, or

• Both devices are assessed and validated as compliant to the PTS POI requirements, or

Modified p. 13 → 10

b) 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.

• 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.

Removed p. 14

Q 36 July 2011: Hashing algorithms are an integral part of digital signatures. Digital signatures are frequently used in connection with meeting a number of security requirements, including those related to firmware updates, display prompt control, and remote key distribution. With the release of PCI PTS POI v3, SHA-1 was explicitly prohibited for use, and only SHA-2 was allowed. Does this prohibition apply only to the signatures of the data that is being updated and to only the device’s specific individual certificates, or to all certificates used by the device? A Hashing algorithms must possess two properties in order to be considered secure. First, they must be one way such that it is easy to compute the hash value, but given the hash value, it is infeasible to reproduce the original unhashed value. Second, they must be collision-free, i.e., it is not possible to find two different messages (sets of …

Removed p. 15

Q 37 October (update) 2018: Are Bluetooth/Wi-Fi interfaces part of the evaluation? A Bluetooth and/or Wi-Fi, like any other open security protocol declared in the POI Protocol Declaration form, must be assessed by the laboratory.

If a Bluetooth interface is used, the Bluetooth interface must enforce encryption. This encryption is in addition to any other encryption the data may have undergone. If PIN or passkey entry is to be used, the evaluator must validate that vendor default values can be changed. The device must not support or allow for the use of insecure communication options such as, but not limited to, security modes 1 & 2 and the “Just Works” secure pairing option of security mode 4.

For Bluetooth 4.1 or higher devices that have BR, EDR, and High Speed (HS) features, Security Mode 4, Level 4 must be used. This requires Secure Connections, which uses authenticated pairing and encryption using 128-bit …

Removed p. 16

Q 40 June 2012: During an evaluation, it is determined that a new device includes the identical IP stack that was previously evaluated and approved under the most recent version of the Open Protocols Requirements module. Is it required to redo all Open Protocols testing? A If the vendor is able to provide evidence that supports the assertion that the IP stack is 100% identical, including the same version of various components and identical IP Protocols, IP Services and IP Security Protocols, no new testing needs to be performed. The report should document how it was verified that the IP stack is identical and shall include the IP stack information including the component version, the IP Protocols, IP Services and IP Security Protocols supported.

Q 41 June 2012: The approval requirements for an SCR or Non-PIN device do not include PCI PTS DTR A1, which requires active tamper-response mechanisms. Is it …

Removed p. 17

Q 43 January (update) 2015: This FAQ has been superseded.

Q 44 September 2012: In the approval listing, the vendor must provide via the evaluation lab pictures detailing all security relevant components (PIN pad, display, card reader(s)) of the approved device. These pictures are then placed on the PCI website as part of the approval listing. Are there any other stipulations? A Yes, at least one of the pictures must fulfill the requirement that the hardware version number must be shown on a label attached to the device. Note that for devices with multiple approved hardware versions, only one such illustration is necessary to facilitate purchasers of these devices recognizing how to determine the approved version(s).

Q 45 November 2012: What are the algorithms and associated minimum key lengths that are acceptable for use with the default operation of any open protocol used in a POI? A The minimum requirements for cryptographic …

Removed p. 18

Q 49 July (update) 2015: The PCI POI Testing and Approval Program Guide specifies that the PCI test laboratory is to provide to MasterCard on behalf of the Council two devices containing the same firmware, any supporting PC based test applications, and any keying material as those evaluated by the test laboratory. Under what conditions are these devices to be provided? A This applies to all new evaluations that result in a new approval number. It does not apply to deltas. It also does not apply to a situation where the vendor is merely rebranding another vendor's previously approved product. However, if a vendor is rebranding a product, and additionally makes other changes, such as in the firmware, it does apply. In conjunction with the transmittal of the evaluation report to the Council, these two devices must be sent to the following location, where they will be placed into secure …

Removed p. 19

Q 53 December 2013: Beginning with POI v3, SHA-1 is prohibited for use in conjunction with digital signatures. Is SHA-1 prohibited for other usages? A SHA-2 or higher is recommended for other usages, but SHA-1 may be used in conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key derivation functions (i.e., KDFs) and random number generation. Where applicable, appropriate key length minimums as delineated in the Derived Test Requirements are also required.

Q 54 December 2013: The PCI PTS requirements do not dictate any specific form factor for devices. Is there any restriction to the types of systems or devices which can be approved under the PCI PTS program? A PCI PTS does not dictate device form factors to allow for vendors to develop innovative solutions to address market needs. However, PTS approval can only be obtained by devices that are designed for …

Removed p. 20

Q 58 February 2014: If an existing approved device undergoes a hardware change that does not impact any of the internal components but impacts the appearance of the device, i.e., the only change is to the exterior of the device, can that change be treated as a delta? A Yes, such changes in casing plastics that result in a change in the device’s look and feel is a permitted hardware type change under the delta guidance provided the amended device remains consistent to the device’s original form factor. The change must result in a new hardware version number and a change in the model identifier.

Q 59 February 2014: Can an approved product change the entire operating system and the change is treated as a delta e.g., from a proprietary system to a Linux based system? A In general, any change in firmware is permitted as a delta. However, completely changing …

Removed p. 21

Q 64 July 2014: POI devices may be approved with support for Open Protocols. Vendors provide a PCI prescribed security policy and other security guidance for the proper implementation of the Open Protocols that are part of the approval. If the entity deploying the device makes changes that are not in accordance with the security guidance necessary to deploy the device in compliance to the Open Protocols module, does it impact the approval? For example: adding additional services or protocols that were not listed in the guidance or using or otherwise replacing the IP stack with one imbedded in the application. A Yes, this would invalidate the approval status of the device for any implementation making such changes. Any such change must result in the device successfully undergoing a delta evaluation in order to maintain approval. The Open Protocols module is to ensure that open protocols and services in POI …

Removed p. 22

Q 67 October (update) 2018: Can Low Power Bluetooth, also known as Bluetooth Light, Bluetooth Smart or Bluetooth Low Energy (BLE) be used? A BLE implementations must use version 4.2 or higher. BLE must use LE Security Mode 1 Level 4 (Secure Connections) only and Just Works cannot be used at any time. The device must not support or allow for the use of insecure communication options such as, but not limited to, LE Security Mode 2, and levels 1, 2 and 3 of LE Security Mode 1 and the “Just Works” secure pairing option of Security Mode 1. This must be documented in the security policy made available on the PCI website. BLE implementations in SCRPs, regardless of Bluetooth version, for use in SPoC Solutions may use unauthenticated pairing (Just Works) provided compensating controls to mitigate against eavesdropping and MITM attacks are in place as part of the Solution. …

Removed p. 23

Q 69 October (update) 2018: In light of the discovery of the Padding Oracle on Downgraded Legacy Encryption (POODLE) attack, is SSL still an allowed protocol. A SSL may continue to be supported, but the vendor must document (for version 4 and higher devices this includes the Security Policy published on the PCI website) that it is inherently weak and should be removed unless required on an interim basis to facilitate interoperability as part of a migration plan. For SSL 3, or older versions of TLS, if supported, all cipher suites using single DES or RC4 must be removed. Both of these objectives may be achieved by modifying the source code to remove support for SSL and non-allowed cipher suites and/or by modifications to the configuration file. In either case, the version information of the code, including where applicable the modified configuration file, shall be identifiable as part of the …

Modified p. 23 → 10

~~Q 70~~ July 2015: Handheld PEDs that attach to a mobile phone, PDA or POS terminal via a sled, sleeve or audio jack are required to support SRED. Does this apply to PEDs that connect via wireless technologies such as Bluetooth or Wi-Fi to mobile phones and tablets? A Yes. Furthermore, for devices that do not implement SRED encryption, the Security Policy must clearly state that the system cannot be implemented to connect to a tablet or mobile phone, and …

July 2015: Handheld PEDs that attach to a mobile phone, PDA or POS terminal via a sled, sleeve or audio jack are required to support SRED. Does this apply to PEDs that connect via wireless technologies such as Bluetooth or Wi-Fi to mobile phones and tablets? A Yes. Furthermore, for devices that do not implement SRED encryption, the Security Policy must clearly state that the system cannot be implemented to connect to a tablet or mobile phone, and any such …

Removed p. 24

Q 74 October 2015: Does the installation, for example in seatbacks, of POI PIN acceptance devices in mass transit vehicles such as airplanes and trains require that these devices contain an anti-removal mechanism to protect against unauthorized removal and/or unauthorized re-installation? A No. Installations in mass transit vehicles constitutes a semi-attended environment and as such, removal detection is not required. A semi-attended environment is one where a transaction is completed under all of the following conditions:

• Card or Proximity Payment Device is present;

• Cardholder is present;

• Cardholder completes the Transaction and, if required, an individual representing the Merchant or Acquirer assists the Cardholder to complete the Transaction If the device does not meet the removal detection requirement, the security policy must stipulate its usage is restricted to attended environments, or to semi-attended environments as defined above. It must also state that any other usage invalidates the approval.

Q 75 May (update) …

Modified p. 25 → 11

• 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 …

Removed p. 26

Q 78 May (update) 2018: Is there a limit to the level of damage to a POI that may be ‘covered up’ without casing replacement? A No. It is easy to either cut out a suitable part from a mechanical sample (obtained during identification) or 3D print a part for the replacement area. Paint or stickers can easily hide any seams or damage as it is common in the marketplace for deployed POIs to have painted plastic casings or stickers of some type. Therefore ‘pure’ casing damage, including full case replacement, will receive 1 point for a standard part in the exploitation phase.

Q 79 July 2017: Should damage to the front or back be treated differently, given increased visibility of frontal damage? A No, unless the rear can be expected to not be visible (e.g., in an EPP) where any damage does not need to be covered up at all. …

Modified p. 26 → 11

Q 81 July 2017: For purposes of PCI acceptance, a draft standard is a document that either has been published as a draft for trial use (e.g., ISO FDIS) or has been published as a draft for public comment (e.g., NIST drafts). A However, ANSI (X9) does neither of ~~these~~ and further clarification must be made. For purposes of PCI acceptance, an ANSI (X9) draft standard is one that has been successfully balloted out of the assigned X9 working ~~group …~~

A However, ANSI (X9) does neither of these; and further clarification must be made. For purposes of PCI acceptance, an ANSI (X9) draft standard is one that has been successfully balloted out of the assigned X9 working group⎯e.g., X9F1, X9F4, or X9F6. Prior to this point, working group procedures allow members to post documents in various stages of “draft” which may conflict with each other and may not reflect a consensus of the working group. A breach of the algorithm …

Removed p. 27

Q 83 December 2017: Are laboratories allowed to do PTS HSM and POI work at a vendor site? A The purpose of the laboratory assessment is to provide an independent review and testing of PTS devices using approved laboratory personnel and equipment. Device testing for PTS approvals shall be done in the PCI recognized laboratory facility and not at vendor site unless:

• The laboratory work is in connection with evaluating policies and procedures of the vendor.

• Evaluating Module 5 Manufacturing requirements.

• Evaluating Module 5 Manufacturer and Facility of Initial Key Loading or Facility of Initial Deployment requirements.

• Where necessary, to review source code.

Any work completed outside the PCI recognized laboratory facility should be clearly documented in the PCI PTS device evaluation report.

Q 84 December 2017: Attacks may require spare parts, e.g. plastic housings, which can be obtained from a mechanical sample of the same device. How should these spare parts …

Modified p. 27 → 11

~~Q 86~~ May 2018: Is it acceptable for a terminal application to parse input data, which dynamically changes its execution ~~behaviour~~ at runtime? E.g., can a web browser or ~~email~~ client parse and display HTML5, Java, ~~Javascript~~ or any other scripting language? A ~~Yes~~ as long as the data is being parsed, verified and displayed by the firmware.

May 2018: Is it acceptable for a terminal application to parse input data, which dynamically changes its execution behavior at runtime? E.g., can a web browser or e- mail client parse and display HTML5, Java, JavaScript or any other scripting language? A Yes, as long as the data is being parsed, verified and displayed by the firmware.

Removed p. 28

Q 87 May 2018: Is authenticity checking provided by TLS sufficient to meet B16? A No. TLS is only designed to offer IP security, it does not provide security or integrity of the message interpretive content or context. I.e., it does not prevent message content code (such as HTML5, Java, Javascript, etc.) from requesting an input prompt. Vendor or acquirer certified applications and/or data that are communicated using a managed PKI (in addition to TLS) are acceptable. However, the application and/or data provider must attest that the application and/or data does not contain instructions to make use of a prompt.

Q 89 October 2018: DTRs state ‘Evidence-based reporting, demonstrating device compliance through robust testing, is the fundamental basis for achieving device approval.’ What are the minimum expectations for testing / test evidence for any device resistance to attacks involving physical penetration / modification? A Although evidence of cutting and/or drilling into …

Modified p. 28 → 12

~~Q 88~~ 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 …

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 …

Removed p. 29

Q 1 Do attack scenarios considered under A1 include replacement of the enclosure to conceal tamper evidence? A A1 allows the evaluator to use any method of attack feasible against the terminal limited only by the attack potential of 26. The POI device must be able to withstand attack from any side, including front and rear case replacement up to the attack potential value.

Q 2 Attack scenarios should consider keypad removal or replacement associated with unattended payment terminals, such as in connection with overlay attacks. How can this be addressed by the device’s design? A Since in vending machines or other unattended acceptance/payment terminals only the keypad area of a device is usually visible to the cardholder, attacks may be mounted which use device removal and the insertion of keypad overlays or keypad substitutes as an attack element. These attacks may be easier to perform than direct attacks to the …

Modified p. 29 → 13

~~Q 91~~ April 2021: PTS vendors are required to make all source code pertinent to Security Requirements available to the test laboratories. Multiple test requirements require the test laboratories to review that code to facilitate validation to the applicable Security Requirements. Should those code segments (snippets) be included in the reports? A ~~Yes, unless~~ stated in the test requirement that the sample is not required, the segment or snippet is considered evidence of meeting the security requirement. Code samples serve …

April 2021: PTS vendors are required to make all source code pertinent to Security Requirements available to the test laboratories. Multiple test requirements require the test laboratories to review that code to facilitate validation to the applicable Security Requirements. Should those code segments (snippets) be included in the reports? A Yes. Unless stated in the test requirement that the sample is not required, the segment or snippet is considered evidence of meeting the security requirement. Code samples serve as evidence …

Removed p. 30

Q 5 What vulnerabilities must be taken into account for a touch screen? A If the sides are accessible, an overlay attack utilizing a second, clear touch screen could be a problem. The connection/path from the touch screen to the processor (and any devices used for decoding the signals in between) needs to be verified to be secure. Bezels around the touch screen 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 …

Modified p. 30 → 15

~~Q 7~~ In the event of tamper, the device must become immediately inoperable and result in the automatic and immediate erasure of any secret information that may be stored in the device, such that it becomes infeasible to recover the secret information. Guidance notes provide that secret or private keys do not need to be zeroized if either or both of the following conditions exist: ~~• If any of these keys are not zeroized, then other mechanisms must exist to …~~

POI Requirement A1 In the event of tamper, the device must become immediately inoperable and result in the automatic and immediate erasure of any secret information that may be stored in the device, such that it becomes infeasible to recover the secret information. Guidance notes provide that secret or private keys do not need to be zeroized if either or both of the following conditions exist:

Modified p. 30 → 15

• The keys are never used to encrypt or decrypt ~~data,~~ or are not used for authentication.

• The keys are never used to encrypt or decrypt data or are not used for authentication.

Removed p. 31

Q 9 March 2011: When calculating the Identification phase for PIN-bug attacks, when should Restricted or Sensitive Information be used? A In many cases, additional time spent analyzing the device under attack can be used in lieu of Restricted or Sensitive information. Restricted or Sensitive information should only be used when the total attack-potential calculation using Restricted or Sensitive information is less than the total attack-potential calculation using the additional attack time, such as through reverse engineering.

Q 10 March 2011: Should an Expert level of expertise be used when calculating a front-case PIN- bug insertion attack on a device that includes front-case switches with guard rings as the only keypad (front-case) protection for Requirement A1? A If a device includes front-case switches with guard rings as the only keypad security mechanisms protecting the insertion of a PIN bug, then a Proficient level of expertise should be used in the exploitation …

Modified p. 31 → 15

~~Q 8~~ A device uses a key that is randomly generated internally in the secure processor to protect other keys. This key is stored in the clear and protected within a register in the same secure processor. The secure processor resides within a secure area of the device. This key is used to encrypt other keys, which are stored encrypted outside the secure processor•e.g., in flash memory that also resides within the secure area of the device. Upon tamper, the …

A device uses a key that is randomly generated internally in the secure processor to protect other keys. This key is stored in the clear and protected within a register in the same secure processor. The secure processor resides within a secure area of the device. This key is used to encrypt other keys, which are stored encrypted outside the secure processor•e.g., in flash memory that also resides within the secure area of the device. Upon tamper, the device erases …

Removed p. 32

Q 13 May (update) 2018: Requirement A1 states that a device uses tamper-detection and response mechanisms that cause it to become immediately inoperable. If the device is tampered, can it still be used to process non-PIN based payment card transactions? A A PIN-acceptance device that is tampered must immediately cease processing all PIN based payment card transactions. If implemented only one reset shall be supported unless the device is removed for inspection and repair. Any intervention enabling transactions, must require an onsite presence which validates there was NO tamper of the device and is subject to the following conditions:

Q 14 May 2018: What is considered as a ‘standard’ bug for attack costings? A Given the recent rise of cheap electronic systems which provide integrated communications and processing options, any bug that would be used for detecting binary data (such as key pressed / not pressed, or capturing data on an …

Modified p. 32 → 16

a) Use of dual-control techniques;

• Use of dual-control techniques;

Modified p. 32 → 16

b) Provide accountability and traceability including logging of user IDs, date and time stamp, and actions performed;

• Provide accountability and traceability including logging of user IDs, date and time stamp, and actions performed;

Modified p. 32 → 16

c) Sensitive information required for the ~~authorization (e.g.,~~ passwords/authentication ~~codes)~~ is initialized or used in a way that prevents replay at the same or a different device.

• Sensitive information required for the authorization⎯e.g., passwords/authentication codes⎯ is initialized or used in a way that prevents replay at the same or a different device.

Removed p. 33

Q 3 May 2018: Can a POI device satisfy Security Requirement A5, if it has cryptographic implementations that may feasibly be attacked by side channel analysis (SCA) yet having no designed SCA countermeasures? A No. Even if physical protections against tampering are robust, and even in the presence of electronic noise and algorithmic complexity obscuring signals, it is expected that an attacker can defeat any undefended cryptographic implementation repeatedly exercising static keys. Hence, a device must have at least one demonstrably effective SCA countermeasure protecting all cryptographic algorithms in scope of DTR A5. For software implementations and hardware implementations with known countermeasures, the evaluation shall identify one countermeasure, at least, and show its effectiveness. For hardware implementations with unknown countermeasures, the evaluation shall demonstrate the implementation’s SCA characteristics are consistent with having at least one effective countermeasure.

Q 4 October 2018: What should correlation analysis achieve in an SCA test, to …

Modified p. 33 → 17

~~Q 2~~ May 2017: Are there any situations where the evaluation report does not have to provide an attack ~~costing.~~ A ~~Yes for A4~~ (Monitoring During PIN Entry), where testing of any external characteristic available for monitoring demonstrably satisfying the applicable DTR test steps has not found any leakage, then it must be explained why any attack scenario cannot be feasible for less than 26 points, with a minimum of 13 for initial exploitation. In such a situation no formal …

May 2017: Are there any situations where the evaluation report does not have to provide an attack costing? A Yes. For A5 (Monitoring During PIN Entry), where testing of any external characteristic available for monitoring demonstrably satisfying the applicable DTR test steps has not found any leakage, then it must be explained why any attack scenario cannot be feasible for less than 26 points, with a minimum of 13 for initial exploitation. In such a situation no formal attack calculation …

Modified p. 33 → 17

~~Q 2~~ July 2017: Evaluators typically use both source code review and testing of the implementation to verify that side channel protection methods are implemented. How must the evaluator proceed where protections are in code created by the chip vendor and this is only provided to the POI vendor as a library and not source code? A The evaluator must treat the device as a black box and extend testing beyond what would otherwise be required if the source code …

July 2017: Evaluators typically use both source code review and testing of the implementation to verify that side channel protection methods are implemented. How must the evaluator proceed where protections are in code created by the chip vendor and this is only provided to the POI vendor as a library and not source code? A The evaluator must treat the device as a black box and extend testing beyond what would otherwise be required if the source code was available …

Removed p. 34

Q 5 November 2020: POI v6 allows the reuse of testing for emanations (Side Channel Analysis) where testing was done from a prior major version i.e., 5.x. This is only allowed where a complete chain of trust is demonstrated validating why the previous testing is wholly applicable to the newly evaluated device. POI v5, under the same conditions, only allows reuse if less than 3 years old. Can POI v5 devices undergoing SCA use applicable testing from POI v4.x evaluations? A Yes, where applicable POI v5 emanations testing follows the same criteria as stipulated in the POI v6 DTRs.

POI Requirements A6, B16 and E3.4

Q 1 Does “non-PIN data” include data that can be entered while the device is in a maintenance mode? A No. A6, B16, and E3.4 are applicable to the device while in its normal working mode. A6, B16, or E3.4 does not apply to data entered while …

Modified p. 34 → 17

~~Q 3~~ The intent of ~~A6, B16,~~ and ~~E3.4~~ is to eliminate the possibility that PIN values will be entered at an improper time and handled by the device in a non-secure manner. One way for a vendor to address ~~A6, B16,~~ or ~~E3.4~~ is to allow for the entry of PIN values only. Would it be acceptable to allow the input of numerical data if the numerical data is three characters or less and therefore could not represent a …

POI Requirements A8, B15 and C2.4 The intent of A8, B15, and C2.4 is to eliminate the possibility that PIN values will be entered at an improper time and handled by the device in a non-secure manner. One way for a vendor to address A8, B15, or C2.4 is to allow for the entry of PIN values only. Would it be acceptable to allow the input of numerical data if the numerical data is three characters or less and therefore …

Modified p. 34 → 18

~~Q 6~~ Is it acceptable for uncontrolled messages to be displayed simultaneously with prompts for data entry? A No. Any text, including images, other than numbers and punctuation, displayed along with a prompt is considered a prompt and must comply with all requirements governing prompts.

Is it acceptable for uncontrolled messages to be displayed simultaneously with prompts for data entry? A No. Any text, including images, other than numbers and punctuation, displayed along with a prompt is considered a prompt and must comply with all requirements governing prompts.

Removed p. 35

A SCD is not required for protecting the user prompts if the authentication solution meets all of the following:

a) The signing device implements dual control mechanisms such that it is infeasible for a single person to sign user prompts.

b) The signing device provides for all logging details as stipulated in the requirement.

c) Compromise of a signing device does not compromise any other signing device.

d) Compromise of a signing device does not affect the security of POI devices outside the domain of the signing device.

e) POI devices outside the domain of any signing device cannot be modified to accept user prompts from other user prompt sources.

f) The signing device is a single use device or is used in a restricted secure area.

g) The vendor provides the secure operating procedures to the customer.

Q 9 December (update) 2017: For PEDs designed with multiple data acceptance interfaces, where there is a hard keypad dedicated …

Modified p. 35 → 18

~~Q 7~~ Some device designs fit either vendor-controlled or acquirer-controlled display prompts on who is given custody of cryptographic keys protecting prompt updates are managed. Does such a device need to have different identifiers? A If the device is to be listed as both an acquirer-controlled and a vendor-controlled display prompts device, there must be a differentiation so customers can distinguish between the ~~two (e.g.,~~ different hardware and/or firmware ~~versions).~~

Some device designs fit either vendor-controlled or acquirer-controlled display prompts on who is given custody of cryptographic keys protecting prompt updates are managed. Does such a device need to have different identifiers? A If the device is to be listed as both an acquirer-controlled and a vendor-controlled display prompts device, there must be a differentiation so customers can distinguish between the two⎯e.g., different hardware and/or firmware versions.

Modified p. 35 → 18

~~Q 8~~ For devices that implement acquirer-controlled prompts, is it required to use a secure cryptographic device to implement the dual control required to manage those prompts? A ~~Except as noted below, dual~~ control must be enforced by a SCD. The SCD can be the PED itself or another device. If a SCD other than the PED enforces dual control, the vendor must either provide the SCD to third ~~parties,~~ or describe how a SCD must be used to comply …

For devices that implement acquirer-controlled prompts, is it required to use a secure cryptographic device to implement the dual control required to manage those prompts? A Dual control must be enforced by an SCD. The SCD can be the PED itself or another device. If an SCD other than the PED enforces dual control, the vendor must either provide the SCD to third parties or describe how an SCD must be used to comply with B15. The description must include …

Modified p. 35 → 19

• The firmware must be designed such that no sensitive data can be entered into the “non- sensitive” ~~interface~~

• The firmware must be designed such that no sensitive data can be entered into the “non- sensitive” interface.

Modified p. 35 → 19

• If the x/y touch coordinates are sent to the authenticated applications on the device, the vendor must provide guidance to application developers to not ever send out touch coordinates. Additionally, the vendor also must review all applications and NOT sign/authenticate them if they are written to send out touch coordinates, thus not allowing them to be ~~loaded~~ or

• If the x/y touch coordinates are sent to the authenticated applications on the device, the vendor must provide guidance to application developers to not ever send out touch coordinates. Additionally, the vendor also must review all applications and NOT sign/authenticate them if they are written to send out touch coordinates, thus not allowing them to be loaded; or

Removed p. 36

Q 2 Is the attack potential of 18 per device to be applied to a single device, or averaged over multiple devices? A A6 addresses an attack performed on a single device. If an attack has a potential of 18 to develop, A6 is met regardless of whether or not applying the attack to additional devices is less than 18.

Q 3 The DTR “Appendix A•Guidance for the Privacy Screen Design” specifies size and weight guidelines for handheld devices. Are handheld devices required to meet these guidelines? A No. In order to be considered a handheld device, it must by weight, size, and shape encourage its handheld operation; however, the guidelines listed are suggestions, not requirements.

Q 4 Requirement A7 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 …

Modified p. 36 → 19

~~Q 1~~ Can the calculation for the attack potential of 18 per device include the cost of development kits that provide application programming information? A No. The device must include protections that require an attacker to achieve an attack potential of at least 18 to order to defeat them. Administrative controls on application programming information are not adequate to meet this requirement.

POI Requirement A8 Can the calculation for the attack potential of 18 per device include the cost of development kits that provide application programming information? A No. The device must include protections that require an attacker to achieve an attack potential of at least 18 to order to defeat them. Administrative controls on application programming information are not adequate to meet this requirement.

Modified p. 36 → 19

~~Q 3 Touch-screen~~ devices offer multiple possibilities for the data entry: traditional PIN pad layout, QWERTY layout, signature capture, handwriting recognition, etc. Does A6 apply to all of these methods of data entry, or only the traditional PIN pad? A A6 applies to all methods of data entry that can be used by a cardholder to disclose their PIN, including QWERTY layout, signature capture, and handwriting recognition.

April (update) 2025: Touchscreen devices offer multiple possibilities for the data entry: traditional PIN pad layout, QWERTY layout, signature capture, handwriting recognition, etc. Does A8 apply to all of these methods of data entry, or only the traditional PIN pad? A A8 applies to all methods of data entry that can be used by a cardholder to disclose their PIN, including QWERTY layout, signature capture, and handwriting recognition.

Modified p. 36 → 20

~~Q 1 What methods may be employed to comply with this requirement? A The PIN entry device must be equipped with a privacy shield, or designed~~ so that the cardholder can shield it with his/her body to protect against observation of the PIN during PIN ~~entry.~~

• 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;

Modified p. 36 → 20

~~Q 2 When a device is not a handheld device, it must have a~~ privacy shield ~~to meet A7. Are there any special considerations if the shield~~ is ~~detachable? A 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.~~

• 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;

Modified p. 36 → 20

• Limited viewing angle (for example, a polarizing filter or recessed PIN ~~pad),~~

• Limited viewing angle (for example, a polarizing filter or recessed PIN pad);

Modified p. 36 → 20

• Housing that is part of the ATM or kiosk, cardholder’s hand or body (applies to handheld devices ~~only),~~ and

• Housing that is part of the ATM or kiosk, cardholder’s hand or body (applies to handheld devices only); and

Removed p. 37

Q 1 March 2015: MSRs must have protections against any additions, substitutions, or modifications for the purpose of determining or modifying magnetic-stripe track data. Does that include attacks where a bug is installed on the opposite side of the card track of the original MSR such that the attacker would only capture card data if the cardholder swipes the card with the track side facing the wrong way? A Yes. Some MSRs are intentionally designed to capture the track data regardless of which way the card is swiped. Thus cardholders become conditioned to swiping the card from either side, even where the reader does not support.

Q 1 Requirement A9 states that the minimum attack potential for the removal of a secure component from its intended environment is 18 points. Does this figure include the cost required to produce and install an overlay bug after removal of the secure component? A …

Modified p. 37 → 20

~~Q 5~~ September (update) 2016: Is there any impact on the device’s approval if the laboratory evaluated privacy method is not used? A Frequently, the deployers of devices rationalize that privacy-protection mechanisms may be bulky or obtrusive, make it more difficult to see the device’s screen, or, with less dexterous users, interfere with card payment and PIN entry. However, in order to maintain the device’s approval, and any associated liability protection for compromise attributable to use of said device, it …

September (update) 2016: Is there any impact on the device’s approval if the laboratory evaluated privacy method is not used? A Frequently, the deployers of devices rationalize that privacy-protection mechanisms may be bulky or obtrusive, make it more difficult to see the device’s screen, or, with less dexterous users, interfere with card payment and PIN entry. However, in order to maintain the device’s approval, and any associated liability protection for compromise attributable to use of said device, it is required …

Modified p. 37 → 20

~~Q 6~~ September 2016: Vendors must either provide a privacy shield providing privacy protections during PIN entry for the cardholder, or alternatively, the vendor may use less restrictive privacy-shield criteria provided that the vendor supplies rules and guidance as to how the visual observation is to be deterred by the environment in which the device is installed. Does this impact the security policy disclosure? A Yes. The security policy must stipulate the rules and guidance under which the device was …

September 2016: Vendors must either provide a privacy shield providing privacy protections during PIN entry for the cardholder, or alternatively, the vendor may use less restrictive privacy-shield criteria provided that the vendor supplies rules and guidance as to how the visual observation is to be deterred by the environment in which the device is installed. Does this impact the security policy disclosure? A Yes. The security policy must stipulate the rules and guidance under which the device was evaluated as …

Removed p. 38

Q 2 May 2011: The procedure for authorized installation or re-installation must use dual controls. Dual-control techniques must use two or more separate entities (usually persons), operating in concert, to protect sensitive functions or information. Is it acceptable to use a dual-control technique where one party is a technician visiting the device and the other is not a person (for example, a remote server)? A Yes, provided that one single party cannot disable the removal-detection mechanism. Dual control implies mutual supervision and that for a breach to be committed; both parties must be in collusion. As such, a mechanism where the server allows disabling the removal-detection mechanism based only on the person’s authentication credentials is not acceptable, because it does not prevent access by someone with valid credentials, but with the intention of attacking the device. An acceptable technique would be, for example, that the server only grants access to …

Removed p. 41

Q 8 July 2013: Will micro-code be required to meet B1? A Chip-level code delivered with a component that cannot be configured, modified, or changed by any standard interface and, where an error cannot compromise the security of the device, does not need to be validated against Requirement B1. Examples may include smart card controllers, keypad controllers, or modem firmware.

Q 9 July 2015: Can a memory re-initialization (security) cycle last longer than 24 hours? A Yes, to allow the adjustment of the security cycle of the PIN Entry device (max. 24 hours duration) to the business cycle of an integrated POS system it may be connected to (max. 24 hours duration). The Firmware of the PIN Entry device, during the cycles’ adjustment processes, must not allow any security cycle to last longer than the combined maximum durations of the security cycle and the business cycle (48 hours). This must be …

Modified p. 41 → 23

~~Q 7~~ Under what circumstances can a device not use authenticity checking when self-testing its firmware? A A device does not require authenticity checking when self-testing its firmware if (all apply):

Under what circumstances can a device not use authenticity checking when self-testing its firmware? A A device does not require authenticity checking when self-testing its firmware if (all apply):

Modified p. 41 → 23

a) The authenticity checking of ~~firmware•either~~ internally and according to B4 or externally using appropriate procedures within a secured environment under the vendor’s ~~control•is~~ performed whenever the firmware is established in that secure area; and

• The authenticity checking of firmware

•either internally and according to B2 or externally using appropriate procedures within a secured environment under the vendor’s control

•is performed whenever the firmware is established in that secure area; and

Modified p. 41 → 23

b) The effort to deliberately modify or replace the firmware or parts of it in order to get access to sensitive information (access to the memory device) must be addressed as an attack scenario under Requirements A1, ~~A3,~~ and A5 and meet the respective attack potentials; and

• The effort to deliberately modify or replace the firmware or parts of it in order to get access to sensitive information (access to the memory device) must be addressed as an attack scenario under Requirements A1, A4, and A6 and meet the respective attack potentials; and

Modified p. 41 → 23

c) A periodic integrity check according to Requirement B1 is performed for the firmware, ensuring that random changes will be detected; and if cryptographic authenticity is not performed, the integrity check must be cryptographically based. Although an algorithm using a secret key, such as a keyed hash, can be used, it is not necessary for meeting the integrity criteria.

• A periodic integrity check according to Requirement B1 is performed for the firmware, ensuring that random changes will be detected; and if cryptographic authenticity is not performed, the integrity check must be cryptographically based. Although an algorithm using a secret key, such as a keyed hash, can be used, it is not necessary for meeting the integrity criteria.

Removed p. 42

Q 2 December 2012: The device’s functionality must not be influenced by logical anomalies. This includes assessment of the device’s interfaces and associated communication methods. What type of evidentiary matter should a vendor provide a lab to support this assessment? A The vendor shall provide evidentiary matter providing details on internal testing including, but not limited to, the following:

a) Source code reviews targeting specific relevant security•critical functionalities

b) Vulnerability analysis; that includes gathering and considering evidence necessary to perform practical testing

c) Penetration testing to validate the robustness of the device to protect against feasible attacks by addressing known attack methods. For example (but not restricted to) fuzzing; using appropriate tools and techniques

d) Audits of relevant existing test evidence, which may be utilized where appropriate, by giving justifications for validity of evidence and test methodologies overall.

The laboratory shall determine the veracity of the material provided to determine the degree of reliance that …

Modified p. 43 → 24

~~Q 3~~ December 2011: If a device supports firmware updates, the device must cryptographically authenticate the firmware, and if the firmware is not confirmed, the firmware update must be rejected and deleted. Can a device completely load new firmware before checking its authenticity and overwrite its primary copy of existing authenticated code if it retains a secure backup copy of the existing authenticated code? A Yes, provided the following is true:

December 2011: If a device supports firmware updates, the device must cryptographically authenticate the firmware, and if the firmware is not confirmed, the firmware update must be rejected and deleted. Can a device completely load new firmware before checking its authenticity and overwrite its primary copy of existing authenticated code if it retains a secure backup copy of the existing authenticated code? A Yes, provided the following is true:

Modified p. 43 → 24

a) The new code is cryptographically authenticated prior to execution.

• The new code is cryptographically authenticated prior to execution.

Modified p. 43 → 24

b) If the new code fails authentication, the backup copy of code is cryptographically authenticated, and if the backup copy is successfully authenticated, the device boots from the backup copy and the backup is then used to overwrite the new code that failed authentication. ~~c) If both firmware versions fail authentication, the device fails in a secure manner.~~

If the new code fails authentication, the backup copy of code is cryptographically authenticated, and if the backup copy is successfully authenticated, the device boots from the backup copy and the backup is then used to overwrite the new code that failed authentication.

Removed p. 44

Q 1 What symbols are acceptable as “non-significant”? A Any symbol can be used as long as it cannot be used to determine PIN values. Using a different symbol for different digit numbers or groups of numbers is not acceptable. Here is an example of symbol use that would NOT be allowed: 1=*, 2=@, 3=%.

Q 1 What does “encrypted immediately” mean in term of software or hardware architecture? A This means when the cardholder signifies that PIN entry is complete, either by pressing an “enter” button, or by entering the last digit of the PIN, the device does not perform any processes other than those required to encrypt the PIN.

Modified p. 44 → 24

~~Q 4~~ February 2017: If the device uses digital signatures for authenticating firmware updates (compliant with ~~B4),~~ does it need to use a secure protocol to meet ~~J4 and K9?~~ A B4 stipulates that firmware loaded into the device must be authenticated regardless of how the file is delivered to the device.

February 2017: If the device uses digital signatures for authenticating firmware updates (compliant with B2), does it need to use a secure protocol to meet B22? A B2 stipulates that firmware loaded into the device must be authenticated regardless of how the file is delivered to the device.

Modified p. 44 → 24

J4 ensures that the management platform delivers the files to the device securely and that the interface cannot be used as an attack vector into the device.

B2 ensures that the management platform delivers the files to the device securely and that the interface cannot be used as an attack vector into the device.

Modified p. 44 → 24

a) For remote ~~access, i.e.~~ the files are delivered to the device across a private or public ~~network, the~~ use of a security protocol is required and must be validated.

• For remote access⎯i.e., the files are delivered to the device across a private or public network⎯the use of a security protocol is required and must be validated.

Modified p. 44 → 24

b) For manual ~~access, i.e.~~ where the operator has physical control of the terminal and the files, and the files are not delivered across a ~~network, the~~ device must ensure that the interface cannot be exploited (e.g., by restricting access/functionality on the interface, requiring administrative rights, using cryptographic authentication techniques, ~~etc.) K9 states it is for remote access only and does not include a manual element, a security protocol would be required to ensure the interface cannot be exploited.~~

• For manual access⎯i.e., where the operator has physical control of the terminal and the files, and the files are not delivered across a network⎯the device must ensure that the interface cannot be exploited (e.g., by restricting access/functionality on the interface, requiring administrative rights, using cryptographic authentication techniques, etc.).

Modified p. 44 → 25

~~Q 2~~ Requirement B6 requires that a PIN be encrypted immediately. Typically, this means that the secure processor forms and encrypts the PIN block before performing any other operation. However, some device designs place a microprocessor between the keypad and the secure processor. Under what conditions, if any, would such a design be allowed? A Such a design is considered compliant if the microprocessor, the secure processor, and the path between them are completely within the protective boundary of the …

POI Requirement B4 Requirement B4 requires that a PIN be encrypted immediately. Typically, this means that the secure processor forms and encrypts the PIN block before performing any other operation. However, some device designs place a microprocessor between the keypad and the secure processor. Under what conditions, if any, would such a design be allowed? A Such a design is considered compliant if the microprocessor, the secure processor, and the path between them are completely within the protective boundary of …

Removed p. 45

Q 3 It is common practice for encrypting PIN pads used in ATMs to support the use of one command to initiate PIN entry and another command to encrypt the PIN. Is this acceptable under B6? A Yes. It is acceptable for an EPP to allow one command to initiate PIN entry and a second command to initiate PIN encryption. However, it must not be possible for the encryption command to be used to encrypt the PIN multiple times to output the encrypted PIN from the EPP under different cryptographic keys or to output the PIN in plain-text. Also, the plain-text PIN value must only exist in tamper protected memory or equivalent.

Q 5 April 2013: B6 requires that online PINs must be encrypted immediately after PIN entry is complete. It is further stipulated that plaintext PINs must not exist for more than one minute from the completion of the cardholder’s …

Modified p. 45 → 26

~~Q 4~~ September 2012: Devices may support the encipherment of the PIN multiple times as part of a transaction series. B6 stipulates that the encipherments must use the same encryption key for this series. Can the transaction series be encrypted by a series of keys if the current key is a derivation of a predecessor key? A The purpose of the requirement is to prevent an adversary from using the authorized key to send the transaction online for authorization and …

September 2012: Devices may support the encipherment of the PIN multiple times as part of a transaction series. B4 stipulates that the encipherments must use the same encryption key for this series. Can the transaction series be encrypted by a series of keys if the current key is a derivation of a predecessor key? A The purpose of the requirement is to prevent an adversary from using the authorized key to send the transaction online for authorization and another key …

Modified p. 45 → 26

Q 1 Is it acceptable to XOR key components during key loading to satisfy the authentication requirements of ~~B7?~~ A The XOR of key components alone is not enough to constitute authentication. Some type of authentication of the users that use the key loading function, or authentication of the key-loading command is required.

Q 1 Is it acceptable to XOR key components during key loading to satisfy the authentication requirements of B5? A The XOR of key components alone is not enough to constitute authentication. Some type of authentication of the users that use the key loading function, or authentication of the key-loading command is required.

Modified p. 46 → 26

~~Q 2~~ May (update) 2018: Under what circumstances is key entry via the device keypad permitted? A Plain-text secret keys cannot be entered into the device using the keypad. Plain-text key components may be entered via the keypad in accordance with ISO 11568-2. Encrypted keys may also be entered via the keypad. Entry of key components or encrypted keys must be restricted to authorized individuals. Functions used to enter keys must only be available when the device is ~~placed~~ in …

May (update) 2018: Under what circumstances is key entry via the device keypad permitted? A Plain-text single component secret keys cannot be entered into the device using the keypad. Plain-text key components may be entered via the keypad in accordance with ISO 11568-2. Encrypted keys may also be entered via the keypad. Entry of key components or encrypted keys must be restricted to authorized individuals. Functions used to enter keys must only be available when the device is in a …

Modified p. 46 → 26

~~Q 3~~ Do maintenance menus that provide services such as LCD Contract Adjustment, ~~Self-tests,~~ Printer Maintenance, and Key Tests constitute a “sensitive service?” A If the services provided in these normally non-permitted functions do not affect the security of the terminal or the cardholder data, they are not considered sensitive services. Only services that could compromise the security of the terminal are sensitive services.

Do maintenance menus that provide services such as LCD Contract Adjustment, Self- tests, Printer Maintenance, and Key Tests constitute a “sensitive service?” A If the services provided in these normally non-permitted functions do not affect the security of the terminal or the cardholder data, they are not considered sensitive services. Only services that could compromise the security of the terminal are sensitive services.

Modified p. 46 → 26

~~Q 4~~ For devices that require the use of authentication data to access sensitive functions, and the authentication data are static, can the authentication data be sent with the device? A The authentication data can be sent with the device only when the authentication data is in tamper-evident packaging, such as the use of PIN mailers. Otherwise separate communication channels must be used with pre-designated recipients.

For devices that require the use of authentication data to access sensitive functions, and the authentication data are static, can the authentication data be sent with the device? A The authentication data can be sent with the device only when the authentication data is in tamper-evident packaging, such as the use of PIN mailers. Otherwise separate communication channels must be used with pre-designated recipients.

Modified p. 46 → 27

~~Q 5~~ March 2011: Plain-text secret or private keys and their components may be injected into a PIN pad using a key loader (which has to be some type of secure cryptographic device). Are there any restrictions on loading keys via this methodology? A ~~Yes, the~~ loading of plain-text secret or private keys and their components using a key-loader device is restricted to secure key-loading facilities. Unattended devices deployed in the field shall have plain-text secret or private key loading …

March 2011: Plain-text secret or private keys and their components may be injected into a PIN pad using a key loader (which has to be some type of secure cryptographic device). Are there any restrictions on loading keys via this methodology? A Yes. The loading of plain-text secret or private keys and their components using a key-loader device is restricted to secure key-loading facilities. Unattended devices deployed in the field shall have plain-text secret or private key loading restricted to …

Modified p. 46 → 27

~~Q 6~~ December 2011: Devices may have functions for zeroizing secret and private keys in the device. Are these functions considered sensitive services that require authentication? A ~~Yes, the~~ intentional zeroization of secret or private keys in a non-tamper event is the execution of functions that are not available during normal use. This requires authentication consistent with the implementations of other sensitive services, such as the use of PINs/passphrases. If implemented, the device must force the authentication values to be …

December 2011: Devices may have functions for zeroizing secret and private keys in the device. Are these functions considered sensitive services that require authentication? A Yes. The intentional zeroization of secret or private keys in a non-tamper event is the execution of functions that are not available during normal use. This requires authentication consistent with the implementations of other sensitive services, such as the use of PINs/passphrases. If implemented, the device must force the authentication values to be changed from …

Removed p. 47

POI Requirements B7, B11, K17

Q 1 May (update) 2018: B7 defines sensitive functions as those functions that access sensitive data, such as cryptographic keys, and that authentication is required for such access. The guidance note for B7 stipulates that authentication shall be considered as dual-control techniques when entering sensitive information through a secure user interface, or cryptographic techniques when entering electronic data. The use of other techniques to access sensitive services results in the device being unable to use previously existing keying material. How does this guidance apply to secret or private key loading? A 1) When entering plain-text secret keys through the keypad, they must be entered as two or more components and require the use of at least two passwords/authentication codes. The passwords/authentication codes must be entered through the keypad or else conveyed encrypted into the device. These passwords/authentication codes must either be unique per device (and per …

Modified p. 47 → 27

~~Q 7~~ June (update) 2015: Devices may have functions for zeroizing secret and private keys in the device. This functionality is regarded as a sensitive service that requires authentication. In some cases there is an upstream effect where software changes must occur on interfaces points, such as ATM platforms, applications, switches and hosts that interface with EPPs. Is there any dispensation from this requirement? A All devices implementing this functionality must meet the requirement. However, the device may do so …

June (update) 2015: Devices may have functions for zeroizing secret and private keys in the device. This functionality is regarded as a sensitive service that requires authentication. In some cases there is an upstream effect where software changes must occur on interfaces points, such as ATM platforms, applications, switches and hosts that interface with EPPs. Is there any dispensation from this requirement? A All devices implementing this functionality must meet the requirement. However, the device may do so by implementing …

Removed p. 48

Injection of plain-text secret keys or their components/shares where the device does not itself require the use of at least two passwords/authentication codes for injection results in the zeroization of pre-existing secret keys. For devices supporting multiple key hierarchies (e.g., multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized. In all cases, the authentication values (passwords, authentication codes or similar) for each user on a given device must be different for each user.

3) For encrypted values injected into the device, either from a key loader or from a network host, or via loading through the keypad, the ability of the device to successfully decrypt the value and use it is sufficient. In this case, the loading of the key-encipherment key would have been done under dual control, e.g., in examples a) and b) above.

4) Remote key-loading techniques using public key …

Modified p. 48 → 28

~~Q 1~~ January 2015: It is a requirement of DTR D4 that a POI generate the EMV Unpredictable Number (UN) for any PIN based transaction using the internal RNG, as tested under requirement ~~B9.~~ Are non-PIN based transactions also required to generate the UN from the RNG of the POI? A Yes, the RNG of the POI must be used to generate all random and unpredictable values that are used for the security of card data and PIN transactions. When …

January 2015: It is a requirement of DTR B21 that a POI generate the EMV Unpredictable Number (UN) for any PIN based transaction using the internal RNG, as tested under requirement B7. Are non-PIN based transactions also required to generate the UN from the RNG of the POI? Yes, the RNG of the POI must be used to generate all random and unpredictable values that are used for the security of card data and PIN transactions. When the POI is …

Removed p. 49

Q 2 June (update) 2015: In order to prevent exhaustive PIN determination, examples of preventive measures such as a unique key per transaction or the limiting of the rate of PIN encryption to thirty seconds or greater between encipherments as measured over 120 transactions are given. Are any other methods possible? A The list of examples is not exhaustive. Other methods are possible. For example, the exclusive use of ISO PIN block formats 1, 3 and/or 4 whereby each PIN is enciphered using a unique except by chance random pad of characters with permissible values of 0000 to 1111 depending on the format may be used to prevent exhaustive PIN determination.

Q 3 One example given to prevent exhaustive PIN determination is to limit the rate of PIN encryption to thirty seconds or greater between encipherments as measured over 120 transactions. Can this average of 30 seconds between encipherments be determined …

Modified p. 49 → 28

~~Q 1~~ Is it acceptable for a device to have the ability to use Master Keys as both key-encryption keys for session key and as fixed keys•i.e., the Master Key could be used to encrypt PIN blocks and to decrypt session keys? A No. A key must be used for one purpose only as ~~mandated~~ in ANSI X9.24 and ISO 11568.

POI Requirement B9 Is it acceptable for a device to have the ability to use Master Keys as both key-encryption keys for session key and as fixed keys•i.e., the Master Key could be used to encrypt PIN blocks and to decrypt session keys? A No. A key must be used for one purpose only as required in ANSI X9.24 and ISO 11568.

Modified p. 49 → 28

~~Q 3~~ Is it acceptable to use the same authentication technique for loading both cryptographic keys and firmware? A The technique may be the same, but the secrets used for authentication must be different. Example: If RSA signatures are used, the RSA private key used to sign cryptographic keys for loading must be different from the private key used to sign firmware.

Is it acceptable to use the same authentication technique for loading both cryptographic keys and firmware? A The technique may be the same, but the secrets used for authentication must be different. Example: If RSA signatures are used, the RSA private key used to sign cryptographic keys for loading must be different from the private key used to sign firmware.

Modified p. 49 → 28

~~Q 4~~ Is it acceptable to use TDES ECB mode encryption for session keys when using the Master Key/session key technique? A Yes. TDES ECB mode can be used to encrypt session keys.

Is it acceptable to use TDES ECB mode encryption for session keys when using the Master Key/session key technique? A Yes. TDES ECB mode can be used to encrypt session keys.

Removed p. 50

Q 5 PCI PIN Security Requirement 20 states that all secret and private cryptographic keys ever- present and used for any function (e.g., key-encipherment or PIN-encipherment) by a transaction-originating terminal (device) that processes PINs must be unique (except by chance) to that device. How does this requirement apply to device testing? A Devices must implement unique secret and private keys for any function directly or indirectly related to PIN protection. The basic rule is that any private or secret key resident in the device that is directly or indirectly used for PIN protection whose compromise would lead to the compromise of the same key in another device must be unique per device. For example, this means not only the PIN-encryption key(s), but keys that are used to protect other keys, firmware- update and authentication keys and display prompt control keys. As stated in the requirement, this does not apply to …

Modified p. 50 → 28

~~Q 6~~ Is it acceptable to load double-length 128-bit TDES key components into a device in smaller ~~bit-values (e.g.,~~ two 64-bit parts held by key custodian 1 and two 64-bit parts held by key custodian ~~2)?~~ A Yes, provided the 128-bit cryptographic TDES keys (and key components) are generated and managed as full double-length ~~128 bit~~ TDES keys during their entire life cycle in accordance with ANSI X9.24 and ISO 11568.

Is it acceptable to load double-length 128-bit TDES key components into a device in smaller bit-values⎯e.g., two 64-bit parts held by key custodian 1 and two 64-bit parts held by key custodian 2? A Yes, provided the 128-bit cryptographic TDES keys (and key components) are generated and managed as full double-length 128-bit TDES keys during their entire life cycle in accordance with ANSI X9.24 and ISO 11568.

Modified p. 50 → 28

It would not be acceptable to generate ~~64 bit~~ keys or key components separately, and then concatenate them for use as a double length key after generation.

It would not be acceptable to generate 64-bit keys or key components separately, and then concatenate them for use as a double length key after generation.

Modified p. 50 → 28

If key-check values are used to ensure key integrity, they must be calculated over the entire 128- bit key component or the resultant 128-bit key, but never on a portion of the key or key component. In addition, the resultant key inside the device must be recombined in accordance with PCI requirements and ANSI/ISO standards. Similarly for triple-length keys, the entire ~~192 bit~~ key component or the resultant 192-bit key must be used to calculate the key-check values.

If key-check values are used to ensure key integrity, they must be calculated over the entire 128- bit key component or the resultant 128-bit key, but never on a portion of the key or key component. In addition, the resultant key inside the device must be recombined in accordance with PCI requirements and ANSI/ISO standards. Similarly for triple-length keys, the entire 192-bit key component or the resultant 192-bit key must be used to calculate the key-check values.

Modified p. 50 → 29

~~Q 8~~ ISO 11568-2 Symmetric ciphers, their key management and life cycle and ANSI X9.24-1 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques stipulate that any key that exists in a transaction-originating device shall not exist in any other such device. Does that apply to all secret and private keys contained in a device? A The intent of the requirement is that the compromise of a key in one transaction-originating ~~device (e.g.,~~ an EPP or POS ~~device) …~~

ISO 11568-2 Symmetric ciphers, their key management and life cycle and ANSI X9.24-1 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques stipulate that any key that exists in a transaction-originating device shall not exist in any other such device. Does that apply to all secret and private keys contained in a device? A The intent of the requirement is that the compromise of a key in one transaction-originating device⎯e.g., an EPP or POS device⎯does not impact the …

Removed p. 51

Q 9 ISO 11568-2 Symmetric ciphers, their key management and life cycle and ANSI X9.24-1 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques stipulate that a key-encipherment key shall be at least of equal or greater strength than the key that it is protecting. What keys does this apply to in a device? A This applies to any key-encipherment keys used for the protection of secret or private keys stored in the device or for keys used to encrypt any secret or private keys for loading or transport to the device. For purpose of this requirement, the following algorithms and keys sizes by row are considered equivalent.

Algorithm DES RSA Elliptic Curve DSA Minimum key size in number of bits 168 2048 224 2048/224 DES refers to non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the …

Modified p. 51 → 29

~~Q 10~~ Devices may support the remote loading of secret acquirer keys using asymmetric techniques. Any such remote key-loading protocol must provide for a mechanism to minimize the probability of man-in-the-middle attacks where a device may be spoofed into communicating with a non-legitimate host. One common mechanism is to “bind” the host to the device such that the device will not accept communications that are not digitally signed by the legitimate host and authenticated by the device. Different scenarios exist …

Devices may support the remote loading of secret acquirer keys using asymmetric techniques. Any such remote key-loading protocol must provide for a mechanism to minimize the probability of man-in-the-middle attacks where a device may be spoofed into communicating with a non-legitimate host. One common mechanism is to “bind” the host to the device such that the device will not accept communications that are not digitally signed by the legitimate host and authenticated by the device. Different scenarios exist where it …

Removed p. 52

Q 11 May (update) 2018: Remote key distribution using asymmetric techniques methodologies must provide for protection against man-in-the-middle attacks and the hijacking of PIN- acceptance devices where the devices are under a PKI hierarchy that facilitates more than one acquirer (e.g., a hierarchy under a PIN-acceptance device vendor’s Root). In order to achieve this, many vendors have implemented techniques that force the PIN-acceptance device to “bind” to a specific transaction-processing host’s certificate, and not accept commands digitally signed by any other hosts. However, in the case of portfolio transfers or other situations where a device must be decommissioned (unbound), from a specific host, what techniques are acceptable for compliance? A Decommissions, such as sending a new host’s certificate to replace the existing host’s certificate without authentication are not acceptable. Any remote decommissioning must require cryptographic techniques and be specific per PIN-acceptance device. For example:

a) The existing bound host can digitally …

Modified p. 55 → 30

a) The conversion from a less secure methodology ~~(non-TR-31~~ or ~~non-TR-31~~ equivalent) to a more secure ~~(TR-31~~ or equivalent) methodology must be nonreversible.

• The conversion from a less secure methodology (non-ANSI X9.143 or non-ANSI X9.143 equivalent) to a more secure (ANSI X9.143 or equivalent) methodology must be nonreversible.

Modified p. 55 → 30

b) When entering the plain-text KBPK (or equivalent) through the keypad, it must be entered as two or more components and require the use of at least two passwords/authentication codes. The passwords/authentication codes must be entered through the keypad or else conveyed encrypted into the device.

• When entering the plain-text KBPK (or equivalent) through the keypad, it must be entered as two or more components and require the use of at least two passwords/authentication codes. The passwords/authentication codes must be entered through the keypad or else conveyed encrypted into the device.

Modified p. 55 → 31

c) Loading of a plaintext KBPK (or equivalent) using a key loader must be done using dual control and require the use of two or more passwords/authentication codes before injection of the key. These passwords/authentication codes are entered directly through the keypad of the applicable device or are conveyed encrypted into the device and must be at least seven characters in length. These passwords/authentication codes must either be unique per device (and per custodian), except by chance, or if vendor …

• Loading of a plaintext KBPK (or equivalent) using a key loader must be done using dual control and require the use of two or more passwords/authentication codes before injection of the key. These passwords/authentication codes are entered directly through the keypad of the applicable device or are conveyed encrypted into the device and must be at least seven characters in length. These passwords/authentication codes must either be unique per device (and per custodian), except by chance, or if vendor …

Modified p. 55 → 31

d) It is not permitted to load the KBPK to the device encrypted by a ~~non-TR-31~~ or ~~non-TR-31~~ equivalent symmetric key. However, the KBPK may be loaded using asymmetric techniques.

• It is not permitted to load the KBPK to the device encrypted by a non-ANSI X9.143 or non- ANSI X9.143 equivalent symmetric key. However, the KBPK may be loaded using asymmetric techniques.

Removed p. 56

Q 21 August 2011: When a device is converted to or otherwise implements TR-31, the conversion must be one way. On a device supporting multiple independent key hierarchies, such as one designed to support multiple acquirers, does the implementation apply to all key hierarchies on the device? A No, a device supporting multiple independent hierarchies may implement TR-31 (or equivalent) on a hierarchy-by-hierarchy basis.

Q 23 Some devices allow the use of a decrypt data function that if not controlled may allow sensitive information

•e.g., keys or PINs

•to be output in the clear. How must a device protect against the outputting of sensitive data? A It must be managed using at least one of five techniques:

Modified p. 56 → 31

~~Q 20~~ The Guidance for DTR ~~B11~~ states, “A device may include more than one compliant ~~key- exchange~~ and storage scheme. This does not imply that the device must enforce ~~TR-31~~ or an equivalent scheme, but it must be capable of implementing such a scheme as a configuration option.” If the use of ~~TR-31~~ as the key-exchange mechanism is optional, must there be an explicit device configuration change to enable/disable ~~TR-31~~ as the "active" key-exchange scheme? A ~~Yes an~~ explicit …

November (update) 2022: The Guidance for DTR B9 states, “A device may include more than one compliant key-exchange and storage scheme. This does not imply that the device must enforce ANSI X9.143 or an equivalent scheme, but it must be capable of implementing such a scheme as a configuration option.” If the use of ANSI X9.143 as the key-exchange mechanism is optional, must there be an explicit device configuration change to enable/disable ANSI X9.143 as the "active" key-exchange scheme? A …

Modified p. 56 → 31

~~Q 22~~ Are there any restrictions on how the terminal master key is loaded into the device? A The initial terminal master key (TMK) must be loaded to the device using either asymmetric key- loading techniques or manual techniques•e.g., the device keypad, IC cards, key-loading device, etc. Subsequent loading of the terminal master key may use asymmetric techniques, manual techniques, or the existing TMK to encrypt the replacement TMK for download. Keys are not allowed to be reloaded by any …

Are there any restrictions on how the terminal master key is loaded into the device? A The initial terminal master key (TMK) must be loaded to the device using either asymmetric key- loading techniques or manual techniques•e.g., the device keypad, IC cards, key-loading device, etc. Subsequent loading of the terminal master key may use asymmetric techniques, manual techniques, or the existing TMK to encrypt the replacement TMK for download. Keys are not allowed to be reloaded by any methodology in …

Modified p. 56 → 32

a) The key-usage information of any downloaded key must be cryptographically bound to the key value using accepted methods, and the device must enforce that the key is only used for the intended use.

• The key-usage information of any downloaded key must be cryptographically bound to the key value using accepted methods, and the device must enforce that the key is only used for the intended use.

Modified p. 56 → 32

b) The addition of a new key type (slot) subsequent to the initial configuration of the device causes the zeroization of all other secret keys, Devices supporting remote key-distribution techniques using asymmetric techniques shall only support the use of such techniques for the loading of TMKs. Support shall not exist to use remote key-distribution techniques for working ~~keys (e.g.,~~ PIN, data, MAC, ~~etc.) unless~~ the key-usage information is cryptographically bound to each individual key.

• The addition of a new key type (slot) subsequent to the initial configuration of the device causes the zeroization of all other secret keys, Devices supporting remote key-distribution techniques using asymmetric techniques shall only support the use of such techniques for the loading of TMKs. Support shall not exist to use remote key-distribution techniques for working keys⎯e.g., PIN, data, MAC, etc.⎯unless the key-usage information is cryptographically bound to each individual key.

Modified p. 56 → 32

c) Downloaded data key types must not be accepted by the device unless enciphered by a different terminal master key than sensitive keys such as the PEK or MAC key types.

• Downloaded data key types must not be accepted by the device unless enciphered by a different terminal master key than sensitive keys such as the PEK or MAC key types.

Modified p. 56 → 32

d) The device does not provide any support for a decrypt data or similar function.

• The device does not provide any support for a decrypt data or similar function.

Modified p. 56 → 32

e) The device must ensure that keys with different purposes can never have the same value; this requirement must be maintained until the device is decommissioned (or until the applicable TMK(s) changes).

• The device must ensure that keys with different purposes can never have the same value; this requirement must be maintained until the device is decommissioned (or until the applicable TMK(s) changes).

Modified p. 56 → 32

~~Q 24~~ May (update) 2018: Can secret keys or their components be used for other purposes such as passwords/authentication codes to enable the use of sensitive services? A No. The use of secret keys or their components for other purposes violates the requirement that keys be used for their sole intended ~~purpose, e.g.,~~ key encipherment or PIN encipherment, etc.

May (update) 2018: Can secret keys or their components be used for other purposes such as passwords/authentication codes to enable the use of sensitive services? A No. The use of secret keys or their components for other purposes violates the requirement that keys be used for their sole intended purpose⎯e.g., key encipherment or PIN encipherment, etc.

Removed p. 57

Note that PIN pads and integrated circuit card readers used in unattended devices that have anti-removal mechanisms to protect against unauthorized removal and/or unauthorized re- installation may not require zeroization of keys for repair purposes if all other tamper protection mechanisms remain active. These mechanisms must be validated as part of the device’s PCI POI approval and must be appropriately implemented in accordance with applicable POI requirements, including technical FAQs.

Q 26 May 2018: POI devices may possess asymmetric key pairs for use in remote key loading to the device. A POI key pair used for remote key distribution cannot be used for other purposes. Can a device use the same key pair for both authentication and encryption? A Yes, currently that is allowed. For example a POI private key used for remote key distribution may be used for both decryption and for creating digital signatures. However, effective 1 September 2018, …

Modified p. 57 → 32

~~Q 25~~ September (update) 2016: The PCI PIN Security Requirements stipulate that any cryptographic device used in connection with the acquisition of PIN data that is removed from service must have all keys stored within the device destroyed that have been used (or potentially could be) for any cryptographic purpose. If necessary to comply with the above, the device must be physically destroyed so that it cannot be placed into service again, or allow the disclosure of any secret data …

September (update) 2016: The PCI PIN Security Requirements stipulate that any cryptographic device used in connection with the acquisition of PIN data that is removed from service must have all keys stored within the device destroyed that have been used (or potentially could be) for any cryptographic purpose. If necessary to comply with the above, the device must be physically destroyed so that it cannot be placed into service again, or allow the disclosure of any secret data or keys. …

Modified p. 57 → 32

a) Specific menu commands to zeroize stored keys

• Specific menu commands to zeroize stored keys

Modified p. 57 → 32

b) Inducement of a tamper event to zeroize those keys

• Inducement of a tamper event to zeroize those keys

Modified p. 57 → 32

c) Encryption by a key of equal or greater strength that is itself ~~zeroized,~~ i.e., only cryptograms of the protected keys are recoverable.

• Encryption by a key of equal or greater strength that is itself zeroized⎯ i.e., only cryptograms of the protected keys are recoverable.

Modified p. 58 → 33

~~Q 27~~ May 2018: ANSI TR-34 describes two protocols for implementing the distribution of symmetric keys using asymmetric techniques. The two techniques are described as the Two Pass method and the One Pass method and should be used as follows: ~~• The Two Pass method is appropriate for where the POI and KDH can communicate in real time. It uses random nonces for the prevention of replay attacks.~~

May 2018: ANSI TR-34 describes two protocols for implementing the distribution of symmetric keys using asymmetric techniques. The two techniques are described as the Two Pass method and the One Pass method and should be used as follows:

Modified p. 58 → 33

• The One Pass method is appropriate for environments where the POI and KDH will not be able to communicate in ~~real-time i.e.~~ the POI cannot initiate the sequence of cryptographic protocol messages. In these environments, the KDH will generate the cryptographic message that can be transported to the POI over untrusted channels in non-real time. It includes the use of time-stamps in lieu of random nonces to prevent replay attacks.

• The One Pass method is appropriate for environments where the POI and KDH will not be able to communicate in real-time⎯i.e., the POI cannot initiate the sequence of cryptographic protocol messages. In these environments, the KDH will generate the cryptographic message that can be transported to the POI over untrusted channels in non-real time. It includes the use of time-stamps in lieu of random nonces to prevent replay attacks.

Modified p. 58 → 33

The malicious keying of a POI device by a second KDH under the same PKI is possible where the POI has already exchanged credentials with a first KDH. In order to prevent this attack, binding (or an equivalent method as noted in ~~FAQ B11 #12)~~ is necessary for all POI ~~devices,~~ and is a pre-requisite for both the Two Pass and One Pass key exchange protocols.

The malicious keying of a POI device by a second KDH under the same PKI is possible where the POI has already exchanged credentials with a first KDH. In order to prevent this attack, binding (or an equivalent method as noted in the DTR B9 guidance) is necessary for all POI devices and is a pre-requisite for both the Two Pass and One Pass key exchange protocols.

Modified p. 58 → 33

Are POI devices required to support both methods? A ~~No a~~ device may support only one. Whether the device supports only one or both, the vendor must describe in the device’s security policy that is posted to the PCI website the environments and circumstances under which it is appropriate to implement the supported method(s).

Are POI devices required to support both methods? A No. A device may support only one. Whether the device supports only one or both, the vendor must describe in the device’s security policy that is posted to the PCI website the environments and circumstances under which it is appropriate to implement the supported method(s).

Removed p. 59

Q 28 September 2020: PIN Security Requirement 18-3 requires the implementation of key blocks.

Interoperable methods include those defined in ASC X9 TR-31 and ISO 20038. The requirement also allows for any equivalent method whereby the equivalent method includes the cryptographic binding of the key-usage information to the key value using accepted methods. How are equivalent methods determined? A Equivalent methods must be subject to an independent expert review and said review is publicly available for peer review:

a) The review by the independent expert must include proof that in the equivalent method the encrypted key and its attributes in the Key Block have integrity protection such that it is computationally infeasible for the key to be used if the key or its attributes have been modified. Modification includes, but is not limited to: o Changing or replacing any bit(s) in the attributes or encrypted key o Interchanging any bits of the …

Modified p. 60 → 34

a) It must prevent the loading of PIN, MAC, and/or Data keys - or any keys used to manage these within the key hierarchy - from being used for another purpose. IPEK, KEKs, and derivation keys must be uniquely identified where supported. b) It must prevent the determination of key length for variable length keys. c) It must ensure that the key can only be used for a specific algorithm (such as TDES or AES, but not both). d) It …

Modified p. 60 → 34

~~• new devices must support AES). o~~ To implement confidentiality controls over any key metadata other than the key length. ~~o Support for asymmetric algorithms.~~

e) To implement confidentiality controls over any key metadata other than the key length.

Removed p. 61

Q 31 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.

Modified p. 61 → 35

~~Q 30 September 2020:~~ POI devices are required to support key blocks using the ~~ASC X9 TR-31~~ key-derivation methodology for TDES keys, and for AES keys must support either the ~~TR- 31~~ methodology and/or the ISO 20038 methodology. ~~TR-31~~ and ISO 20038 are methods to package keys (the key blocks) for conveyance or storage, but they use symmetric mechanisms for that and for key conveyance require a symmetric key exchange key that is pre-shared for use as the key block …

November 2022: POI devices are required to support key blocks using the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology and/or the ISO 20038 methodology. ANSI X9.143 and ISO 20038 are methods to package keys (the key blocks) for conveyance or storage, but they use symmetric mechanisms for that and for key conveyance require a symmetric key exchange key that is pre-shared for use as the key block protection key. …

Modified p. 61 → 35

~~• The Key Block Binding Method~~ However, TR-34 uses asymmetric methods for the Key Block Binding Method, instead of the symmetric methods used in ~~TR-31~~ or ISO 20038 which require that a symmetric key was previously exchanged between the POI device and the KDH.

However, TR-34 uses asymmetric methods for the Key Block Binding Method, instead of the symmetric methods used in ANSI X9.143 or ISO 20038 which require that a symmetric key was previously exchanged between the POI device and the KDH.

Modified p. 61 → 35

~~Q 32 December 2020:~~ Devices must support the ANSI ~~TR-31~~ key-derivation methodology for TDES keys, and for AES keys must support either the ~~TR-31~~ methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and said review is publicly available for peer review. What constitutes publicly available? A “Publicly available" means posted in a forum or otherwise published such that it is available for peer review for the time …

November 2022: Devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and said review is publicly available for peer review. What constitutes publicly available? A “Publicly available" means posted in a forum or otherwise published such that it is available for peer review for the time frame …

Modified p. 61 → 35

~~Q 33~~ April 2021: ANSI TR-34 allows RSA keys with a modulus of 2048 bits to encrypt 128-bits AES keys for transport. This is an exception to the general rule that key encryption keys must be of equal or greater strength to the keys they protect. Are there any other exceptions? A No. The intent of the allowance of using RSA keys that are weaker in strength than the keys they transport is to leverage the cryptographic algorithms and key …

April 2021: ANSI TR-34 allows RSA keys with a modulus of 2048 bits to encrypt 128-bits AES keys for transport. This is an exception to the general rule that key encryption keys must be of equal or greater strength to the keys they protect. Are there any other exceptions? A No. The intent of the allowance of using RSA keys that are weaker in strength than the keys they transport is to leverage the cryptographic algorithms and key strengths in …

Removed p. 62

Q 1 ISO 9564 stipulates that a PIN shall be not less than four and not more than twelve characters in length. What PIN lengths must an EPP or POS device support? A EPPs and POS devices must be able to support from four- to twelve-digit PINs for payment card transactions.

Q 2 October 2016: POI devices must support at least one of the following PIN block formats if supporting online PIN entry:

• ISO Format 4 Can a device support all four online PIN block formats? A Yes, a device may support any combination of PIN block formats. However, the device must provide support for ISO Format 4, the extended PIN Block Format, which uses 128 bit ciphers, e.g., AES. As stated in the PCI PIN Security Requirements RSA keys encrypting keys greater in strength than double-length TDEA keys shall use a modulus of at least 2048 bits.

Q 1 Is it …

Removed p. 63

Q 5 What constitutes appropriate algorithms and key sizes? A Appropriate algorithms and key sizes will change slowly over time, as the computing capability for brute force attacks will increase. At the moment, examples of appropriate algorithms and key sizes are:

Algorithm DES RSA Elliptic Curve DSA Minimum key size in number of bits 112 2048 224 2048/224 DES refers to non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. The DSA key sizes refer to the size of the modulus and the minimum size of a large subgroup.

AES may also be used with a key size of at least 128 bits.

Principles of dual control/split knowledge apply as defined in ISO 11568.

Modified p. 63 → 37

~~Q 1~~ What is the definition of “cryptographic unit”? A The cryptographic unit is the microprocessor that encrypts the PIN block. This processor is subject to PCI device requirements, and is therefore considered secure when within a compliant device. This means that a general-purpose micro-controller can be used as long as it is within a device that complies with PCI device requirements.

POI Requirement B15 What is the definition of “cryptographic unit”? A The cryptographic unit is the microprocessor that encrypts the PIN block. This processor is subject to PCI device requirements, and is therefore considered secure when within a compliant device. This means that a general-purpose micro-controller can be used as long as it is within a device that complies with PCI device requirements.

Modified p. 63 → 37

~~Q 2~~ Is it acceptable to use an LED controlled exclusively by the crypto-processor as the prompt for PIN entry? A No. Cardholders expect the prompt for PIN to come from the same display as other prompts. If it does not, there is a greater possibility of cardholders being misdirected.

Is it acceptable to use an LED controlled exclusively by the crypto-processor as the prompt for PIN entry? A No. Cardholders expect the prompt for PIN to come from the same display as other prompts. If it does not, there is a greater possibility of cardholders being misdirected.

Modified p. 63 → 37

~~Q 3~~ Would the display of plain-text PIN digits by the device qualify as tamper evidence? A No. The cardholder may not be familiar with the typical behavior of a given device and may not recognize that the device is violating Requirement ~~B5.~~

Would the display of plain-text PIN digits by the device qualify as tamper evidence? A No. The cardholder may not be familiar with the typical behavior of a given device and may not recognize that the device is violating Requirement B3.

Modified p. 63 → 37

~~Q 4~~ If a terminal includes a display under its control and a keypad with its own display, must the cryptographic unit of the device control both displays? A Yes. If a single device has two displays that could prompt the cardholder for data, then both displays would be governed under ~~B16.~~ This means the terminal and keypad are a single device that must meet PCI requirements.

If a terminal includes a display under its control and a keypad with its own display, must the cryptographic unit of the device control both displays? A Yes. If a single device has two displays that could prompt the cardholder for data, then both displays would be governed under B15. This means the terminal and keypad are a single device that must meet PCI requirements.

Removed p. 64

Q 6 What log file characteristics and content are necessary to meet Requirement B16? A A device must automatically record events that are relevant to B16 to a file that is automatically saved. Because each device vendor solution will be unique, the data set that is appropriate to be included in a log file can vary. At a minimum, it is expected that actions that involve cryptographic operations, the user(s) and the time and date of the action will be recorded in the log file. The logs may exist either internally or externally to the device, and a mechanism must be implemented which prohibits the overwriting of log events without proper authentication.

Q 9 May (update) 2018: Can USB authentication tokens or smart cards be considered to be the SCD required to enforce dual control under B16? A The use of dual tokens alone would not meet the requirement. The tokens …

Modified p. 64 → 37

~~Q 7~~ Cryptographic keys used for updating display prompts must be managed under the principles of dual control and split knowledge, and any secret or private keys used must not appear in the clear outside of a secure cryptographic device. Can the authentication data used to enable use of a signing or MACing key travel through an unprotected environment•e.g., the unprotected RAM of a computer? A The authentication data may exist in the clear outside of a secure cryptographic device. …

Cryptographic keys used for updating display prompts must be managed under the principles of dual control and split knowledge, and any secret or private keys used must not appear in the clear outside of a secure cryptographic device. Can the authentication data used to enable use of a signing or MACing key travel through an unprotected environment•e.g., the unprotected RAM of a computer? A The authentication data may exist in the clear outside of a secure cryptographic device. However, the …

Modified p. 64 → 37

~~Q 8~~ What logging requirements must be met by a SCD under ~~B16?~~ A The logs must provide sufficient evidentiary matter to demonstrate to the lab that the control techniques and mechanisms specified by the vendor exist.

What logging requirements must be met by an SCD under B15? A The logs must provide sufficient evidentiary matter to demonstrate to the lab that the control techniques and mechanisms specified by the vendor exist.

Modified p. 64 → 38

~~Q 10~~ May 2011: If a device complies with ~~B16,~~ what are the requirements for controlling the updates of these prompts? A ~~B16~~ is assessed when a device uses firmware updates to control the changing of display prompts. Therefore, updating of prompts for devices that comply with ~~B16~~ requires the creation of a new firmware version, and a resultant change in the firmware version number of the PED.

May 2011: If a device complies with B15, what are the requirements for controlling the updates of these prompts? A B15 is assessed when a device uses firmware updates to control the changing of display prompts. Therefore, updating of prompts for devices that comply with B15 requires the creation of a new firmware version, and a resultant change in the firmware version number of the PED.

Modified p. 64 → 38

It is not acceptable to have vendor-controlled prompts that are updated separately of the firmware, without the generation of a new firmware version. It is acceptable for prompt updates to use a separate cryptographic key to that used for other firmware updates•but any separate update method must be assessed by the laboratory as being compliant to Requirements B3 and ~~B4.~~ At all times, the cryptographic keys used to update prompts and firmware must be different than those used to update …

It is not acceptable to have vendor-controlled prompts that are updated separately of the firmware, without the generation of a new firmware version. It is acceptable for prompt updates to use a separate cryptographic key to that used for other firmware updates•but any separate update method must be assessed by the laboratory as being compliant to Requirements E2 and B2. At all times, the cryptographic keys used to update prompts and firmware must be different than those used to update …

Modified p. 64 → 38

~~Q 11~~ May 2011: If a device complies with ~~B16,~~ does this mean I need to re-submit the device for lab evaluation every time I change the prompts? A If there are suitable wildcards in the firmware version listing to accommodate new prompt versions that have been previously reviewed and confirmed as appropriate by a PCI laboratory, the review of each change by a PCI laboratory is not necessary.

May 2011: If a device complies with B15, does this mean I need to re-submit the device for lab evaluation every time I change the prompts? A If there are suitable wildcards in the firmware version listing to accommodate new prompt versions that have been previously reviewed and confirmed as appropriate by a PCI laboratory, the review of each change by a PCI laboratory is not necessary.

Removed p. 65

Q 1 July 2014: Does the security policy need to state the exact approval class and use case of the device? A Yes, the security policy must state the exact approval class and use case of the device. For example, a device approved under the Non-PED approval class must outline that the use of the device to accept customer PIN data will invalidate the device’s PCI approval.

Modified p. 65 → 38

~~Q 12~~ May 2011: Requirement ~~B16~~ does not specify any minimum attack potential. What requirements are placed on the physical security of a device that allows for display prompts to be updated by third parties using cryptographically based controls? A All prompts that may be used to request plaintext data entry from the cardholder must be secured against an attack potential of at least 18 PCI points with a minimum of 9 for exploitation. This includes prompts that may be …

May 2011: Requirement B15 does not specify any minimum attack potential. What requirements are placed on the physical security of a device that allows for display prompts to be updated by third parties using cryptographically based controls? A All prompts that may be used to request plaintext data entry from the cardholder must be secured against an attack potential of at least 18 PCI points with a minimum of 9 for exploitation. This includes prompts that may be updated by …

Modified p. 65 → 38

~~Q 13~~ March 2015: PIN pads designed for use with ATMs typically support both a secure (encrypts the data entered) and non-secure state. Does the transition between states require authentication? A ~~Yes, cryptographic~~ mechanisms consistent with Appendix D of the POI Derived Test Requirements must be used for the authentication. Specifically:

March 2015: PIN pads designed for use with ATMs typically support both a secure (encrypts the data entered) and non-secure state. Does the transition between states require authentication? A Yes. Cryptographic mechanisms consistent with Appendix D of the POI Derived Test Requirements must be used for the authentication. Specifically:

Modified p. 65 → 38

• For touchscreens, the management of the keypad ~~‘buttons’~~ is done in a secure way to prevent the determination of the customer PIN through exploitation of potential differences in the displayed keypad and the organization of the numeric buttons on the touch interface.

• For touchscreens, the management of the keypad “buttons” is done in a secure way to prevent the determination of the customer PIN through exploitation of potential differences in the displayed keypad and the organization of the numeric buttons on the touch interface.

Modified p. 65 → 38

This is not to ~~infer~~ that the device must force the implementation, but that it must provide support for such an implementation. ~~Note this FAQ is effective 1 July 2015 POI Requirement B18~~

This is not to imply that the device must force the implementation, but rather that it must provide support for such an implementation.

Modified p. 65 → 39

Q 1 August 2011: The operating system of the device must contain only necessary components and must be configured securely and run with least privilege. What is considered an “operating system” for PCI purposes? A In the scope of PCI-PTS, any underlying software providing services for code running in the device is considered part of the operating system. Examples of such services ~~include:~~ system initialization and boot, hardware abstraction layers, memory management, multitasking, synchronization primitives, file systems, device ~~drivers~~ and …

Q 1 August 2011: The operating system of the device must contain only necessary components and must be configured securely and run with least privilege. What is considered an “operating system” for PCI purposes? A In the scope of PCI-PTS, any underlying software providing services for code running in the device is considered part of the operating system. Examples of such services include system initialization and boot, hardware abstraction layers, memory management, multitasking, synchronization primitives, file systems, device drivers, and …

Removed p. 66

Q 4 August 2022: Vendors can have various options for both hardware and firmware that may be either security or non-security relevant. For non-security relevant options, vendors are allowed to designate in their hardware/firmware identifiers a lower case ‘x’ in the relevant position. Security relevant options must have specific numbers and/or letters assigned and listed as part of the approval. The program guide specifies that options, both security and non-security relevant must be clearly defined and documented as to the options available and their function in the device’s Security Policy. Through oversight, some Security Policies do not have this information. Does this information need to be included? A Yes. All report submittals, whether ‘New’ or ‘Delta’ must ensure that the device’s Security Policy required for the PCI website includes this information. This includes necessary updates to existing Security Policies.

Modified p. 66 → 41

Q 2 June 2015: Is there any impact on the device’s approval if the laboratory evaluated security policy is changed by the vendor? A Beginning with V4, the content of the security policy is part of the evaluation of a device by the laboratory and is an integral input upon which the approval of a device is based. Deployers rely on the security policy in order to ensure that they do not breach the conditions of a device's approval. Any …

Q 1 June 2015: Is there any impact on the device’s approval if the laboratory evaluated security policy is changed by the vendor? A Beginning with V4, the content of the security policy is part of the evaluation of a device by the laboratory and is an integral input upon which the approval of a device is based. Deployers rely on the security policy in order to ensure that they do not breach the conditions of a device's approval. Any …

Modified p. 66 → 41

Q 3 October (update) 2018: The PCI PTS Lab Requirements prohibit a PTS lab from creating any ~~vendor-documentation.~~ Are there any scenarios where a PTS lab may assist a vendor in creating documentation? A In some cases, a PTS lab may revise a Security Policy for grammar, formatting, or spelling edits for a device under evaluation. This may be done to assist the vendor in creating a document sufficient to be submitted to PCI. In this case, the PTS lab …

Q 2 October (update) 2018: The PCI PTS Lab Requirements prohibit a PTS lab from creating any vendor documentation. Are there any scenarios where a PTS lab may assist a vendor in creating documentation? A In some cases, a PTS lab may revise a Security Policy for grammar, formatting, or spelling edits for a device under evaluation. This may be done to assist the vendor in creating a document sufficient to be submitted to PCI. In this case, the PTS …

Removed p. 67

Q 1 What are acceptable methods of meeting this requirement? A The use of accepted key-management techniques will typically satisfy this requirement:

However, when the device is intended to support multiple acquirers and the acquirer is selected by a user (i.e., merchant pressing a button), the device must verify that the correct acquirer has been chosen.

Q 2 Is it acceptable for a device that supports multiple key hierarchies to meet C1 by ensuring that specific applications can only access keys that are associated with them? A Yes. It is acceptable provided each application can only access a single key hierarchy’s keys.

Q 3 What are acceptable means of external cryptographic keys selection? A Keys may be selected through the device keypad, or commands sent from another device such as an electronic cash register. Any commands sent from another device must be cryptographically authenticated to protect against man-in-the-middle and replay attacks.

Q 4 If …

Removed p. 68

b) Key hierarchies can only be established in accordance with Requirement B7. New key hierarchies must be authenticated using dual control (passwords/authentication codes) either via the key loader or directly via the EPP or POS PED. Existing key hierarchies may be replaced without using authentication if the loading results in the zeroization of pre- existing secret keys, i.e., the invoking of the key-loading function/command causes the zeroization prior to the actual loading of the new key. In addition, existing key hierarchies may be replaced or new key hierarchies may be established through the use of remote key distribution using asymmetric techniques that are in compliance with the PCI PIN Security Requirements, Annex A.

Q 7 When is C1 not applicable to acquirer-controlled display prompt devices? A C1 is not applicable to acquirer-controlled display prompt B devices that do not include commands for external key selection, or cannot hold multiple keys related …

Removed p. 71

Q 2 When is “No” or “N/A” an acceptable response to D4.1, D.4.2, D4.3, and D4.4? A “No” or “N/A” is only an acceptable response when the device does not support the specified method of PIN submission to the IC Card.

Q 3 How many options should be marked “Yes” if a device supports more than one of the PIN submission options? A All applicable options must be checked “Yes.” The evaluation laboratory will verify that all responses are appropriate.

Q 1 February 2012: Are there any scenarios where an OEM device intended for use in an unattended environment does not require protections against unauthorized removal? A Yes. Self-contained OEM products that are “bolt-on” or drop-in type modules, i.e. fully functional PED modules integrating all required components, do not require removal protections if the module provides a complete tamper envelope around all security sensitive parts, and any attacks considered during the evaluation …

Removed p. 72

Q 1 May 2018: Effective 1 May, 2018, POI vendors must complete and submit to PCI an Attestation of Validation (AOV) that includes providing evidentiary materials that an auditable record of an ongoing vulnerability assessment process exists. This is demonstrated by providing a copy of the vendor’s sign-off form specified in Requirement G1 regarding all physical interfaces and the corresponding logical protocols that are supported by the device as stated in Requirement F1. This applies to all unexpired approvals that exist for the vendor as of 31 December of the prior year. Does this vulnerability assessment process apply to non-public domain protocols and interfaces? A Yes the intent of the vulnerability assessment process is to be comprehensive. Effective with the May 2019 reporting for the 2018 calendar year, the vulnerability process reported on in the AOV must include all physical interfaces and their corresponding logical protocols. To facilitate this, evaluations …

Removed p. 73

Q 3 December 2017: Account data is defined to include the full PAN and, if present, any elements of sensitive authentication data. Other data that is sent in conjunction with the PAN are also considered account data such as, but not limited to, cardholder name, expiration date, and service code. What is the minimum that must be encrypted under SRED? A The following must be encrypted, if present:

a) Full Track or Equivalent (when aggregated as a single data element), including both Track 1 and Track 2.

b) Manually Entered Security Validation Value e(.g. CVV2, CVC2, and CID2),

c) Issuer Discretionary Data (as a single, unparsed field)

d) Issuer Discretionary Data

• Sensitive Data (as a parsed field). Any or all portions of the discretionary data are considered to be sensitive unless known to be non-sensitive

e) The PAN itself. If the PAN can be parsed, then the Sensitive PAN Middle digits (after the first six …

Modified p. 78 → 42

Q 2 June 2012: The guidance states that encrypting mode is defined to be when the device’s encryption of account data functionality is enabled and operational. Can a device output all or some account data in the clear when in encrypting mode? A Yes, even for devices that only support encrypting mode. For example, a device can implement cryptographically authenticated whitelists for outputting account data in the clear, ~~ever~~ if that whitelist causes all account data to be output in …

Q 1 June 2012: The guidance states that encrypting mode is defined to be when the device’s encryption of account data functionality is enabled and operational. Can a device output all or some account data in the clear when in encrypting mode? A Yes, even for devices that only support encrypting mode. For example, a device can implement cryptographically authenticated whitelists for outputting account data in the clear, even if that whitelist causes all account data to be output in …

Removed p. 79

POI Requirement K16.1

Q 1 October (update) 2016: If hash functions are used to generate surrogate PAN values, the input to the hash function must use a salt with a minimum length of 64-bits. Are salt values required to be unique per transaction? A The salt may be unique per transaction, unique per a group of transactions, unique per device or unique per merchant.

• Salts that are unique per transaction or otherwise unique per device must be generated by the transaction device.

• Salts that are unique per merchant are generated outside the transaction device and require loading to each merchant device. The vendor must supply documentation to the merchant/acquirer processor on how to securely load the salt values and that this loading is treated as a sensitive service in accordance with K22.

Document Comparison

Content Changes