Document Diff - PCI Watch

Added p. 9

Additional individual security requirements in POI v4 that were not previously evaluated shall still apply if applicable to the overall UPT evaluation. Furthermore, for devices that embed other PCI- approved devices and are therefore basing their security on these sub-components (even partially), the renewal/expiration date shall be the earliest to expire date among all evaluations, including the embedded device itself.

In addition, all wildcard options, both security and non-security relevant, must be clearly defined and documented as to the options available and their function in both the evaluation report and in the security policy.

Added p. 15

• It cannot adversely affect the security features of the product that are relevant to the PCI POI approval.

• It cannot modify any of the cryptographic functionality of the POI or introduce new primitive cryptographic functionality. However, new composite functionality that builds on existing primitives is permitted.

• The application is strongly authenticated to the POI secure controller by digital signature.

• The application can only work on the keys it alone manages and cannot affect or see any other keys.

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

Added p. 20

Q 67 April (update) 2016: 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 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.

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

• TLS_RSA_WITH_AES_128_CBC_SHA256

• TLS_RSA_WITH_AES_256_CBC_SHA256

• TLS_RSA_WITH_AES_128_CCM

• TLS_RSA_WITH_AES_256_CCM

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

• TLS_DHE_DSS_WITH_AES_128_CBC_SHA

• TLS_DHE_DSS_WITH_AES_256_CBC_SHA

• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

• TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

• TLS_DHE_DSS_WITH_AES_256_GCM_SHA384

• TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA

• TLS_DH_DSS_WITH_AES_128_CBC_SHA

• TLS_DH_DSS_WITH_AES_256_CBC_SHA

• TLS_DH_DSS_WITH_AES_128_CBC_SHA256

• TLS_DH_DSS_WITH_AES_256_CBC_SHA256

• TLS_DH_DSS_WITH_AES_128_GCM_SHA256

• TLS_DH_DSS_WITH_AES_256_GCM_SHA384

• TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA

• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384

• TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

Q 70 July 2015: Handheld PEDs that attach to a mobile phone, PDA or …

Added p. 23

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 October 2015: …

Added p. 29

Q 2 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 needs to be presented.

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 …

Added p. 38

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 included in the security policy for the device.

Added p. 41

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.

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.

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

Added p. 45

(continued on next page)

Added p. 54

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

Added p. 63

Q 1 May (update) 2017: This FAQ has been superseded.

The vendor may alternately provide user documentation detailing the management of cryptographic keys following these principles and implementing the use of a secure cryptographic device for management of these keys. The process exists upstream of the device, but the device must still provide enforcement•e.g., validate the MAC or digital signature.

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

Modified p. 1

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

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

Modified p. 2

PCI PTS POI Evaluation FAQs ~~•Technical~~

PCI PTS POI Evaluation FAQs

Removed p. 3

• In all cases, regardless of any prior work, the evaluating lab is responsible for performing the degree of work necessary to ensure the compliance of the device under evaluation to the Open Protocols requirements.

Q 3 If a device application includes prompts for non-PIN data and the device enforces

Modified p. 3

PCI Requirement ~~B16.2~~ 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.

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.

Modified p. 4 → 3

Q 4 When is an “N/A” response to a requirement acceptable? A An “N/A” response is acceptable in two cases: First, if compliance is achieved by meeting another requirement option, ~~such as meeting A1.~~ Second, if the characteristics governed by the requirement are absent in the ~~device, such as A5 if the device does not emit any audible tones.~~ The evaluation laboratory will verify that all responses are appropriate.

Q 3 September (update) 2015: When is an “N/A” response to a requirement acceptable? A An “N/A” response is acceptable in two cases: First, if compliance is achieved by meeting another requirement option, if one exists. Second, if the characteristics governed by the requirement are absent in the device. The evaluation laboratory will verify that all responses are appropriate.

Modified p. 4 → 3

Q 5 What is the definition of “Secret Information?” A “Secret information” is any cryptographic keys or passwords that the device relies on to maintain security characteristics governed by PCI requirements.

Q 4 What is the definition of “Secret Information?” A “Secret information” is any cryptographic keys or passwords that the device relies on to maintain security characteristics governed by PCI requirements.

Modified p. 4 → 3

Q 6 Some components of a device may include cryptographic keys that cannot be erased. Are there any instances when this would be acceptable? See Requirements A1 and ~~A7.~~ A Cryptographic keys that are never used to encrypt or decrypt data; or are not used for authentication, do not need to be considered secret data, and therefore do not need to be erased.

Q 5 Some components of a device may include cryptographic keys that cannot be erased. Are there any instances when this would be acceptable? See Requirements A1 and A6. A Cryptographic keys that are never used to encrypt or decrypt data; or are not used for authentication, do not need to be considered secret data, and therefore do not need to be erased.

Modified p. 4

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

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

Modified p. 4

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

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.

Modified p. 4

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

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.

Modified p. 4

Q 10 What is a “Delta” A 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. Examples of deltas include:

• Revisions to existing firmware or hardware on existing approved devices to add or modify functionality

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. Examples of deltas include:

• Revisions to existing firmware or hardware on existing approved devices to add or modify functionality

Modified p. 5

Q 11 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 …

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 …

Modified p. 5

Q 12 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 …

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 …

Modified p. 5

Q 13 Is it acceptable to make changes to an approved device’s hardware or firmware and keep the existing version #s? A No. Any hardware changes to an approved device that has been deployed must result in a new hardware version #. Any firmware changes to an approved device must result in a new firmware version. As described in the PCI PTS Device Testing and Approval Program Guide, vendors may use a combination of fixed and variable alphanumeric characters in …

Q 12 Is it acceptable to make changes to an approved device’s hardware or firmware and keep the existing version #s? A No. Any hardware changes to an approved device that has been deployed must result in a new hardware version #. Any firmware changes to an approved device must result in a new firmware version. As described in the PCI PTS Device Testing and Approval Program Guide, vendors may use a combination of fixed and variable alphanumeric characters in …

Modified p. 5

Q 14 Does the entry of the authentication code (password or PIN) 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 (password or PIN) 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 …

Q 13 Does the entry of the authentication code (password or PIN) 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 (password or PIN) 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 …

Modified p. 6

Q 15 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. …

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

Modified p. 6

Q 16 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 …

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 …

Modified p. 6

Q 17 The DTRs indicate that software developed to enable an attack can be considered bespoke equipment (Appendix B, under "Equipment"). Does this mean that PIN-disclosing bug software should be considered bespoke equipment? A Software required for a PIN-disclosing bug is typically straightforward to implement and would not be considered bespoke. Bespoke software would be software that requires significant time and expertise to develop such as is required for side channel attacks. PCI requires strong justification to be provided when …

Q 16 The DTRs indicate that software developed to enable an attack can be considered bespoke equipment (Appendix B, under "Equipment"). Does this mean that PIN-disclosing bug software should be considered bespoke equipment? A Software required for a PIN-disclosing bug is typically straightforward to implement and would not be considered bespoke. Bespoke software would be software that requires significant time and expertise to develop such as is required for side channel attacks. PCI requires strong justification to be provided when …

Modified p. 6

Q 18 How do the point calculations take into account the development of a PIN-disclosing bug?

Q 17 How do the point calculations take into account the development of a PIN-disclosing bug?

Modified p. 6

Q 19 When can multiple devices be costed in the calculation to support the compliance of a device to those requirements that have a minimum attack potential? A The requirement for multiple devices during either the identification or the exploitation phase of an attack value calculation depends upon the difficulty of attacking a device, and the risk that the device may be tampered during the attack. However, PCI expects that most attacks can be performed with only one or two …

Q 18 When can multiple devices be costed in the calculation to support the compliance of a device to those requirements that have a minimum attack potential? A The requirement for multiple devices during either the identification or the exploitation phase of an attack value calculation depends upon the difficulty of attacking a device, and the risk that the device may be tampered during the attack. However, PCI expects that most attacks can be performed with only one or two …

Modified p. 7

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

Modified p. 7

Q 21 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 …

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 …

Modified p. 7

Q 22 If a device is submitted for evaluation of offline PIN entry, is it acceptable for the device to only support plain-text PIN or to only support enciphered PIN? A No. In order to receive an approval for offline PIN entry, a device must be capable of supporting both ~~plain-text~~ and enciphered PIN.

Q 21 If a device is submitted for evaluation of offline PIN entry, is it acceptable for the device to only support plain-text PIN or to only support enciphered PIN? A No. In order to receive an approval for offline PIN entry, a device must be capable of supporting both plaintext and enciphered PIN.

Modified p. 7

Q 23 Several requirements, such as those for access to sensitive services, key loading, and removal detection, provide for the use of authentication using passwords or PINs. Are there any restrictions on this type of authentication data? A Yes, any passwords, PINs, or similar used to meet a PCI requirement must be at least a ~~five-~~ character minimum. These passwords/PINs must either be unique per device (and per user where dual control is required) except by chance, or if vendor …

Q 22 June (update) 2015: Several requirements, such as those for access to sensitive services, key loading, and removal detection, provide for the use of authentication using passwords or PINs. Are there any restrictions on this type of authentication data? A Yes, any passwords, PINs, or similar used to meet a PCI requirement must be at least a seven- character minimum. These passwords/PINs must either be unique per device (and per user where dual control is required) except by chance, …

Modified p. 7

Q ~~24 April~~ (update) ~~2021:~~ This FAQ has been superseded.

Q 23 November (update) 2020: This FAQ has been superseded.

Modified p. 7

Q 25 In occurrences where it is necessary to return a device to the device vendor for maintenance, are there any restrictions on what must happen to the secret keys in the device? A When a device is returned to the vendor for maintenance, mechanisms must be in place to automatically cause the erasure of all previously loaded acquirer secret keys upon servicing the device•e.g., loading a new public RSA key causes the erasure of all previously loaded secret keys.

Q 24 In occurrences where it is necessary to return a device to the device vendor for maintenance, are there any restrictions on what must happen to the secret keys in the device? A When a device is returned to the vendor for maintenance, mechanisms must be in place to automatically cause the erasure of all previously loaded acquirer secret keys upon servicing the device•e.g., loading a new public RSA key causes the erasure of all previously loaded secret keys.

Modified p. 8

Q 26 Security requirements are normally available for a four-year period from date of publication for new evaluations of products. Products are approved until six years after the retirement/expiration of the version of security requirements against which they were approved. This results in approvals that are a minimum of six years and a maximum of ten years, depending on the timeframe in which the approval occurs in relation to the life cycle of the applicable security requirements. Modifications for approved …

Q 25 Security requirements are normally available for a four-year period from date of publication for new evaluations of products. Products are approved until six years after the retirement/expiration of the version of security requirements against which they were approved. This results in approvals that are a minimum of six years and a maximum of ten years, depending on the timeframe in which the approval occurs in relation to the life cycle of the applicable security requirements. Modifications for approved …

Modified p. 8

Q 27 Technical FAQs are updated on a regular basis, and add clarifications for the application of defined security requirements. Are new FAQs applicable to devices that are currently in evaluation? Furthermore, must FAQs that were not in existence at the time of the original evaluation be considered in subsequent delta evaluations? A Yes. Technical FAQs not only add clarifications to requirements in order to provide a consistent and level playing field in the applications of those requirements, but may …

Q 26 Technical FAQs are updated on a regular basis, and add clarifications for the application of defined security requirements. Are new FAQs applicable to devices that are currently in evaluation? Furthermore, must FAQs that were not in existence at the time of the original evaluation be considered in subsequent delta evaluations? A Yes. Technical FAQs not only add clarifications to requirements in order to provide a consistent and level playing field in the applications of those requirements, but may …

Modified p. 8

The intent is not to cause a device in evaluation to fail if otherwise it would not unless known exploitations exist. Unless such an exploitation exists, a product currently in evaluation will generally not be subject to new FAQs issued during the product’s evaluation. This does not exempt a product from the applicability of the FAQ if the product must be reworked and resubmitted at a later date because of other issues that cause it to fail the evaluation.

The intent is not to cause a device in evaluation to fail if otherwise it would not unless known exploitations exist. Unless such an exploitation exists, a product currently in evaluation will generally not be subject to new FAQs issued during the product’s evaluation. This does not exempt a product from the applicability of the FAQ if the product must be reworked and resubmitted at a later date because of other issues that cause it to fail the evaluation. ) …

Modified p. 9

Q 28 Compound devices, such as unattended payment terminals, may be evaluated as part of a single evaluation of all applicable components, or may be evaluated with one or more previously approved OEM components. Where a compound device incorporates previously approved components, what considerations must be made for the evaluation? A There are several considerations:

Q 27 Compound devices, such as unattended payment terminals, may be evaluated as part of a single evaluation of all applicable components, or may be evaluated with one or more previously approved OEM components. Where a compound device incorporates previously approved components, what considerations must be made for the evaluation? A There are several considerations:

Modified p. 9

Q 29 Are OEM components, such as EPPs, approved against an earlier version of security requirements allowed for use in achieving an overall UPT approval without additional testing of requirements that were already evaluated, even if those requirements were updated as part of the POI v3 Security Requirements? A OEM components approved against earlier security requirements are only allowed for use in obtaining an overall UPT approval evaluation without additional testing of those components if they are no more than …

Q 28 Are OEM components, such as EPPs, approved against an earlier version of security requirements allowed for use in achieving an overall UPT approval without additional testing of requirements that were already evaluated, even if those requirements were updated as part of the POI v4 Security Requirements? A OEM components approved against earlier security requirements are only allowed for use in obtaining an overall UPT approval evaluation without additional testing of those components if they are no more than …

Modified p. 10

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

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 …

Modified p. 10

Q 32 The program manual states that hardware and firmware version number identifiers may consist of a combination of fixed and variable alphanumeric characters, whereby a lowercase "x" is used by PCI to designate all variable fields. The "x" represents fields that the vendor can change at any time to denote a different device configuration. Examples include: country usage code, customer code, communication interface, device color, etc. What are examples of options that cannot be addressed by use of a …

Q 31 September (update) 2016: The program manual states that hardware and firmware version number identifiers may consist of a combination of fixed and variable alphanumeric characters, whereby a lowercase "x" is used by PCI to designate all variable fields. The "x" represents fields that the vendor can change at any time to denote a different device configuration. Examples include: country usage code, customer code, communication interface, device color, etc. What are examples of options that cannot be addressed by …

Modified p. 11

Q 33 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. …

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

Modified p. 11

2. All such requests must be received by PCI SSC as a delta letter from one of the PCI SSC PTS recognized laboratories. If the only change is to the nameplate of the product, there is not any new evaluation ~~fee (currently $2,500),~~ but as noted above, there will be an annual listing ~~fee (currently $1,250).~~

2. All such requests must be received by PCI SSC as a delta letter from one of the PCI SSC PTS recognized laboratories. If the only change is to the nameplate of the product, there is not any new evaluation fee, but as noted above, there will be an annual listing fee.

Modified p. 11

Q 34 May 2011: For attack potential calculations, information is classified as Public, Restricted or Sensitive. What are examples of each? Information is considered Public if it can be easily obtained from the Internet or is provided without any control mechanisms. Examples include open protocol specifications and electronic component datasheets. Information with automated access controls mechanisms (such as online account subscription) without human intervention classifies as Public. Restricted information is distributed upon request and is subject to human-based control mechanisms. …

Q 33 May 2011: For attack potential calculations, information is classified as Public, Restricted or Sensitive. What are examples of each? A Information is considered Public if it can be easily obtained from the Internet or is provided without any control mechanisms. Examples include open protocol specifications and electronic component datasheets. Information with automated access controls mechanisms (such as online account subscription) without human intervention classifies as Public. Restricted information is distributed upon request and is subject to human-based control …

Modified p. 12

Q 35 May 2011: For attack-potential calculations, if the same equipment used for the identification phase can be reused for exploitation, the equipment cannot be accounted for twice, but instead must be divided by two and spread equally over the two phases. Does a similar rational apply where parts are reused? No. While equipment readily lends itself to reuse for each exploitation, parts are typically a one- time use for each exploitation. Each exploitation should have the same attack potential …

Q 34 May 2011: For attack-potential calculations, if the same equipment used for the identification phase can be reused for exploitation, the equipment cannot be accounted for twice, but instead must be divided by two and spread equally over the two phases. Does a similar rational apply where parts are reused? A No. While equipment readily lends itself to reuse for each exploitation, parts are typically a one- time use for each exploitation. Each exploitation should have the same attack …

Modified p. 12

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

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

Modified p. 13

Q 37 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 …

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 …

Modified p. 13 → 14

Q 38 March (update) 2015: 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.

Q 37 March (update) 2015: 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.

Modified p. 14

Q 39 December 2011: Specific requirements are identified in the Core and SRED modules that Secure Card Readers must be validated against. Are there any other requirements that must be considered? A Yes, all of the non-designated SRED requirements should be considered for applicability. In most cases they will not be applicable and will not require any assessment beyond that determination.

Q 38 December 2011: Specific requirements are identified in the Core and SRED modules that Secure Card Readers must be validated against. Are there any other requirements that must be considered? A Yes, all of the non-designated SRED requirements should be considered for applicability. In most cases they will not be applicable and will not require any assessment beyond that determination.

Modified p. 14

Q 40 June 2012: If a device supports multiple IP enabled interfaces, does testing need to be performed on all IP enabled interfaces by the laboratory during the evaluation? A If a device supports multiple IP enabled interfaces and the IP stack (including all IP Protocols, IP Services and IP Security Protocols) are identical for all interfaces, testing is only required to be performed on one of the IP enabled interfaces.

Q 39 June 2012: If a device supports multiple IP enabled interfaces, does testing need to be performed on all IP enabled interfaces by the laboratory during the evaluation? A If a device supports multiple IP enabled interfaces and the IP stack (including all IP Protocols, IP Services and IP Security Protocols) are identical for all interfaces, testing is only required to be performed on one of the IP enabled interfaces.

Modified p. 14 → 15

Q 41 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 ~~Protocol~~ 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 …

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 …

Modified p. 14 → 15

Q 42 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 …

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

Modified p. 15

Q 43 September 2012: Vendors may provide application toolkits for third parties to develop applications that cannot impact any of the functionality needed to comply with PCI requirements. The exceptions to this are for alteration of display prompts by third parties and for SRED applications developed by third parties, subject to controls stipulated in the PTS POI Derived Test Requirements and these FAQs. Can a vendor provide a toolkit that allows third parties to implement applications that supplant the cryptographic …

Q 42 September 2012: Vendors may provide application toolkits for third parties to develop applications that cannot impact any of the functionality needed to comply with PCI requirements. The exceptions to this are for alteration of display prompts by third parties and for SRED applications developed by third parties, subject to controls stipulated in the PTS POI Derived Test Requirements and these FAQs. Can a vendor provide a toolkit that allows third parties to implement applications that supplant the cryptographic …

Modified p. 15 → 16

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 algorithms used to provide security to any confidential data, including data transmitted using open protocols, is specified in DTR B11. Only TDES, RSA, ECC, DSA, and AES are acceptable for encryption or signing operations. SHA256 or above may also be used for hashing ~~purposes~~

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 algorithms used to provide security to any confidential data, including data transmitted using open protocols, is specified in DTR B11. Only TDES, RSA, ECC, DSA, and AES are acceptable for encryption or signing operations. SHA256 or above may also be used for hashing purposes.

Modified p. 16

Q 46 November 2012: What communication methods should be assessed with the Open Protocols Module? A Any communication method that uses a wireless, local, or wide area network to transport data. This includes, but is not limited to: Bluetooth, ~~WI-Fi,~~ Cellular (GPRS, CDMA), or Ethernet. A serial ~~point to point~~ connection would not need to be assessed unless that connection is wireless or through a hub, switch or other multiport device. In addition, any communication that uses a public domain …

Q 46 November 2012: What communication methods should be assessed with the Open Protocols Module? A Any communication method that uses a wireless, local, or wide area network to transport data. This includes, but is not limited to: Bluetooth, Wi-Fi, Cellular (GPRS, CDMA), or Ethernet. A serial point-to-point connection would not need to be assessed unless that connection is wireless or through a hub, switch or other multiport device. In addition, any communication that uses a public domain protocol or …

Modified p. 16

Q 48 July (update) 2014: What requirements must a Secure Card Reader be validated against? A SCRs must meet as applicable the ICCR and/or MSR requirements designated in Appendix B of the PCI PTS POI Security Requirements and the Secure Reading and Exchange of Data ~~Module.~~ If the device is capable of communicating over an IP network or uses a public domain protocol (such as but not limited to Wi-Fi or Bluetooth), then requirements specified in the Open Protocols Module …

Q 48 July (update) 2014: What requirements must a Secure Card Reader be validated against? A SCRs must meet as applicable the ICCR and/or MSR requirements designated in Appendix B of the PCI PTS POI Security Requirements and the Secure Reading and Exchange of Data Module and additionally must meet B20, security policy. If the device is capable of communicating over an IP network or uses a public domain protocol (such as but not limited to Wi-Fi or Bluetooth), then …

Modified p. 16 → 17

Q 49 ~~April 2013:~~ 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. …

PCI PTS POI Evaluation FAQs 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. …

Modified p. 17

Q 52 July 2013: Devices are not required to support SRED, but if they do, they must be validated to SRED. If a device does encryption to protect account data but the vendor will not claim SRED, is SRED a required module? A There are several scenarios where SRED is mandatory. Those scenarios include any device validated to the Non-PED or SCR approval classes, or in some handheld scenarios involving a PIN entry devices attached (e.g., via a sled, sleeve …

Modified p. 18 → 19

Q 60 February 2014: Can a device meet the PTS POI requirements without having an active tamper response mechanism to zeroize secret and private keys during a penetration attack? Regardless of which modules of the PTS POI standard the device is designed to comply with, penetration of the device must cause the automatic and immediate erasure of any secret and private keys such that it becomes infeasible to recover the keying material. ~~If any such keys are not zeroized then …~~

Q 60 February 2014: Can a device meet the PTS POI requirements without having an active tamper response mechanism to zeroize secret and private keys during a penetration attack? A No. Regardless of which modules of the PTS POI standard the device is designed to comply with, penetration of the device must cause the automatic and immediate erasure of any secret and private keys such that it becomes infeasible to recover the keying material. This is true of devices even …

Modified p. 19

Q 63 February 2014: If a SCR processes PINs, i.e., it supports offline PIN authentication via an ICCR component, or it formats and encrypts a PIN block to send online directly to the host, does it have to be evaluated with a specific PIN entry device? Yes it must be validated in conjunction with a specific PIN entry device, e.g., PED or EPP, to validate the security of the interaction, including the establishment of the keying relationship. The PIN entry …

Q 63 February 2014: If a SCR processes PINs, i.e., it supports offline PIN authentication via an ICCR component, or it formats and encrypts a PIN block to send online directly to the host, does it have to be evaluated with a specific PIN entry device? A Yes it must be validated in conjunction with a specific PIN entry device, e.g., PED or EPP, to validate the security of the interaction, including the establishment of the keying relationship. The PIN …

Removed p. 20

A BLE implementations must use version 4.2 or higher. BLE must use LE Security Mode 1 Level 3 or 4 only. The vendor must provide user documentation that unsecure communication options such as, but not limited to security mode 2, and Levels 1 and 2 of security mode 1 cannot be used.

Modified p. 20

Q 66 January 2015: Does the use of a protective case impact the approval status of a device? A Yes. In general, cases are not supported by the device approval program due to the potential for hiding tamper evidence. Cases may be used where they do not cover any portion of the MSR or ICCR area. For example, a case used to protect a drop of a mobile device or the addition of a lanyard may not cover the ICCR …

Modified p. 20 → 21

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

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 …

Modified p. 21

• ~~TLS_ECHDE_RSA_WITH_AES_128_GCM_SHA256~~

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Modified p. 21 → 22

• ~~TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384~~ For SSL 3, or older versions of TLS, if supported, all cipher suites using single DES or RC4 must be removed. This 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 approved firmware.

• TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 For SSL 3, or older versions of TLS, if supported, all cipher suites using single DES or RC4 must be removed. This 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 approved firmware.

Modified p. 21 → 25

Q 70 April 2021: Removal detection requirements were eliminated in POI v6. Are these requirements now eliminated for v3, v4 and v5 devices? A Yes. All aspects of requirements on anti-removal mechanisms eliminated in POI v6 become optional for v3/v4/v5 devices. If applied as changes to approved v3/v4/v5 devices, they shall be assessed in a delta evaluation, in which the relevant hardware and firmware identifiers are updated. Although no longer mandatory in v6, for new devices optionally implementing protections satisfying …

Q 82 April (update) 2021: Removal detection requirements were eliminated in POI v6. Are these requirements now eliminated for v3, v4 and v5 devices? A Yes. All aspects of requirements on anti-removal mechanisms eliminated in POI v6 become optional for v3/v4/v5 devices. If applied as changes to approved v3/v4/v5 devices, they shall be assessed in a delta evaluation, in which the relevant hardware and firmware identifiers are updated. Although no longer mandatory in v6, for new devices optionally implementing protections …

Modified p. 22 → 26

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

Modified p. 22 → 26

Q 72 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 …

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 …

Modified p. 22 → 26

Q 73 Requirements A1 and D1 specify minimum attack potentials of 26 for the device and 20 for the ICC reader for penetration attacks designed to determine or modify sensitive data. In Version 1 requirements, alternative options included meeting a minimum of ten hours of exploitation time. Does exploitation time enter into either of these two requirements? A Yes. In addition to the specified minimum attack potential values, any feasible penetration attack against either device for the purpose of determining …

Q 3 Requirements A1 and D1 specify minimum attack potentials of 26 for the device and 20 for the ICC reader for penetration attacks designed to determine or modify sensitive data. In Version 1 requirements, alternative options included meeting a minimum of ten hours of exploitation time. Does exploitation time enter into either of these two requirements? A Yes. In addition to the specified minimum attack potential values, any feasible penetration attack against either device for the purpose of determining …

Modified p. 22 → 26

Q 74 Are there circumstances under which a device can comply with Requirement A1 while employing one tamper switch to protect the keypad area? A No. If switches are used as the primary protection for the area around a physical keypad area, then at least three blind, tamper switches must be implemented. The switches must be protected from attacks that use the application of adhesives or conductive liquids to disable the switches. The design must ensure that a minimum of …

Q 4 Are there circumstances under which a device can comply with Requirement A1 while employing one tamper switch to protect the keypad area? A No. If switches are used as the primary protection for the area around a physical keypad area, then at least three blind, tamper switches must be implemented. The switches must be protected from attacks that use the application of adhesives or conductive liquids to disable the switches. The design must ensure that a minimum of …

Modified p. 22 → 27

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

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.

Modified p. 22 → 27

The API for firmware and applications (if applicable) needs to be looked at carefully to determine the conditions under which plain-text data entry is allowed. Example: it should not be possible unless under acquirer display prompt controlled devices, for a third party to display an image (JPEG) that states “press enter when ready for PIN entry” and then have a plain-text keypad pop up on the next screen. The extra caution is warranted for touch screen devices because of the …

Modified p. 23 → 27

Q 76 In the attack-potential calculation for A1, is it allowed to include in the point calculation a value for disabling the removal detection mechanism of an EPP or OEM PED intended for use in an unattended environment? A If attack scenarios in A1 do not necessarily require the removal of the device out of its location (e.g., the attack could take place at a time before field placement), the cost for disabling the removal sensor should not be included …

Q 6 In the attack-potential calculation for A1, is it allowed to include in the point calculation a value for disabling the removal detection mechanism of an EPP or OEM PED intended for use in an unattended environment? A If attack scenarios in A1 do not necessarily require the removal of the device out of its location (e.g., the attack could take place at a time before field placement), the cost for disabling the removal sensor should not be included …

Modified p. 23 → 27

Q 77 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 disable …

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

Modified p. 23 → 28

Q 78 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 …

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 …

Modified p. 23 → 28

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

Modified p. 24 → 28

Q 80 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.1?~~ 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 phase of the attack for Requirement ~~A1.1.~~ …

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 phase of the attack for Requirement A1. …

Modified p. 24 → 28

Q 81 March 2011: What level of expertise should be accounted for in the installation and testing of a PIN bug during the exploitation phase of the attack calculation for Requirement ~~A1.1?~~ A In most cases, only a Layman or Proficient level of expertise should be used for the installation and testing of a PIN bug during exploitation. It is expected that, during the identification phase, an attacker would develop a script executable by a Layman or Proficient person during …

Q 11 March 2011: What level of expertise should be accounted for in the installation and testing of a PIN bug during the exploitation phase of the attack calculation for Requirement A1? A In most cases, only a Layman or Proficient level of expertise should be used for the installation and testing of a PIN bug during exploitation. It is expected that, during the identification phase, an attacker would develop a script executable by a Layman or Proficient person during …

Modified p. 24 → 28

Q 82 March 2011: Should the Identification phase include a complete dry run for the installation and testing of a PIN bug, or can some of the final steps be deferred until the Exploitation phase? A In general the Identification phase should include a full dry run for the installation and testing of a PIN bug resulting in a complete script to be followed in the Exploitation phase. In rare instances, additional steps may be required in the Exploitation phase …

Q 12 March 2011: Should the Identification phase include a complete dry run for the installation and testing of a PIN bug, or can some of the final steps be deferred until the Exploitation phase? A In general the Identification phase should include a full dry run for the installation and testing of a PIN bug resulting in a complete script to be followed in the Exploitation phase. In rare instances, additional steps may be required in the Exploitation phase …

Modified p. 24 → 29

Q 83 April 2013: 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 …

Q 13 April 2013: 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 …

Modified p. 24 → 29

Q 84 Is A4 intended to address the ICC reader security? A No. A4 does not apply to the ICC reader. The security of the ICC reader and the path from the reader to the crypto-processor are addressed by D1, D2, and D3.

Q 1 Is A4 intended to address the ICC reader security? A No. A4 does not apply to the ICC reader. The security of the ICC reader and the path from the reader to the crypto-processor are addressed by D1, D2, and D3.

Modified p. 25 → 29

Q 85 What standards and methods are used for measuring “electro-magnetic emissions”? A Vendors should take into account that EM emissions can be a risk to PIN data, and should design to address this risk. There are many methods for shielding and minimizing EM emissions. The vendor must describe to the laboratory in writing how EM emissions are addressed by the device design. The laboratory will examine evidence provided by the vendor to determine if the evidence supports the vendor’s …

Q 1 What standards and methods are used for measuring “electro-magnetic emissions”? A Vendors should take into account that EM emissions can be a risk to PIN data, and should design to address this risk. There are many methods for shielding and minimizing EM emissions. The vendor must describe to the laboratory in writing how EM emissions are addressed by the device design. The laboratory will examine evidence provided by the vendor to determine if the evidence supports the vendor’s …

Modified p. 25 → 30

POI Requirements ~~A8,~~ B16 and E3.4

POI Requirements A7, B16 and E3.4

Modified p. 25 → 30

Q 87 Does “non-PIN data” include data that can be entered while the device is in a maintenance mode? A No. ~~A8,~~ B16, and E3.4 are applicable to the device while in its normal working mode. ~~A8,~~ B16, or E3.4 does not apply to data entered while the device is in special modes that are not intended to be accessed by cardholders and merchants.

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

Modified p. 25 → 30

Q 88 Does “non-PIN data” include control inputs such as “enter,” “cancel,” etc.? A No. Non-PIN data refers to numeric data entered via the keypad.

Q 2 Does “non-PIN data” include control inputs such as “enter,” “cancel,” etc.? A No. Non-PIN data refers to numeric data entered via the keypad.

Modified p. 25 → 30

Q 89 The intent of ~~A8,~~ 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 ~~A8,~~ 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 …

Q 3 The intent of A7, 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 A7, 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 …

Modified p. 25 → 30

Q 90 What restrictions exist if a device can display uncontrolled messages and the keypad is used to enter non-PIN data? A The prompts for non-PIN data entry must be under the control of the cryptographic unit and must be specific such that a cardholder would not enter a PIN at an inappropriate time. An uncontrolled message followed by an ambiguous prompt for non-PIN data could lead to a cardholder entering their PIN at an inappropriate time. For example, if …

Q 4 What restrictions exist if a device can display uncontrolled messages and the keypad is used to enter non-PIN data? A The prompts for non-PIN data entry must be under the control of the cryptographic unit and must be specific such that a cardholder would not enter a PIN at an inappropriate time. An uncontrolled message followed by an ambiguous prompt for non-PIN data could lead to a cardholder entering their PIN at an inappropriate time. For example, if …

Removed p. 26

Q 91 Touch-screen 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.

Q 92 The vendor chooses to comply with Requirement A8, B16, or E3.4. All of these govern the alteration of prompts and specify an attack potential of at least 18. What criteria should a vendor use to determine which one to comply with? A Statements A8 and B16.1 are intended to be met by the vendor controlling the means of authorizing prompt changes. B16.1 should be complied with for devices that allow prompts to be changed as part of firmware updates. A8 should be …

Modified p. 26 → 31

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

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.

Modified p. 26 → 31

Q 94 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).

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

Removed p. 27

Q 96 May 2011: If a device complies with B16.1, what are the requirements for controlling the updates of these prompts? A B16.1 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.1 requires the creation of a new firmware version, and a resultant change in the firmware version number of the PED.

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 non-firmware code, …

Modified p. 27 → 31

Q 95 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 …

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 …

Modified p. 28 → 32

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

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.

Modified p. 28 → 32

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

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

Modified p. 28 → 33

Q ~~101~~ 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.

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.

Modified p. 28 → 33

Q ~~102~~ When a device is not a handheld device, it must have a privacy shield to meet ~~A9.~~ 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.

Q 2 When a device is not a handheld device, it must have a privacy shield to meet A8. 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.

Modified p. 28 → 33

Q ~~103~~ 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 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.

Modified p. 28 → 33

Q ~~104~~ Requirement A9 stipulates that the device must provide a means to deter the visual observation of PIN values as they are being entered by the cardholder. What methods are acceptable? A The POI Security Requirements provide for several options that may be used separately or in combination to provide privacy during PIN entry. These options are:

Q 4 Requirement A8 stipulates that the device must provide a means to deter the visual observation of PIN values as they are being entered by the cardholder. What methods are acceptable? A The POI Security Requirements provide for several options that may be used separately or in combination to provide privacy during PIN entry. These options are:

Modified p. 29 → 33

Q ~~105~~ 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 that …

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 …

Modified p. 29 → 34

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

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 …

Modified p. 29 → 34

Q ~~107~~ Requirement ~~A11~~ 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 No. The 18-point requirement for the removal of a secure component (e.g., EPP) includes all stages of identification and exploitation up to the point that the secure component is removed from its installed environment. No …

Q 1 Requirement A10 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 No. The 18-point requirement for the removal of a secure component (e.g., EPP) includes all stages of identification and exploitation up to the point that the secure component is removed from its installed environment. No …

Modified p. 29 → 35

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

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 …

Modified p. 30 → 35

Q ~~109~~ December 2011: Secure components intended for use in unattended devices must contain an anti-removal mechanism to protect against unauthorized removal and/or unauthorized re-installation. The installation or removal of the device requires an authorized process using dual control techniques. One mechanism for doing so involves the use of passwords. Can a device have a function (e.g., a specified key-press sequence) to reset the passwords to their default values if the reset zeroizes all the secret keys and new passwords …

Q 3 December 2011: Secure components intended for use in unattended devices must contain an anti-removal mechanism to protect against unauthorized removal and/or unauthorized re-installation. The installation or removal of the device requires an authorized process using dual control techniques. One mechanism for doing so involves the use of passwords. Can a device have a function (e.g., a specified key-press sequence) to reset the passwords to their default values if the reset zeroizes all the secret keys and new passwords …

Modified p. 30 → 35

Q ~~110~~ December 2011: In connection with removal detection and authorized installation/re- installation, accountability and traceability must exist, including logging of user IDs, date and time stamps, and action performed. What are acceptable locations for the logging to reside at? A It may be logged at the device’s (e.g., ATM) host, or it may be logged directly by the device (i.e., EPP or OEM PED), and either stored by the device where feasible, or externally by the host’s controller.

Q 4 December 2011: In connection with removal detection and authorized installation/re- installation, accountability and traceability must exist, including logging of user IDs, date and time stamps, and action performed. What are acceptable locations for the logging to reside at? A It may be logged at the device’s (e.g., ATM) host, or it may be logged directly by the device (i.e., EPP or OEM PED), and either stored by the device where feasible, or externally by the host’s controller.

Modified p. 30 → 36

Q ~~111~~ December 2011: Dual control is required for removal detection and authorized installation/re-installation. Can the same dual-control that is used to authorize the device’s removal also be used to authorize the re-installation? A The vendor may not necessarily require both options. Possible scenarios include:

Q 5 December 2011: Dual control is required for removal detection and authorized installation/re-installation. Can the same dual-control that is used to authorize the device’s removal also be used to authorize the re-installation? A The vendor may not necessarily require both options. Possible scenarios include:

Modified p. 30 → 36

Q ~~112~~ December 2011: For a removal then re-installation, if communication to the device is not possible before the removal but only after the re-installation, what are the requirements? A The device can either:

Q 6 December 2011: For a removal then re-installation, if communication to the device is not possible before the removal but only after the re-installation, what are the requirements? A The device can either:

Modified p. 30 → 36

Q ~~113~~ December 2011: Under what conditions can a device that does not undergo an authorized removal process be re-installed? A The device can either:

Q 7 December 2011: Under what conditions can a device that does not undergo an authorized removal process be re-installed? A The device can either:

Modified p. 31 → 36

Q ~~114~~ September 2012: Some implementations of ICCRs are not intended to support offline PIN acceptance. In those circumstances, can an ICCR be approved if it is not validated as compliant to the removal detection requirement? A No. Support for offline PIN acceptance can readily be modified by a firmware change without physically having to touch the device. However, for deployed devices it is unlikely that an ICCR without removal detection would be physically replaced in the field due to …

Q 8 September 2012: Some implementations of ICCRs are not intended to support offline PIN acceptance. In those circumstances, can an ICCR be approved if it is not validated as compliant to the removal detection requirement? A No. Support for offline PIN acceptance can readily be modified by a firmware change without physically having to touch the device. However, for deployed devices it is unlikely that an ICCR without removal detection would be physically replaced in the field due to …

Modified p. 31 → 37

Q ~~115~~ What is required to meet B1? A The device must perform an internal self-test automatically at least once every day, in addition to at power-up. Firmware integrity tests may use techniques such as SHA-2 or equivalent. Authenticity testing must use cryptographic methods (MACs, digital signature or encryption). The hash must either be cryptographically protected using a key (e.g., HMAC-SHA-2) or physically protected equivalent to a secret key. LRC, CRC and other non-cryptographic methods and weak cryptographic methods (e.g., …

Q 1 What is required to meet B1? A The device must perform an internal self-test automatically at least once every day, in addition to at power-up. Firmware integrity tests may use techniques such as SHA-2 or equivalent. Authenticity testing must use cryptographic methods (MACs, digital signature or encryption). The hash must either be cryptographically protected using a key (e.g., HMAC-SHA-2) or physically protected equivalent to a secret key. LRC, CRC and other non-cryptographic methods and weak cryptographic methods (e.g., …

Modified p. 31 → 37

Q ~~116~~ Is it acceptable to perform firmware integrity checks before each PIN transaction instead of once daily? A Yes. It is acceptable to perform firmware integrity checks before each PIN transaction as opposed to performing them at least once every 24 hours.

Q 2 Is it acceptable to perform firmware integrity checks before each PIN transaction instead of once daily? A Yes. It is acceptable to perform firmware integrity checks before each PIN transaction as opposed to performing them at least once every 24 hours.

Modified p. 31 → 37

Q ~~117~~ Is it acceptable to perform a self-test after several minutes of inactivity rather than once every 24 hours? A Yes, as long as it is 24 hours or less. Note that the power-up self-tests are still required.

Q 3 Is it acceptable to perform a self-test after several minutes of inactivity rather than once every 24 hours? A Yes, as long as it is 24 hours or less. Note that the power-up self-tests are still required.

Modified p. 31 → 37

Q ~~118~~ B1 requires that firmware integrity be tested every 24 hours. Some firmware, such as a boot block, is rarely executed. For such firmware, is it acceptable to perform an integrity check prior to execution, rather than every 24 hours? A Yes, it is acceptable to test firmware immediately prior to each execution rather than once every 24 hours. However, note that all firmware must additionally be checked as part of the ~~self-test~~ performed at startup.

Q 4 B1 requires that firmware integrity and authenticity be tested every 24 hours. Some firmware, such as a boot block, is rarely executed. For such firmware, is it acceptable to perform an integrity and authenticity check prior to execution, rather than every 24 hours? A Yes, it is acceptable to test such firmware immediately prior to each execution rather than once every 24 hours. However, note that all firmware must additionally be checked as part of the self- test …

Modified p. 31 → 37

Q ~~119~~ Requirement B1 states that a self-test must check for both integrity and authenticity of the installed firmware. Is it necessary to perform both checks separately? A No. The self-test required by B1 must perform an authenticity check, using cryptographic means such as a digital signature or a MAC. As such, an authenticity check will also confirm the integrity of the installed firmware, an additional integrity check is not necessary, but optionally may be additionally performed using a non-authenticated …

Q 5 Requirement B1 states that a self-test must check for both integrity and authenticity of the installed firmware. Is it necessary to perform both checks separately? A No. The self-test required by B1 must perform an authenticity check, using cryptographic means such as a digital signature or a MAC. As such, an authenticity check will also confirm the integrity of the installed firmware, an additional integrity check is not necessary, but optionally may be additionally performed using a non-authenticated …

Modified p. 31 → 37

Q ~~120~~ If a device employs firmware on the MSR’s read head to encrypt account data, is that firmware subject to authenticity checking as defined in Requirement B1? A No. Authenticity checking as defined in Requirement B1 is for the management of firmware that is directly or indirectly involved in the protection of cardholder PINs as defined in the various security requirements. However, the firmware on the read head must be designed such that it cannot be updated.

Q 6 If a device employs firmware on the MSR’s read head to encrypt account data, is that firmware subject to authenticity checking as defined in Requirement B1? A No. Authenticity checking as defined in Requirement B1 is for the management of firmware that is directly or indirectly involved in the protection of cardholder PINs as defined in the various security requirements. However, the firmware on the read head must be designed such that it cannot be updated.

Modified p. 32 → 38

Q ~~121~~ 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):

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):

Modified p. 32 → 38

• 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 A7 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. 32 → 38

Q ~~122~~ 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 device, does not need to be validated against Requirement B1. Examples may include smart card controllers, keypad ~~controllers~~ or modem firmware.

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.

Modified p. 32 → 39

Q ~~123~~ November 2012: What interfaces should be assessed under Requirement B2? A All interfaces and associated communication methods of the device must be assessed to ensure that no interface can be abused or used as an attack vector. Specifically, this includes any physical, logical, or application interface that is executed within the POI device with sufficient privilege to allow for direct interface to sensitive assets within the POI (should that protocol be compromised in some way). The interfaces must …

Q 1 November 2012: What interfaces should be assessed under Requirement B2? A All interfaces and associated communication methods of the device must be assessed to ensure that no interface can be abused or used as an attack vector. Specifically, this includes any physical, logical, or application interface that is executed within the POI device with sufficient privilege to allow for direct interface to sensitive assets within the POI (should that protocol be compromised in some way). The interfaces must …

Modified p. 32 → 39

Q ~~124~~ December ~~2012 (Mandatory April 2013):~~ 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:

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:

Modified p. 33 → 39

• 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 may be placed upon the evidence, and where necessary, the laboratory shall extend the testing.

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

Modified p. 33 → 39

Q ~~125~~ What is considered “firmware”? (OS, EPROM code, DLL’s, parameter files, applications, kernel code)? A Firmware is considered to be any code within the device that provides security protections needed to comply with PCI POI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI POI requirements.

Q 1 What is considered “firmware”? (OS, EPROM code, DLL’s, parameter files, applications, kernel code)? A Firmware is considered to be any code within the device that provides security protections needed to comply with PCI POI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI POI requirements.

Modified p. 33 → 39

Q ~~126~~ What methods are acceptable to “certify” firmware? A “Certify firmware” refers to self-certification. This requirement, in essence, requires the vendor to have implemented and to use internal quality control and change control systems. With these systems in place, the vendor is in control of the code and can attest to the fact that the code is free of hidden or unauthorized functions by answering yes to B3.

Q 2 What methods are acceptable to “certify” firmware? A “Certify firmware” refers to self-certification. This requirement, in essence, requires the vendor to have implemented and to use internal quality control and change control systems. With these systems in place, the vendor is in control of the code and can attest to the fact that the code is free of hidden or unauthorized functions by answering yes to B3.

Modified p. 33 → 40

Q ~~127~~ Many devices are designed so that third parties can create and load applications. Vendors often support this by providing third parties the tools needed to create and load applications. How can a vendor ensure that the application will not need to be controlled by the vendor? A If applications are not considered firmware, they do not need to be controlled by the vendor. The device design must prevent applications from impacting functions and features governed by the requirements. …

Q 3 Many devices are designed so that third parties can create and load applications. Vendors often support this by providing third parties the tools needed to create and load applications. How can a vendor ensure that the application will not need to be controlled by the vendor? A If applications are not considered firmware, they do not need to be controlled by the vendor. The device design must prevent applications from impacting functions and features governed by the requirements. …

Modified p. 33 → 40

Alteration of prompts by third parties is a special case that can be impacted by non-firmware applications provided that PCI POI ~~B16.2~~ is met.

Alteration of prompts by third parties is a special case that can be impacted by non-firmware applications provided that PCI POI B16 is met.

Modified p. 33 → 40

Q ~~128~~ What parties may possess keys used for the cryptographic authentication of firmware updates? A The firmware is the responsibility of the device vendor, and as such the cryptographic keys that authenticate it within the device must be held solely by the vendor or their designated agent.

Q 1 What parties may possess keys used for the cryptographic authentication of firmware updates? A The firmware is the responsibility of the device vendor, and as such the cryptographic keys that authenticate it within the device must be held solely by the vendor or their designated agent.

Modified p. 34 → 40

Q ~~129~~ Firmware updates must be cryptographically authenticated, and if the authentication fails, the update is rejected and deleted. Are there any circumstances where firmware can be updated without authentication? A Some chipsets are not designed for firmware updates, but only to support firmware replacement. The deletion of the existing firmware and cryptographic keys during the replacement does not allow for the authentication of the new firmware to occur.

Q 2 Firmware updates must be cryptographically authenticated, and if the authentication fails, the update is rejected and deleted. Are there any circumstances where firmware can be updated without authentication? A Some chipsets are not designed for firmware updates, but only to support firmware replacement. The deletion of the existing firmware and cryptographic keys during the replacement does not allow for the authentication of the new firmware to occur.

Modified p. 34 → 40

In such cases it is acceptable to update the firmware without authentication if the process requires that the device be returned to the vendor’s facilities and results in the secure zeroization of all secret and private keys contained within the device. Q ~~130~~ 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 …

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:

Modified p. 34 → 41

Q ~~131~~ 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 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=%.

Modified p. 34 → 41

Q ~~132~~ 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.

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. 34 → 42

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

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 …

Modified p. 34 → 42

An alternate method of meeting the requirement would be for the microprocessor to immediately encrypt the PIN before passing it to the secure processor, which would then decrypt it and create the encrypted PIN block. Note that in this type of design, the microprocessor software used to encrypt the PIN data is being used to meet PCI requirements. Therefore, this software must be

An alternate method of meeting the requirement would be for the microprocessor to immediately encrypt the PIN before passing it to the secure processor, which would then decrypt it and create the encrypted PIN block. Note that in this type of design, the microprocessor software used to encrypt the PIN data is being used to meet PCI requirements. Therefore, this software must be considered “firmware” as addressed by PCI requirements. As such Requirements B3 and B4 would apply to this …

Modified p. 35 → 42

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

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 …

Modified p. 35 → 42

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

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 …

Modified p. 35 → 42

Q ~~136~~ 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 PIN entry. In all cases, erasure of the plaintext PIN must occur before the tamper-detection mechanisms can be disabled using attack methods described in A1. Are there any circumstances where a plaintext PIN can exist for more than one minute? A …

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 PIN entry. In all cases, erasure of the plaintext PIN must occur before the tamper-detection mechanisms can be disabled using attack methods described in A1. Are there any circumstances where a plaintext PIN can exist for more than one minute? A …

Modified p. 36 → 43

Q ~~137~~ 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 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.

Modified p. 36 → 43

Q ~~138~~ 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 a special maintenance …

Q 2 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 a special maintenance …

Modified p. 36 → 43

Q ~~139~~ 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.

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.

Modified p. 36 → 43

Q ~~140~~ 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.

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.

Modified p. 36 → 43

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

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 …

Modified p. 36 → 43

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

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 …

Removed p. 37

POI Requirements B7, B11, K18

Modified p. 37 → 44

Q ~~143 December 2013:~~ 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 …

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 …

Modified p. 37 → 45

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

Q 1 June (update) 2015: 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 …

Modified p. 37 → 45

2) For injecting plain-text secret or private keys from a key loader (which has to be some type of secure cryptographic device), either the key loader or the device or both must require two or more PINs/passwords before injecting the plain-text key into the device. (Note: This may be the entire key•if components, each component requires a separate password.) These passwords are entered directly through the keypad of the applicable device or are conveyed encrypted into the device and must …

Modified p. 37 → 45

Injection of plain-text secret keys or their components where the device does not itself require the use of at least two PINs/passwords for injection results in the zeroization of pre-existing

Injection of plain-text secret keys or their components where the device does not itself require the use of at least two PINs/passwords 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, PINs or similar) for each user on a given device must be different for each …

Modified p. 38 → 46

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

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 …

Modified p. 38 → 46

Q ~~146~~ Should the average delay between encryptions be calculated for the exhaustive attack of a single PIN block, or should the time be averaged over attacks on multiple PIN blocks? A The average time delay should be calculated for an attacker to determine a single PIN value.

Q 1 Should the average delay between encryptions be calculated for the exhaustive attack of a single PIN block, or should the time be averaged over attacks on multiple PIN blocks? A The average time delay should be calculated for an attacker to determine a single PIN value.

Modified p. 38 → 46

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

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 …

Modified p. 39 → 46

Q ~~148~~ 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 over a longer time frame than one hour? A The intent of the requirement statement is that for any 120 consecutive transactions, the average time between encryptions for a specific PIN entry averages out to approximately 30 seconds.

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 over a longer time frame than one hour? A The intent of the requirement statement is that for any 120 consecutive transactions, the average time between encryptions for a specific PIN entry averages out to approximately 30 seconds.

Modified p. 39 → 46

Q ~~149~~ 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.

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.

Modified p. 39 → 47

Q ~~150~~ What PIN block formats are allowed? A ISO 9564•1 PIN block formats 0, 1, or 3 are acceptable for online transactions. Format 2 must be used for PINs that are submitted from the IC reader to the IC for offline transactions. This applies whether the PIN is submitted in ~~plain-text~~ or enciphered using an encipherment key of the IC.

Q 2 September (update) 2015: What PIN block formats are allowed? A ISO 9564•1 PIN block formats 0, 1, 3 or 4 are acceptable for online transactions. Format 2 must be used for PINs that are submitted from the IC reader to the IC for offline transactions. This applies whether the PIN is submitted in plaintext or enciphered using an encipherment key of the IC.

Modified p. 39 → 47

Q ~~151~~ 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.

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.

Modified p. 39 → 47

Q ~~152~~ 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.

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.

Modified p. 39 → 47

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

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 …

Modified p. 40 → 47

Q ~~154~~ 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.

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.

Modified p. 40 → 48

Q ~~155~~ Under what conditions is it acceptable for a device to allow single component plain-text cryptographic keys to be loaded via the keypad? A None. A device must not accept entry of single component plain-text cryptographic keys via the keypad. Full-length key components and encrypted keys may be loaded via the keypad if the requirements for sensitive functions are met (PCI B7, B8).

Q 7 Under what conditions is it acceptable for a device to allow single component plain-text cryptographic keys to be loaded via the keypad? A None. A device must not accept entry of single component plain-text cryptographic keys via the keypad. Full-length key components and encrypted keys may be loaded via the keypad if the requirements for sensitive functions are met (PCI B7, B8).

Modified p. 40 → 48

Q ~~156~~ 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) …

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

Modified p. 41 → 48

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

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 …

Modified p. 41 → 48

Algorithm DES RSA Elliptic Curve ~~DSA/D-H/MQV~~ 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 minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. DSA for digital signatures, and Diffie-Hellman and MQV key agreement key sizes refer to the size of the modulus …

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 minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. DSA for digital signatures, and Diffie-Hellman and MQV key agreement key sizes refer to the size of the modulus …

Modified p. 41 → 49

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

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 …

Modified p. 42 → 49

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

Q 11 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 …

Modified p. 42 → 50

Q ~~160~~ May 2011: What are acceptable methods for remote key distribution using asymmetric techniques methodologies to protect against man-in-the-middle attacks and the hijacking of PIN-acceptance devices? A There are several techniques available, four of which are:

Q 12 May 2011: What are acceptable methods for remote key distribution using asymmetric techniques methodologies to protect against man-in-the-middle attacks and the hijacking of PIN-acceptance devices? A There are several techniques available, four of which are:

Removed p. 43

Q 161 September 2012: With the release of PCI PTS POI v3, SHA-1 was explicitly prohibited for use, and only SHA-2 was allowed. Some vendors may support the use of remote key distribution using asymmetric techniques, which makes use of SHA-1 in either PCI v1 or v2 product implementations. Vendors supporting such techniques can readily migrate their implementations to support SHA-2, however, they may have customers who need to be able to phase in these more robust implementations while supporting a portfolio that include both POI v3 and older devices. In order to support such customers, is it permissible for a vendor to have as a configuration option parallel remote key distribution methodologies, one supporting SHA-1 and the other supporting SHA-2? A Yes to facilitate the orderly migration of the mixed device portfolios of acquiring entities, vendors may submit for approval under POI v3 devices which have parallel implementations of …

Modified p. 43 → 50

Q ~~162~~ Version 3 stipulates that the device must provide support for TR-31 or an equivalent methodology for maintaining the TDES key bundle. Under what circumstances does this apply? A If the device supports the exchange of TDEA keys between itself and another device (e.g., a remote host) encrypted under a shared symmetric key, the device must provide support for TR- 31 or an equivalent methodology for this key conveyance. This does not imply that the device must support TR-31 …

Q 13 Version 4 stipulates that the device must provide support for TR-31 or an equivalent methodology for maintaining the TDES key bundle. Under what circumstances does this apply? A If the device supports the exchange of TDEA keys between itself and another device (e.g., a remote host) encrypted under a shared symmetric key, the device must provide support for TR- 31 or an equivalent methodology for this key conveyance. This does not imply that the device must support TR-31 …

Modified p. 43 → 50

Q ~~163~~ TR-31 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, in order to meet the requirement that a key is used only for a single purpose as defined in ANSI X9.24, the key block protection key is only used to calculate the KBEK …

Q 14 TR-31 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, in order to meet the requirement that a key is used only for a single purpose as defined in ANSI X9.24, the key block protection key is only used to calculate the KBEK …

Modified p. 43 → 50

Q ~~164~~ A device may support key-check values to validate the successful entry of symmetric key components and/or keys. Are there any restrictions on the use of key-check values? A Yes. Any returned values shall not exceed six hexadecimal characters and should be at least four hexadecimal characters in length.

Q 15 A device may support key-check values to validate the successful entry of symmetric key components and/or keys. Are there any restrictions on the use of key-check values? A Yes. Any returned values shall not exceed six hexadecimal characters and should be at least four hexadecimal characters in length.

Modified p. 43 → 51

Q ~~165~~ Requirement B11 stipulates that the device must support TR-31 or equivalent. Key blocks that support padding include a key length that allows the key to be distinguished from the pad characters. In TR-31, the key-length information and padding are encrypted along with the key itself by the KEK (termed the key block encryption key). Does this violate the requirement that a cryptographic key be only used for one purpose, e.g., key encipherment? A No. For all TDEA modes …

Q 16 Requirement B11 stipulates that the device must support TR-31 or equivalent. Key blocks that support padding include a key length that allows the key to be distinguished from the pad characters. In TR-31, the key-length information and padding are encrypted along with the key itself by the KEK (termed the key block encryption key). Does this violate the requirement that a cryptographic key be only used for one purpose, e.g., key encipherment? A No. For all TDEA modes …

Modified p. 44 → 51

Q ~~166~~ TR-31 or an equivalent methodology must be used whenever a symmetric key is downloaded from a remote host enciphered by a shared symmetric key. Are there other circumstances where TR-31 or an equivalent methodology applies or does not apply? A Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, …

Q 17 TR-31 or an equivalent methodology must be used whenever a symmetric key is downloaded from a remote host enciphered by a shared symmetric key. Are there other circumstances where TR-31 or an equivalent methodology applies or does not apply? A Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, …

Modified p. 44 → 51

Q ~~167~~ In support of the conversion of deployed devices to the use of TR-31, can a key previously loaded for another purpose, such as a KEK, be re-statused as a TR-31 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 …

Q 18 In support of the conversion of deployed devices to the use of TR-31, can a key previously loaded for another purpose, such as a KEK, be re-statused as a TR-31 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 …

Modified p. 45 → 51

Q ~~168~~ TR-31 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 configuration option. To implement TR-31 or equivalent for devices that are currently implementing a non-TR-31 symmetric methodology, what characteristics must the device have to support this migration? A The device must enforce the following where applicable:

Q 19 June (update) 2015: TR-31 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 configuration option. To implement TR-31 or equivalent for devices that are currently implementing a non-TR-31 symmetric methodology, what characteristics must the device have to support this migration? A The device must enforce the following where applicable:

Modified p. 45 → 51

These passwords/PINs must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/PINs that are unique per device can be made optionally changeable by the acquirer, but this is not required. Passwords/PINs are at least ~~five~~ characters.

These passwords/PINs must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Passwords/PINs that are unique per device can be made optionally changeable by the acquirer, but this is not required. Passwords/PINs are at least seven characters.

Modified p. 45 → 52

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

• 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 PINs/passwords before injection of the key. These passwords 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/PINs must either be unique per device (and per custodian), except by chance, or if vendor default, they are …

Modified p. 45 → 52

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

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 …

Modified p. 46 → 52

Q ~~170~~ 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 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.

Modified p. 46 → 52

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

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 …

Modified p. 46 → 53

Q ~~172~~ 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:

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. 46 → 53

• 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. 46 → 53

Q ~~173~~ Can secret keys or their components be used for other purposes such as passwords 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.

Q 24 Can secret keys or their components be used for other purposes such as passwords 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.

Modified p. 47 → 54

Q ~~174 June 2012:~~ 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 …

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 …

Modified p. 47 → 54

Q ~~175~~ 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 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.

Modified p. 47 → 54

Q ~~176~~ Is it acceptable for a PIN-encryption key to be used as a key-encrypting key, or for a key- encrypting key to be used as a PIN-encrypting key? A No. A key must be used for one purpose only as mandated by ANSI X9.24 and ISO 11568-3.

Q 1 Is it acceptable for a PIN-encryption key to be used as a key-encrypting key, or for a key- encrypting key to be used as a PIN-encrypting key? A No. A key must be used for one purpose only as mandated by ANSI X9.24 and ISO 11568-3.

Modified p. 47 → 54

Q ~~177~~ Can a device use a key-encrypting key to encrypt or decrypt key-tag information along with a key? A Yes, associated key-tag information such as the algorithm, key expiration, usage, or key MAC may be encrypted or decrypted along with the key using a key-encrypting key. The key and its tag are bound together using a chaining mode of encipherment as defined in IS0 10116.

Q 2 Can a device use a key-encrypting key to encrypt or decrypt key-tag information along with a key? A Yes, associated key-tag information such as the algorithm, key expiration, usage, or key MAC may be encrypted or decrypted along with the key using a key-encrypting key. The key and its tag are bound together using a chaining mode of encipherment as defined in IS0 10116.

Removed p. 48

POI Requirement B16.1

Modified p. 48 → 55

Q ~~178~~ The device must enforce that data keys, ~~key encipherment~~ keys and PIN-encryption keys have different values. Does this apply to replacement keys downloaded throughout the processing life of the device? A The intent of the requirement is to help ensure that these keys are not intentionally used for multiple purposes. Thus the uniqueness check applies for both when the device is initially loaded with these keys and for those that are subsequently loaded. The check must occur across …

Q 3 The device must enforce that data keys, key-encipherment keys and PIN-encryption keys have different values. Does this apply to replacement keys downloaded throughout the processing life of the device? A The intent of the requirement is to help ensure that these keys are not intentionally used for multiple purposes. Thus the uniqueness check applies for both when the device is initially loaded with these keys and for those that are subsequently loaded. The check must occur across all …

Modified p. 48 → 55

Q ~~179~~ May 2011: B13 requires that keys are not intentionally used for multiple purposes. This uniqueness check applies for both when the device is initially loaded with these keys and for those that are subsequently loaded and must occur across all secret-key hierarchies supported by the device. No two secret keys, regardless of purpose, can have the same value. Do parity bits factor into the check? A Yes, keys that are identical except for parity bits must be rejected …

Q 4 May 2011: B13 requires that keys are not intentionally used for multiple purposes. This uniqueness check applies for both when the device is initially loaded with these keys and for those that are subsequently loaded and must occur across all secret-key hierarchies supported by the device. No two secret keys, regardless of purpose, can have the same value. Do parity bits factor into the check? A Yes, keys that are identical except for parity bits must be rejected …

Modified p. 48 → 55

Q ~~180~~ 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.

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.

Modified p. 48 → 55

Q ~~181~~ 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.

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.

Modified p. 48 → 55

Q ~~182~~ 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.

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.

Modified p. 48 → 55

Q ~~183~~ 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.

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.

Removed p. 49

Q 185 What log file characteristics and content are necessary to meet Requirement B16.2? A A device must automatically record events that are relevant to B16.2 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 188 Can USB authentication tokens or smart cards be considered to be the SCD required to enforce dual control under B16.2? A The use of dual tokens alone would not meet the requirement. The tokens would need to …

Modified p. 49 → 56

Q ~~184~~ 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:

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:

Modified p. 49 → 56

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

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

Modified p. 49 → 56

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

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.

Modified p. 50 → 58

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

Modified p. 50 → 59

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

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

Modified p. 50 → 59

Q ~~191~~ 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 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.

Modified p. 50 → 59

Q ~~192~~ 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 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.

Modified p. 50 → 59

Q ~~193~~ If a key externally selected is not the encryption key used to directly encrypt the PIN block, is this selection required to be authenticated? A If the external selection is associated with the PIN encryption, the authentication would apply. For example, externally selecting the Master Key under which a session key will be decrypted for use in PIN block encryption would need to be authenticated.

Q 4 If a key externally selected is not the encryption key used to directly encrypt the PIN block, is this selection required to be authenticated? A If the external selection is associated with the PIN encryption, the authentication would apply. For example, externally selecting the Master Key under which a session key will be decrypted for use in PIN block encryption would need to be authenticated.

Modified p. 50 → 59

Q ~~194~~ 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? A Yes, as long as there is a mechanism that ensures that keys under each acquirer are associated exclusively with that acquirer.

Q 5 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? A Yes, as long as there is a mechanism that ensures that keys under each acquirer are associated exclusively with that acquirer.

Modified p. 51 → 60

Q ~~195~~ External key selection includes selection performed by either a local or remote host. Under what circumstances is a device supporting multiple key hierarchies not required to enforce authentication for each external key selection command? A If an application can select keys from multiple key hierarchies, the device must enforce authentication of commands used for external key selection. If the device only allows an application to select keys from a single hierarchy, then command authentication is not required.

Q 6 External key selection includes selection performed by either a local or remote host. Under what circumstances is a device supporting multiple key hierarchies not required to enforce authentication for each external key selection command? A If an application can select keys from multiple key hierarchies, the device must enforce authentication of commands used for external key selection. If the device only allows an application to select keys from a single hierarchy, then command authentication is not required.

Modified p. 51 → 60

• Key hierarchies for PIN encryption are only established directly by the vendor at their secure facility or at an authorized facility operated by a third party that regularly performs ~~key- loading~~ on behalf of the vendor and is registered to do so under applicable payment brand rules; and subsequent to leaving the facility it is physically and/or logically impossible to load additional key hierarchies without returning to the facility.

• Key hierarchies for PIN encryption are only established directly by the vendor at their secure facility or at an authorized facility operated by a third party that regularly performs key-loading on behalf of the vendor and is registered to do so under applicable payment brand rules; and subsequent to leaving the facility it is physically and/or logically impossible to load additional key hierarchies without returning to the facility.

Modified p. 51 → 60

Q ~~196~~ 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 to PIN encryption.

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 to PIN encryption.

Modified p. 51 → 60

Q ~~197~~ The PCI v1.3 requirements specified that precautions against unauthorized removal were required for unattended devices (PCI POS PED v1.3 DTR 1.4). Are such precautions required for compliance to DTR D1 of the ~~v3.0~~ requirements? A Yes, an unattended device that supports offline PIN entry using a separate ICC reader must provide protections against the unauthorized removal of that reader. Circumvention of these protections must require an attack potential of at least 20 points.

Q 1 The PCI v1.3 requirements specified that precautions against unauthorized removal were required for unattended devices (PCI POS PED v1.3 DTR 1.4). Are such precautions required for compliance to DTR D1 of the v4.0 requirements? A Yes, an unattended device that supports offline PIN entry using a separate ICC reader must provide protections against the unauthorized removal of that reader. Circumvention of these protections must require an attack potential of at least 20 points.

Modified p. 51 → 60

Q ~~198~~ What is meant by “sufficient space to hold a PIN-disclosing ‘bug’”? A Space accessible via the ICC card slot large enough to conceal a PIN-disclosing bug is not allowed. Such a bug could utilize ICC technology. Therefore, there must not be space accessible via the card slot large enough to conceal an ICC chip and small battery.

Q 2 What is meant by “sufficient space to hold a PIN-disclosing ‘bug’”? A Space accessible via the ICC card slot large enough to conceal a PIN-disclosing bug is not allowed. Such a bug could utilize ICC technology. Therefore, there must not be space accessible via the card slot large enough to conceal an ICC chip and small battery.

Modified p. 52 → 60

Q ~~199~~ What volume of space is allowed under D1? A The objective of D1 is to guard against a PIN-disclosing bug being inserted into the device through the card slot. The volume of space accessible via the card slot that could be utilized by an attacker can vary with the geometry of the space and attack methods. For this reason, the requirement does not prohibit a specific volume. Rather, the feasibility of effective bug placement is to be considered …

Q 3 What volume of space is allowed under D1? A The objective of D1 is to guard against a PIN-disclosing bug being inserted into the device through the card slot. The volume of space accessible via the card slot that could be utilized by an attacker can vary with the geometry of the space and attack methods. For this reason, the requirement does not prohibit a specific volume. Rather, the feasibility of effective bug placement is to be considered …

Modified p. 52 → 61

Q ~~200~~ March 2011: D1 stipulates that it must not be possible for both an ICC card and any other foreign object, such as a PIN-disclosing bug to reside within the IC card insertion slot. Part of the determination relies upon it must not be possible to simultaneously insert two payment cards into the slot and still perform a transaction. Are there any further restrictions on this test? A Yes. As unembossed cards become more common, the device must not …

Q 4 March 2011: D1 stipulates that it must not be possible for both an ICC card and any other foreign object, such as a PIN-disclosing bug to reside within the IC card insertion slot. Part of the determination relies upon it must not be possible to simultaneously insert two payment cards into the slot and still perform a transaction. Are there any further restrictions on this test? A Yes. As unembossed cards become more common, the device must not …

Modified p. 52 → 61

Q ~~201~~ Is D2 intended to address the opening of the ICC reader, or the entire reader? A D2 is written with the understanding that the opening (slot) is a potential point of attack for the insertion of a tapping mechanism.

Q 1 Is D2 intended to address the opening of the ICC reader, or the entire reader? A D2 is written with the understanding that the opening (slot) is a potential point of attack for the insertion of a tapping mechanism.

Modified p. 52 → 61

Q ~~202~~ July 2014: The ICC reader’s slot is required to be in full view of the cardholder so that any untoward obstructions or suspicious objects at the opening are detectable. The construction of the device must be such that the entire slot opening is in full view of the cardholder prior to card insertion. In certain Unattended Payment Terminal designs the ICCR slot cannot be positioned straight (horizontal) to the cardholder, when could this be acceptable? A The intent …

Q 2 July 2014: The ICC reader’s slot is required to be in full view of the cardholder so that any untoward obstructions or suspicious objects at the opening are detectable. The construction of the device must be such that the entire slot opening is in full view of the cardholder prior to card insertion. In certain Unattended Payment Terminal designs the ICCR slot cannot be positioned straight (horizontal) to the cardholder, when could this be acceptable? A The intent …

Modified p. 52 → 61

• The ICCR slot internal sizes must not be sufficient to simultaneously insert two ~~un-embossed~~ cards and execute a transaction in order to minimize the likelihood of sufficient space for a bug.

• The ICCR slot internal sizes must not be sufficient to simultaneously insert two un- embossed cards and execute a transaction in order to minimize the likelihood of sufficient space for a bug.

Modified p. 53 → 62

Q ~~203~~ Some device designs include components (e.g., privacy shield) that are near the IC card slot, which could be used to conceal a wire. What criteria are used to determine compliance when such components are present? A The design is considered compliant with D3 if a portion of the wire is visible between the slot and the concealing component.

Q 1 Some device designs include components (e.g., privacy shield) that are near the IC card slot, which could be used to conceal a wire. What criteria are used to determine compliance when such components are present? A The design is considered compliant with D3 if a portion of the wire is visible between the slot and the concealing component.

Modified p. 53 → 62

Q ~~204~~ ISO 9564 stipulates that if the PIN is to be submitted to the IC card in enciphered form, then the device shall encipher the PIN using the authenticated encipherment key of the IC card and submit the enciphered PIN to the IC card. Are there any restrictions on where the authentication must occur? A The device must protect the integrity of all public keys (ICC, applicable issuer, and payment brand) using techniques defined in ISO 11568. In all …

Q 1 ISO 9564 stipulates that if the PIN is to be submitted to the IC card in enciphered form, then the device shall encipher the PIN using the authenticated encipherment key of the IC card and submit the enciphered PIN to the IC card. Are there any restrictions on where the authentication must occur? A The device must protect the integrity of all public keys (ICC, applicable issuer, and payment brand) using techniques defined in ISO 11568. In all …

Modified p. 53 → 62

Q ~~205~~ 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 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.

Modified p. 53 → 62

Q ~~206~~ 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 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.

Modified p. 53 → 62

Q ~~207~~ 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 must not assign any points to access of …

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 must not assign any points to access of …

Removed p. 54

Q 208 October 2011: Where hashing is used to provide for the integrity of data sent over a network connection, the algorithm used must be SHA-2 or higher. If a device implements TLS 1.0 (SSL 3.1) as its only security protocol, and therefore does not support the use of SHA-2 variants in its cipher suite, what options are available for meeting the requirements? A The options for meeting this are:

• Upgrading to TLS 1.2, which provides native support

• Providing security guidance documentation stipulating that application developers must implement SHA-2 for hashing when using SSL/TLS for security functionality.

Modified p. 54 → 63

Q ~~209~~ March 2011: K1 allows the disclosure of clear-text account data by the secure controller to authenticated applications. What constitutes an authenticated application for purposes of SRED? A There are several conditions that an authenticated application must meet:

Q 1 March 2011: K1 allows the disclosure of clear-text account data by the secure controller to authenticated applications. What constitutes an authenticated application for purposes of SRED? A There are several conditions that an authenticated application must meet:

Modified p. 54 → 63

Q ~~210~~ November 2012: Where a whitelist is used to control whether PAN data exits the device in plaintext or ciphertext, does the whitelist updating have to be under the direct control of the vendor? A No, the vendor may provide the mechanisms to the acquirer to directly control the updating of the whitelists in a manner consistent with acquirer controlled display prompts. That is the use of dual control techniques and provisions for auditability and logging. ~~The vendor may …~~

Q 2 November 2012: Where a whitelist is used to control whether PAN data exits the device in plaintext or ciphertext, does the whitelist updating have to be under the direct control of the vendor? A No, the vendor may provide the mechanisms to the acquirer to directly control the updating of the whitelists in a manner consistent with acquirer controlled display prompts. That is the use of dual control techniques and provisions for auditability and logging.

Modified p. 54 → 63

Q ~~211~~ June 2012: The guidance states that the path for contactless data must be secured to 16 points from the point of digitization of the data. Does the point of digitization include the point of ~~entry -- e.g.,~~ the antennae? A The point of digitization occurs when the data is processed by the NFC controller and not at the point of entry. The NFC controller acts as a modem converting the analog signal to a digital signal just as …

Q 1 June 2012: The guidance states that the path for contactless data must be secured to 16 points from the point of digitization of the data. Does the point of digitization include the point of entry•e.g., the antennae? A The point of digitization occurs when the data is processed by the NFC controller and not at the point of entry. The NFC controller acts as a modem converting the analog signal to a digital signal just as a magnetic …

Removed p. 55

Q 216 January 2015: Do the same minimum key sizes apply for the protection of account data under SRED as exists for the protection of PINs? All minimums apply equally with one exception. Double length TDES keys used in connection with SRED can only be used in DUKPT implementations. Double length TDES keys are not permitted for use in SRED in Master/Session or Fixed key implementations

Modified p. 55 → 63

Q ~~212~~ July (update) 2014: K1.1 stipulates that all methods of card-data entry supported by the device must be assessed. Can a device supporting one or more card reader types (Contactless, ICCR, MSR) receive SRED validation if one or more of the card readers cannot meet K1.1? A No, a device validated to SRED cannot have any card reader types as part of the approved hardware and firmware version identifiers where that reader could not meet K1.1, nor can the …

Q 2 July (update) 2014: K1.1 stipulates that all methods of card-data entry supported by the device must be assessed. Can a device supporting one or more card reader types (Contactless, ICCR, MSR) receive SRED validation if one or more of the card readers cannot meet K1.1? A No, a device validated to SRED cannot have any card reader types as part of the approved hardware and firmware version identifiers where that reader could not meet K1.1, nor can the …

Modified p. 55 → 64

Q ~~213~~ September 2012: Many devices offer contactless readers as an optional module, in addition to an ICCR and/or a MSR. Does the contactless module have to meet K1.1 in order to be included as part of the approval? A Devices undergoing SRED validation must have all readers supported by the approved firmware compliant to K1.1. If the contactless reader cannot meet K1.1 it cannot be part of the approved hardware version that includes SRED. ~~Devices that do not support …~~

Q 3 September 2012: Many devices offer contactless readers as an optional module, in addition to an ICCR and/or a MSR. Does the contactless module have to meet K1.1 in order to be included as part of the approval? A Devices undergoing SRED validation must have all readers supported by the approved firmware compliant to K1.1. If the contactless reader cannot meet K1.1 it cannot be part of the approved hardware version that includes SRED.

Modified p. 55 → 64

Q ~~214~~ December 2011: What requirements exist for the security of public keys and key management functions on SCR approval class devices? A Public keys must be protected against change within the device, to prevent attacks to compromise the security of the system through this attack vector. Devices designed for compliance to the SCR approval classes, and which rely on public keys to provide security or authentication to functions such as firmware updates, must be assessed by the PCI PTS …

Q 1 December 2011: What requirements exist for the security of public keys and key management functions on SCR approval class devices? A Public keys must be protected against change within the device, to prevent attacks to compromise the security of the system through this attack vector. Devices designed for compliance to the SCR approval classes, and which rely on public keys to provide security or authentication to functions such as firmware updates, must be assessed by the PCI PTS …

Modified p. 55 → 64

Q ~~215~~ February 2012: Can a device meet SRED requirements without encrypting account data? A No. Compliance with K4 is mandatory for any device to be approved against SRED and have SRED listed as functionality provided.

Q 1 February 2012: Can a device meet SRED requirements without encrypting account data? A No. Compliance with K4 is mandatory for any device to be approved against SRED and have SRED listed as functionality provided.

Removed p. 56

Note: This requirement only applies to keys used to encrypt account data where that encryption is used for the purposes of compliance with the external data security requirements of the SRED module. For example, keys used to encrypt data only between an encrypting MSR readhead and the security processor, where the data is then decrypted and re-encrypted by the security processor with a different, stronger key, are not in scope of this FAQ. However, if the TOE is an SCR, it does apply

Modified p. 56 → 65

Q ~~217~~ July (update) 2014: Can a POI device approved for SRED have a default configuration to not encrypt account data? A The default configuration of a device approved against SRED must be to encrypt account data unless that data is explicitly excluded through use of a method treated as a sensitive ~~service,~~ i.e., requiring dual control or the use of cryptographic authentication. For example:

Q 2 July (update) 2014: Can a POI device approved for SRED have a default configuration to not encrypt account data? A The default configuration of a device approved against SRED must be to encrypt account data unless that data is explicitly excluded through use of a method treated as a sensitive service• i.e., requiring dual control or the use of cryptographic authentication. For example:

Modified p. 56 → 65

• Where a device implements a ~~'whitelist'~~ function ~~- i.e.,~~ the device can be configured to allow for output of some subset of card data in plaintext ~~(e.g.~~ for loyalty or other non-PCI cards) ~~- the~~ absence of the whitelist causes all account data to be encrypted. Any whitelists must be cryptographically authenticated by the POI before use, or entered manually through the keypad only when the device is in a sensitive state.

• Where a device implements a “whitelist” function •i.e., the device can be configured to allow for output of some subset of card data in plaintext (e.g., for loyalty or other non-PCI cards) •the absence of the whitelist causes all account data to be encrypted. Any whitelists must be cryptographically authenticated by the POI before use, or entered manually through the keypad only when the device is in a sensitive state.

Modified p. 56 → 65

• For devices that allow the enablement (turning on) or the disablement (turning off) of SRED functionality, the enablement must result in the firmware revision number changing and the device providing visual indication of SRED enablement. Disablement must result in the firmware revision number reverting and the device no longer providing visual indication of SRED enablement. The visual indication must not be transient and shall be illustrated by photographic evidence provided in the evaluation report. This must be documented in …

Modified p. 56 → 65

• The device has only one operational ~~mode~~ and the firmware is not able to export the card ~~data--it~~ only provides the data to an authenticated application. The firmware does not allow any other mechanism for card data export.

• The device has only one operational mode, and the firmware is not able to export the card data

•it only provides the data to an authenticated application. The firmware does not allow any other mechanism for card data export.

Modified p. 56 → 65

Q ~~218~~ March (update) 2015: Do the same minimum key sizes apply for the protection of account data under SRED as exists for the protection of PINs? A All minimums apply equally with one exception. Double length TDES keys used in connection with SRED can only be used in unique key per transaction implementations as defined in ISO 11568 for key derivation or transformation, e.g., DUKPT. Double length TDES keys are not permitted for use in SRED in Master/Session or …

Q 3 March (update) 2015: Do the same minimum key sizes apply for the protection of account data under SRED as exists for the protection of PINs? A All minimums apply equally with one exception. Double length TDES keys used in connection with SRED can only be used in unique key per transaction implementations as defined in ISO 11568 for key derivation or transformation, e.g., DUKPT. Double length TDES keys are not permitted for use in SRED in Master/Session or …

Modified p. 57 → 66

Q ~~219~~ June (update) 2016: Requirement K4 states that any method used to produce encrypted text that relies on “non-standard” modes of operations (for example, format-preserving Feistel-based Encryption Mode (FFX)) shall be approved by at least one independent security evaluation organization (for example, a standards body) and subjected to independent expert review. How is this requirement met if the method is not included in a published standard? A All account data shall be encrypted using only ANSI X9 or ISO …

Q 4 June (update) 2016: Requirement K4 states that any method used to produce encrypted text that relies on “non-standard” modes of operations (for example, format-preserving Feistel-based Encryption Mode (FFX)) shall be approved by at least one independent security evaluation organization (for example, a standards body) and subjected to independent expert review. How is this requirement met if the method is not included in a published standard? A All account data shall be encrypted using only ANSI X9 or ISO …

Modified p. 57 → 66

1. One that is described in ISO/IEC 10116:2006 (or equivalent) and ~~follow~~ secure padding guidelines.

1. One that is described in ISO/IEC 10116:2006 (or equivalent) and follows secure padding guidelines. Or

Modified p. 57 → 66

2. Exist on a draft standard from a standards body applicable to the financial payments industry i.e., ANSI, ISO or NIST

2. Exist on a draft standard from a standards body applicable to the financial payments industry i.e., ANSI, ISO or NIST And

Modified p. 57 → 66

3. Be subject to an independent expert review and said review is publically available and is reviewed by the PCI PTS evaluation laboratory.

3. Be subject to an independent expert review and said review is publically available and is reviewed by the PCI PTS evaluation laboratory. The review by the independent expert must include proof that this FPE secures against Message Recovery as defined in Bellare, M., Ristenpart, T., Rogaway, P., & Stegers, T. (2009, August). Format-preserving encryption. In Selected Areas in Cryptography (pp. 295-312). Springer Berlin Heidelberg (https://eprint.iacr.org/2009/251.pdf).

Modified p. 57 → 66

Q ~~220~~ November 2012: Requirement K6 uses the word ~~“supports”.~~ Does this imply the device must enforce the use of data-origin authentication, or is it optional in the sense it must be ~~supported,~~ but its use is not mandatory? A No, this does not imply that the device must enforce the implementation of data-origin authentication but it must be capable of implementing such a scheme as a configuration option.

Q 1 November 2012: Requirement K6 uses the word “supports.” Does this imply the device must enforce the use of data-origin authentication, or is it optional in the sense it must be supported but its use is not mandatory? A No, this does not imply that the device must enforce the implementation of data-origin authentication but it must be capable of implementing such a scheme as a configuration option.

Modified p. 57 → 66

Q ~~221~~ December 2011: Account data encryption keys can only be used to encrypt account data and if applicable, transaction-relevant information. What is acceptable for “transaction- relevant” information? A ICC EMV dialog messages exchanged between an external ICCR and a PIN pad, including the ICC public key, are considered transaction relevant information.

Q 1 December 2011: Account data encryption keys can only be used to encrypt account data and if applicable, transaction-relevant information. What is acceptable for “transaction- relevant” information? A ICC EMV dialog messages exchanged between an external ICCR and a PIN pad, including the ICC public key, are considered transaction relevant information.

Modified p. 58 → 67

Q ~~222~~ December 2011: 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. For messages to the host, can the account data key be used for full message encipherment? A Yes, provided it meets all of the following:

Q 2 December 2011: 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. For messages to the host, can the account data key be used for full message encipherment? A Yes, provided it meets all of the following:

Modified p. 58 → 67

Q ~~223~~ March 2011: Authenticated applications may be developed by the POI vendor or by other third parties. The applications are to be developed using techniques consistent with PA- DSS and must be cryptographically authenticated by the POI. Are there any other considerations? A Yes. The technique used to manage the authentication mechanism (e.g., digital signatures) must use a SCD and dual-control techniques. For third parties, the device vendor must either provide the SCD to the third parties or describe …

Q 1 March 2011: Authenticated applications may be developed by the POI vendor or by other third parties. The applications are to be developed using techniques consistent with PA- DSS and must be cryptographically authenticated by the POI. Are there any other considerations? A Yes. The technique used to manage the authentication mechanism (e.g., digital signatures) must use a SCD and dual-control techniques. For third parties, the device vendor must either provide the SCD to the third parties or describe …

Modified p. 59 → 68

Q ~~224~~ June 2012: ~~K16~~ stipulates that changing between encrypting and non-encrypting modes of operation requires explicit authentication. How is this implemented? A Changing between modes is considered a sensitive service as stated in K24 and K25 and therefore requires that authentication use dual control techniques when entering sensitive information through a secure user interface, or cryptographic techniques when entering electronic data.

Q 1 June 2012: K15 stipulates that changing between encrypting and non-encrypting modes of operation requires explicit authentication. How is this implemented? A Changing between modes is considered a sensitive service as stated in K24 and K25 and therefore requires that authentication use dual control techniques when entering sensitive information through a secure user interface, or cryptographic techniques when entering electronic data.

Modified p. 59 → 68

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

Modified p. 60 → 69

POI Requirement ~~K17.1~~

POI Requirement K16.1

Modified p. 60 → 69

Q ~~227 February 2012:~~ 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.

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.

Modified p. 60 → 69

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

• 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