Document Comparison
PTS_POI_Technical_FAQs_v4_August_2022.pdf
→
PTS_POI_Technical_FAQs_v5_August_2022.pdf
57% similar
69 → 79
Pages
34132 → 39702
Words
155
Content Changes
Content Changes
155 content changes. 21 administrative changes (dates, page numbers) hidden.
Added
p. 15
For Bluetooth 4.1 or higher devices that have BR, EDR, and High Speed (HS) features, Security Mode 4, Level 4 must be used. This requires Secure Connections, which uses authenticated pairing and encryption using 128-bit strength keys generated using FIPS-approved Advanced Encryption Standard (AES) encryption. For Bluetooth 2.1 through 4.0 devices, Security Mode 4, Level 3 must be used.
Added
p. 23
Furthermore, for all new POI evaluations using the Internet Protocol Suite, devices must support TLS 1.2 or higher. In addition, all delta evaluations for POI v3, V4 or v5 devices where the open protocols module is impacted, must meet the same criteria.
PCI requires that devices must only support Cipher Suites for use in TLS 1.2 that provide at least 112 bits of security. Cipher suites that comprise AES and other NIST-approved algorithms are acceptable to use. Cipher suites that use TDEA (3DES) are no longer allowed due to the limited amounts of data that can be processed under a single key i.e., the 64-bit block size does not provide adequate protection in applications such as TLS where large amounts of data are encrypted under the same key.
PCI requires that devices must only support Cipher Suites for use in TLS 1.2 that provide at least 112 bits of security. Cipher suites that comprise AES and other NIST-approved algorithms are acceptable to use. Cipher suites that use TDEA (3DES) are no longer allowed due to the limited amounts of data that can be processed under a single key i.e., the 64-bit block size does not provide adequate protection in applications such as TLS where large amounts of data are encrypted under the same key.
Added
p. 26
Q 82 December 2017: Applications that execute within the secure boundary of the POI device that are added (e.g., by a third party) to the device subsequent to a PTS laboratory evaluation that meet the following do not require assessment and listing as part of the device’s firmware:
• The application cannot impact any of the functionality needed to comply with PCI requirements.
• The application does not replace or disable the PCI evaluated firmware functionality. Does this apply to all POI approval classes? A No. Any code present in an SCR intended to be connected to a COTS devices or SCRP approval class devices is considered firmware and must be assessed and listed as part of the device’s approval.
Q 83 December 2017: Are laboratories allowed to do PTS HSM and POI work at a vendor site? A The purpose of the laboratory assessment is to provide an independent review and testing …
• The application cannot impact any of the functionality needed to comply with PCI requirements.
• The application does not replace or disable the PCI evaluated firmware functionality. Does this apply to all POI approval classes? A No. Any code present in an SCR intended to be connected to a COTS devices or SCRP approval class devices is considered firmware and must be assessed and listed as part of the device’s approval.
Q 83 December 2017: Are laboratories allowed to do PTS HSM and POI work at a vendor site? A The purpose of the laboratory assessment is to provide an independent review and testing …
Added
p. 32
Q 14 May 2018: What is considered as a ‘standard’ bug for attack costings? A Given the recent rise of cheap electronic systems which provide integrated communications and processing options, any bug that would be used for detecting binary data (such as key pressed / not pressed, or capturing data on an ICC I/O signal) must be considered to have a size of 15 x 15 x 5 mm, with a minimum width of 10 mm when costed as a standard part, which includes wireless communication capabilities. Use of a flexible keypad membrane to capture keypad signals must also be considered as no more than a standard part. Where interception of very high speed signals
• that require impedance or transmission path length matching
• is required, a specialized part may be considered. The lab must provide justification of the reasons for this in the report, including captures of the signals to …
• that require impedance or transmission path length matching
• is required, a specialized part may be considered. The lab must provide justification of the reasons for this in the report, including captures of the signals to …
Added
p. 42
Q 3 December 2017: Is it necessary to use ASLR and stack canaries in operating systems within a POI? Yes. Where a complex operating system (such as Linux, other *nix variants, and operating systems such as Android) is used, ASLR must be enabled and correctly configured to be compliant in PCI PTS v5 and above. For Linux, this means setting ‘randomize_va_space’ to a value of ‘2’, and ensuring that all code is correctly compiled (and/or configured) to implement and enable ASLR. Where options are provided for use of stack canaries and data execution prevention bits, these must always be enabled (including for application code).
Added
p. 52
Other acceptable techniques include those stated in ANSI TR-34.
In the event of a permanent device decommissioning, the device may be tampered which must result in the zeroizing of all private and secret keys.
In the event of a permanent device decommissioning, the device may be tampered which must result in the zeroizing of all private and secret keys.
Added
p. 55
These passwords/authentication codes 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/authentication codes that are unique per device can be made optionally changeable by the acquirer, but this is not required. Passwords/authentication codes are at least seven characters.
Entry of key components without the use of at least two separate passwords/authentication codes results in the zeroization of pre-existing acquirer secret keys•i.e., the invoking of the key loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple-acquirer key hierarchies (e.g., multi-acquirer devices), only the hierarchy (e.g., specific TMK and working keys) associated with the key being loaded must be zeroized. In all cases, the authentication values (passwords, authentication codes or similar) for each user on a given device must be different for each user.
Q 26 May …
Entry of key components without the use of at least two separate passwords/authentication codes results in the zeroization of pre-existing acquirer secret keys•i.e., the invoking of the key loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple-acquirer key hierarchies (e.g., multi-acquirer devices), only the hierarchy (e.g., specific TMK and working keys) associated with the key being loaded must be zeroized. In all cases, the authentication values (passwords, authentication codes or similar) for each user on a given device must be different for each user.
Q 26 May …
Added
p. 66
Q 3 October (update) 2018: The PCI PTS Lab Requirements prohibit a PTS lab from creating any vendor-documentation. Are there any scenarios where a PTS lab may assist a vendor in creating documentation? A In some cases, a PTS lab may revise a Security Policy for grammar, formatting, or spelling edits for a device under evaluation. This may be done to assist the vendor in creating a document sufficient to be submitted to PCI. In this case, the PTS lab will provide the following as part of the evaluation report submission:
• A track-changed/redlined version of the edited Security Policy, showing the original text created by the vendor as well as the updated text.
• A clean copy of the edited Security Policy for posting.
• A track-changed/redlined version of the edited Security Policy, showing the original text created by the vendor as well as the updated text.
• A clean copy of the edited Security Policy for posting.
Added
p. 69
Q 5 May 2018: The new SCRP approval class increases the level of protection required for the ICC I/O interface to 26 points. Why is this required when other approval classes continue to allow for a device meeting a level of 20 points of protection to be considered compliant? A The intent behind the SCRP approval class is to ensure that the customer card data is protected and strongly encrypted before it is sent through the passed into the COTS environment device onto the backend systems for payment processing. This is an important part of the overall security of the Software Based PIN entry on COTS (SPoC) PIN on COTS system solution, and helps to prevent correlation attacks and reduce the threat of the compromise of the PIN on the COTS device. Because protection of the ICC I/O signal requires protection from the physical interface to the customer card, through …
Added
p. 72
Q 1 May 2018: Effective 1 May, 2018, POI vendors must complete and submit to PCI an Attestation of Validation (AOV) that includes providing evidentiary materials that an auditable record of an ongoing vulnerability assessment process exists. This is demonstrated by providing a copy of the vendor’s sign-off form specified in Requirement G1 regarding all physical interfaces and the corresponding logical protocols that are supported by the device as stated in Requirement F1. This applies to all unexpired approvals that exist for the vendor as of 31 December of the prior year. Does this vulnerability assessment process apply to non-public domain protocols and interfaces? A Yes the intent of the vulnerability assessment process is to be comprehensive. Effective with the May 2019 reporting for the 2018 calendar year, the vulnerability process reported on in the AOV must include all physical interfaces and their corresponding logical protocols. To facilitate this, evaluations …
Modified
p. 1
Payment Card Industry (PCI) PTS POI Security Requirements Technical FAQs for use with Version 4
Payment Card Industry (PCI) PTS POI Security Requirements Technical FAQs for use with Version 5
Modified
p. 3 → 4
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.
Q 4 May (update) 2018: What is the definition of “Secret Information?” A “Secret information” is any cryptographic keys or passwords/authentication codes that the device relies on to maintain security characteristics governed by PCI requirements.
Modified
p. 3 → 4
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.
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 A5. 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 → 5
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
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: a) Revisions to existing firmware or hardware on existing approved devices to add or modify functionality
Modified
p. 4 → 5
b) Adding EMV level 1 to an existing approval
Modified
p. 4 → 5
c) Maintenance fixes on devices that have expired and are no longer approved for new deployments
Modified
p. 4 → 5
d) Assessment of a device for offline PIN entry where the existing approval is only for online PIN entry, or vice versa
Modified
p. 4 → 5
e) The porting of a new set of firmware to an existing approved device.
Modified
p. 5 → 6
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 …
Q 13 May (update) 2018: Does the entry of the authentication code (e.g., password) that is used for settlement/balancing at an ATM require the use of the secure EPP, or may it use an alternate mechanism such as the keyboard at the back of the ATM? A The entry of the authentication code used for settlement/balancing at the ATM does not need to be entered through the EPP, but may use the keyboard installed in the rear of the ATM. …
Modified
p. 5 → 6
Note that PINs or passcodes entered to put the EPP into a sensitive state, such as those used to enable manual key loading, must be entered via a secure interface, i.e., through the EPP.
Note that authentication codes entered to put the EPP into a sensitive state, such as those used to enable manual key loading, must be entered via a secure interface, i.e., through the EPP.
Modified
p. 7 → 8
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, …
Q 22 May (update) 2018: Several requirements, such as those for access to sensitive services, key loading, and removal detection, provide for the use of authentication using passwords or authentication codes. Are there any restrictions on this type of authentication data? A Yes, any passwords, authentication codes, or similar used to meet a PCI requirement must be at least a seven-character minimum. These passwords/authentication codes must either be unique per device (and per user where dual control is required) except …
Modified
p. 9 → 10
a) UPT evaluation reports containing separately approved OEM components must at a minimum contain a summary table of all requirements (whether Yes or N/A) of any module that is relevant to the final form factor of the UPT. This table may reference the pertinent OEM component for compliance to any specific requirement.
Modified
p. 9 → 10
b) All requirements impacted (e.g., additional cardholder input mechanisms, displays, controllers, removal detection, etc.) by the final form factor of the UPT must be addressed in detail for each impacted requirement.
Modified
p. 9 → 10
•e.g., because submitting vendors are different or for any other restriction
•the lab must determine the extent of additional work required.
c) Where the lab evaluating the final form factor is not the same lab as the lab that evaluated OEM component(s), the lab should have access to the OEM component lab report(s). If those reports are not available
•e.g., because submitting vendors are different or for any other restriction
•the lab must determine the extent of additional work required.
•e.g., because submitting vendors are different or for any other restriction
•the lab must determine the extent of additional work required.
Modified
p. 9 → 10
d) If the lab is unable to place reliance, where necessary, on information that is available in reports that are not available to the lab, and the lab is unable to perform the degree of necessary additional work to achieve such reliance, they must decline the engagement.
Modified
p. 9 → 10
e) In all cases, PCI SSC may reject the report if in the judgment of PCI SSC the report does not contain adequate information to substantiate the conclusions of compliance to overall UPT criteria.
Modified
p. 9 → 10
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 …
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 v5 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. 9 → 10
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.
Additional individual security requirements in POI v5 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.
Modified
p. 12 → 13
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 …
Q 35 May (update) 2018: PIN entry devices may physically integrate in the same device other functionality, such as mobile phone, PDA capabilities or POS terminal. Handheld configurations of PIN entry devices may accommodate the attachment (e.g., via a sled, sleeve or audio jack) of a mobile phone, PDA or POS terminal, where the attached device communicates with the PED. Such a configuration appears as a single device, with separate interfaces for input by the clerk and cardholder. What considerations …
Modified
p. 12 → 13
a) Both devices are assessed and validated as compliant to the PTS POI requirements, or
Modified
p. 12 → 13
b) The PED device, which must also control the card reader(s), must implement and be validated against the PTS POI SRED module. The PED must enforce SRED functions for encryption of card data at all times. The PED is only allowed one state, and that is to encrypt all account data. It cannot be configured to enter a state where account data is not encrypted.
Modified
p. 14 → 15
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.
Q 37 October (update) 2018: Are Bluetooth/Wi-Fi interfaces part of the evaluation? A Bluetooth and/or Wi-Fi, like any other open security protocol declared in the POI Protocol Declaration form, must be assessed by the laboratory.
Modified
p. 14 → 15
If a Bluetooth interface is used, the Bluetooth interface must enforce encryption. This encryption is in addition to any other encryption the data may have undergone. If PIN or passkey entry is to be used, the evaluator must validate that vendor default values can be changed. The device must not support or allow for the use of insecure communication options such as, but not limited to, security modes 1 &2 and the “Just Works” secure pairing option of security mode …
If a Bluetooth interface is used, the Bluetooth interface must enforce encryption. This encryption is in addition to any other encryption the data may have undergone. If PIN or passkey entry is to be used, the evaluator must validate that vendor default values can be changed. The device must not support or allow for the use of insecure communication options such as, but not limited to, security modes 1 & 2 and the “Just Works” secure pairing option of security …
Modified
p. 15 → 16
a) It cannot adversely affect the security features of the product that are relevant to the PCI POI approval.
Modified
p. 15 → 16
b) 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.
Modified
p. 15 → 16
c) The application is strongly authenticated to the POI secure controller by digital signature.
Modified
p. 15 → 16
d) The application can only work on the keys it alone manages and cannot affect or see any other keys.
Modified
p. 16 → 17
Q 47 July (update) 2013: Can a secure card reader (SCR) send data in the clear? A A secure card reader intended for use with a non PTS approved device such as, but not limited to, a mobile phone or tablet, is only allowed one state, and that is to encrypt all account data. It cannot be configured to enter a state where account data is not encrypted.
Q 47 July (update) 2013: Can a secure card reader (SCR) send data in the clear? A A secure card reader intended for use with a non-PTS approved device such as, but not limited to, a mobile phone or tablet, is only allowed one state, and that is to encrypt all account data. It cannot be configured to enter a state where account data is not encrypted.
Modified
p. 17 → 18
PCI test laboratory is to provide to MasterCard on behalf of the Council two devices containing the same firmware, any supporting PC based test applications, and any keying material as those evaluated by the test laboratory. Under what conditions are these devices to be provided? A This applies to all new evaluations that result in a new approval number. It does not apply to deltas. It also does not apply to a situation where the vendor is merely rebranding another …
Q 49 July (update) 2015: The PCI POI Testing and Approval Program Guide specifies that the PCI test laboratory is to provide to MasterCard on behalf of the Council two devices containing the same firmware, any supporting PC based test applications, and any keying material as those evaluated by the test laboratory. Under what conditions are these devices to be provided? A This applies to all new evaluations that result in a new approval number. It does not apply to …
Modified
p. 20 → 21
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 …
Q 66 December (update) 2017: 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 …
Modified
p. 20 → 22
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 …
Q 67 October (update) 2018: Can Low Power Bluetooth, also known as Bluetooth Light, Bluetooth Smart or Bluetooth Low Energy (BLE) be used? A BLE implementations must use version 4.2 or higher. BLE must use LE Security Mode 1 Level 4 (Secure Connections) only and Just Works cannot be used at any time. The device must not support or allow for the use of insecure communication options such as, but not limited to, LE Security Mode 2, and levels 1, …
Removed
p. 21
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Modified
p. 21 → 23
Q 69 December (update) 2016: In light of the discovery of the Padding Oracle on Downgraded Legacy Encryption (POODLE) attack, is SSL still an allowed protocol. A SSL may continue to be supported, but the vendor must document (for version 4 devices this includes the Security Policy published on the PCI website) that it is inherently weak and should be removed unless required on an interim basis to facilitate interoperability as part of a migration plan. Furthermore, for all new …
Q 69 October (update) 2018: In light of the discovery of the Padding Oracle on Downgraded Legacy Encryption (POODLE) attack, is SSL still an allowed protocol. A SSL may continue to be supported, but the vendor must document (for version 4 and higher devices this includes the Security Policy published on the PCI website) that it is inherently weak and should be removed unless required on an interim basis to facilitate interoperability as part of a migration plan. For SSL …
Removed
p. 22
• 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
• 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.
• 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
• 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. 24 → 25
Q 75 October 2015: PIN Entry Devices that attach to a mobile phone, PDA or POS terminal via a sled, sleeve, audio jack, or wireless connection are required to support SRED. Does this apply to PEDs that are integrated with other devices (such as a tablet or mobile phone) that appear as a single device? A Yes. An integrated device is one where two physically and electronically distinct devices (e.g., a PED and a commercial off the shelf (COTS) device …
Q 75 May (update) 2018: PIN Entry Devices that attach to a mobile phone, PDA or POS terminal via a sled, sleeve, audio jack, or wireless connection are required to support SRED. Does this apply to PEDs that are integrated with other devices (such as a tablet or mobile phone) that appear as a single device? A Yes. An integrated device is one where two physically and electronically distinct devices (e.g., a PED and a commercial off the shelf (COTS) …
Modified
p. 24 → 25
• The PED, which must also control the card reader(s), must implement and be validated against the PTS POI SRED module and be both physically and electronically distinct from the non-PED system (for example, it is not acceptable to have the PED firmware execute within the same processor as the non-PED firmware). The PED must enforce SRED functions for encryption of card data at all times. The Security Policy must also state that the non-PED has not been assessed under …
• The PED, which must also control the card reader(s), must implement and be validated against the PTS POI SRED module and be both physically and electronically distinct from the non-PED system (for example, it is not acceptable to have the PED firmware execute within the same processor as the non-PED firmware). The PED must enforce SRED functions for encryption of card data at all times. The PED is only allowed one state, and that is to encrypt all account …
Modified
p. 25 → 26
Q 78 July 2017: Is there a limit to the level of damage to a POI that may be ‘covered up’ without casing replacement? A No. It is easy to either cut out a suitable part from a mechanical sample (obtained during identification) or 3D print a part for the replacement area. Paint or stickers can easily hide any seams or damage as it is common in the marketplace for deployed POIs to have painted plastic casings or stickers of …
Q 78 May (update) 2018: Is there a limit to the level of damage to a POI that may be ‘covered up’ without casing replacement? A No. It is easy to either cut out a suitable part from a mechanical sample (obtained during identification) or 3D print a part for the replacement area. Paint or stickers can easily hide any seams or damage as it is common in the marketplace for deployed POIs to have painted plastic casings or stickers …
Modified
p. 25 → 26
Q 81 July 2017: For purposes of PCI acceptance, a draft standard is a document that either has been published as a draft for trial use (e.g., ISO FDIS) or has been published as a draft for public comment (e.g., NIST drafts). A However, ANSI (X9) does neither of these and further clarification must be made. For purposes of PCI acceptance, an ANSI (X9) draft standard is one that has been successfully balloted out of the assigned X9 working group …
Q 81 July 2017: For purposes of PCI acceptance, a draft standard is a document that either has been published as a draft for trial use (e.g., ISO FDIS) or has been published as a draft for public comment (e.g., NIST drafts). A However, ANSI (X9) does neither of these and further clarification must be made. For purposes of PCI acceptance, an ANSI (X9) draft standard is one that has been successfully balloted out of the assigned X9 working group …
Modified
p. 25 → 28
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 …
Q 90 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 …
Removed
p. 26
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 or modifying sensitive data must entail at least ten hours of exploitation time.
Modified
p. 27 → 30
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 …
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. 27 → 30
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 …
• 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 …
• If any of these keys are not zeroized, then other mechanisms must exist to disable …
Modified
p. 28 → 31
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. …
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 …
Modified
p. 29 → 32
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 …
Q 13 May (update) 2018: Requirement A1 states that a device uses tamper-detection and response mechanisms that cause it to become immediately inoperable. If the device is tampered, can it still be used to process non-PIN based payment card transactions? A A PIN-acceptance device that is tampered must immediately cease processing all PIN based payment card transactions. If implemented only one reset shall be supported unless the device is removed for inspection and repair. Any intervention enabling transactions, must require …
Modified
p. 29 → 32
a) Use of dual-control techniques;
Modified
p. 29 → 32
b) Provide accountability and traceability including logging of user IDs, date and time stamp, and actions performed;
Modified
p. 29 → 32
c) Sensitive information required for the authorization (e.g., passwords/authentication codes) is initialized or used in a way that prevents replay at the same or a different device.
Modified
p. 29 → 32
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.
Q 1 Is A3 intended to address the ICC reader security? A No. A3 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. 29 → 33
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 …
Q 2 May 2017: Are there any situations where the evaluation report does not have to provide an attack costing. A Yes for A4 (Monitoring During PIN Entry), where testing of any external characteristic available for monitoring demonstrably satisfying the applicable DTR test steps has not found any leakage, then it must be explained why any attack scenario cannot be feasible for less than 26 points, with a minimum of 13 for initial exploitation. In such a situation no formal …
Modified
p. 30 → 34
POI Requirements A7, B16 and E3.4
POI Requirements A6, B16 and E3.4
Modified
p. 30 → 34
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.
Q 1 Does “non-PIN data” include data that can be entered while the device is in a maintenance mode? A No. A6, B16, and E3.4 are applicable to the device while in its normal working mode. A6, B16, or E3.4 does not apply to data entered while the device is in special modes that are not intended to be accessed by cardholders and merchants.
Modified
p. 30 → 34
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 …
Q 3 The intent of A6, B16, and E3.4 is to eliminate the possibility that PIN values will be entered at an improper time and handled by the device in a non-secure manner. One way for a vendor to address A6, B16, or E3.4 is to allow for the entry of PIN values only. Would it be acceptable to allow the input of numerical data if the numerical data is three characters or less and therefore could not represent a …
Modified
p. 31 → 34
Q 5 The vendor chooses to comply with Requirement A7, B16, or E3.4. What criteria should a vendor use to determine which one to comply with? A7 applies to any components or paths containing plaintext display signals between the cryptographic processor and display unit. B16 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. E3.4 is appropriate for unattended devices that do not meet …
Q 5 The vendor chooses to comply with Requirement A6, B16, or E3.4. What criteria should a vendor use to determine which one to comply with? A6 applies to any components or paths containing plaintext display signals between the cryptographic processor and display unit. B16 applies to devices that allow for updates of prompts or use cryptography to communicate with a display, whether performed by the vendor or the acquirer. E3.4 is appropriate for unattended devices that do not meet …
Modified
p. 31 → 35
a) The signing device implements dual control mechanisms such that it is infeasible for a single person to sign user prompts.
Modified
p. 31 → 35
b) The signing device provides for all logging details as stipulated in the requirement.
Modified
p. 31 → 35
c) Compromise of a signing device does not compromise any other signing device.
Modified
p. 31 → 35
d) Compromise of a signing device does not affect the security of POI devices outside the domain of the signing device.
Modified
p. 31 → 35
e) POI devices outside the domain of any signing device cannot be modified to accept user prompts from other user prompt sources.
Modified
p. 31 → 35
f) The signing device is a single use device or is used in a restricted secure area.
Modified
p. 31 → 35
g) The vendor provides the secure operating procedures to the customer.
Modified
p. 32 → 35
Q 9 July 2017: For PEDs designed with multiple data acceptance interfaces, where there is a hard keypad dedicated to PIN (and other sensitive data) entry, and the other interface is a touch interface not intended to accept any sensitive data entry, what controls are required for the 2nd interface? A In this type of design, the following controls on the “non-sensitive” interface must be enforced, in addition to the existing restriction that applications must not ask for input of …
Q 9 December (update) 2017: For PEDs designed with multiple data acceptance interfaces, where there is a hard keypad dedicated to PIN (and other sensitive data) entry, and the other interface is a touch interface not intended to accept any sensitive data entry, what controls are required for the 2nd interface? A In this type of design, the following controls on the “non-sensitive” interface must be enforced, in addition to the existing restriction that applications must not ask for input …
Modified
p. 32 → 35
• If the x/y touch coordinates are sent to the authenticated applications on the device, the vendor must provide guidance to application developers to not ever send out touch coordinates. Additionally, the vendor also must review all applications and NOT sign/authenticate them if they are written to send out touch coordinates, thus not allowing them to be loaded.
• If the x/y touch coordinates are sent to the authenticated applications on the device, the vendor must provide guidance to application developers to not ever send out touch coordinates. Additionally, the vendor also must review all applications and NOT sign/authenticate them if they are written to send out touch coordinates, thus not allowing them to be loaded or
Modified
p. 32 → 36
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.
Q 2 Is the attack potential of 18 per device to be applied to a single device, or averaged over multiple devices? A A6 addresses an attack performed on a single device. If an attack has a potential of 18 to develop, A6 is met regardless of whether or not applying the attack to additional devices is less than 18.
Modified
p. 32 → 36
Q 3 Touch-screen devices offer multiple possibilities for the data entry: traditional PIN pad layout, QWERTY layout, signature capture, handwriting recognition, etc. Does A7 apply to all of these methods of data entry, or only the traditional PIN pad? A A7 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 3 Touch-screen devices offer multiple possibilities for the data entry: traditional PIN pad layout, QWERTY layout, signature capture, handwriting recognition, etc. Does A6 apply to all of these methods of data entry, or only the traditional PIN pad? A A6 applies to all methods of data entry that can be used by a cardholder to disclose their PIN, including QWERTY layout, signature capture, and handwriting recognition.
Modified
p. 33 → 36
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.
Q 2 When a device is not a handheld device, it must have a privacy shield to meet A7. Are there any special considerations if the shield is detachable? A A user’s guide must accompany the device that states that the privacy shield must be used to comply with ISO 9564. Optionally, the user’s guide can also reference PCI device requirements.
Modified
p. 33 → 36
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:
Q 4 Requirement A7 stipulates that the device must provide a means to deter the visual observation of PIN values as they are being entered by the cardholder. What methods are acceptable? A The POI Security Requirements provide for several options that may be used separately or in combination to provide privacy during PIN entry. These options are:
Modified
p. 34 → 37
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 …
Q 1 Requirement A9 states that the minimum attack potential for the removal of a secure component from its intended environment is 18 points. Does this figure include the cost required to produce and install an overlay bug after removal of the secure component? A 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. 35 → 38
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 …
Q 3 May (update) 2018: 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/authentication codes. Can a device have a function (e.g., a specified key-press sequence) to reset the passwords/authentication codes to their default values if the reset zeroizes all the secret keys …
Modified
p. 35 → 38
• The device is removed and a PIN-disclosing bug installed and then is reinstalled using the default passwords. Authorized staff may then load legitimate keys without detecting the tamper on the reinstalled device.
• The device is removed and a PIN-disclosing bug installed and then is reinstalled using the default passwords/authentication codes. Authorized staff may then load legitimate keys without detecting the tamper on the reinstalled device.
Modified
p. 36 → 39
a) Implementation of an authorized removal command to disable the removal sensors, and therefore also require an authorized replacement command to re-enable the sensors.
Modified
p. 36 → 39
b) Implementation of only an authorized replacement command, and reliance upon the removal sensors to automatically activate the removed state.
Modified
p. 36 → 39
c) Erasure of the secret keys whenever the device is removed, and then re-loading new keys once the device is re-installed.
Modified
p. 36 → 39
a) Erase all keys when removed or
Modified
p. 36 → 39
a) Erase all keys when removed or
Modified
p. 36 → 39
b) Go to an unauthorized state upon removal and require an authorized re-installation process.
Modified
p. 36 → 39
b) Go to an unauthorized state upon removal and require an authorized re-installation process.
Modified
p. 38 → 41
•either
•is
a) The authenticity checking of firmware•either internally and according to B4 or externally using appropriate procedures within a secured environment under the vendor’s control•is performed whenever the firmware is established in that secure area; and
Modified
p. 38 → 41
b) The effort to deliberately modify or replace the firmware or parts of it in order to get access to sensitive information (access to the memory device) must be addressed as an attack scenario under Requirements A1, A3, and A5 and meet the respective attack potentials; and
Modified
p. 38 → 41
c) A periodic integrity check according to Requirement B1 is performed for the firmware, ensuring that random changes will be detected; and if cryptographic authenticity is not performed, the integrity check must be cryptographically based. Although an algorithm using a secret key, such as a keyed hash, can be used, it is not necessary for meeting the integrity criteria.
Modified
p. 39 → 42
•critical
a) Source code reviews targeting specific relevant security•critical functionalities
Modified
p. 39 → 42
b) Vulnerability analysis; that includes gathering and considering evidence necessary to perform practical testing
Modified
p. 39 → 42
c) Penetration testing to validate the robustness of the device to protect against feasible attacks by addressing known attack methods. For example (but not restricted to) fuzzing; using appropriate tools and techniques
Modified
p. 39 → 42
d) Audits of relevant existing test evidence, which may be utilized where appropriate, by giving justifications for validity of evidence and test methodologies overall.
Removed
p. 40
• If both firmware versions fail authentication, the device fails in a secure manner.
Modified
p. 40 → 43
a) The new code is cryptographically authenticated prior to execution.
Modified
p. 40 → 43
b) If the new code fails authentication, the backup copy of code is cryptographically authenticated, and if the backup copy is successfully authenticated, the device boots from the backup copy and the backup is then used to overwrite the new code that failed authentication. c) If both firmware versions fail authentication, the device fails in a secure manner.
Modified
p. 41 → 44
a) For remote access, i.e. the files are delivered to the device across a private or public network, the use of a security protocol is required and must be validated.
Modified
p. 41 → 44
b) For manual access, i.e. where the operator has physical control of the terminal and the files, and the files are not delivered across a network, the device must ensure that the interface cannot be exploited (e.g., by restricting access/functionality on the interface, requiring administrative rights, using cryptographic authentication techniques, etc.) K9 states it is for remote access only and does not include a manual element, a security protocol would be required to ensure the interface cannot be exploited.
Modified
p. 43 → 46
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 …
Q 2 May (update) 2018: Under what circumstances is key entry via the device keypad permitted? A Plain-text secret keys cannot be entered into the device using the keypad. Plain-text key components may be entered via the keypad in accordance with ISO 11568-2. Encrypted keys may also be entered via the keypad. Entry of key components or encrypted keys must be restricted to authorized individuals. Functions used to enter keys must only be available when the device is placed in …
Modified
p. 43 → 46
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.
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.
Removed
p. 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 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 pre-expired and force a change upon initial use. Plain-text keys or their components are never permitted over a network connection.
(continued on next page)
(continued on next page)
Modified
p. 45 → 47
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 …
Q 1 May (update) 2018: B7 defines sensitive functions as those functions that access sensitive data, such as cryptographic keys, and that authentication is required for such access. The guidance note for B7 stipulates that authentication shall be considered as dual-control techniques when entering sensitive information through a secure user interface, or cryptographic techniques when entering electronic data. The use of other techniques to access sensitive services results in the device being unable to use previously existing keying material. How …
Modified
p. 45 → 47
Entry of key components without the use of at least two separate passwords/PINs results in the zeroization of pre-existing secret keys, i.e., the invoking of the key-loading function/command causes the zeroization prior to the actual loading of the new key. 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 …
Entry of key components without the use of at least two separate passwords/authentication codes results in the zeroization of pre-existing secret keys, i.e., the invoking of the key- loading function/command causes the zeroization prior to the actual loading of the new key. For devices supporting multiple key hierarchies (e.g., multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized. In all cases, the authentication values (passwords, authentication codes or similar) for …
Modified
p. 45 → 48
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 …
Injection of plain-text secret keys or their components/shares where the device does not itself require the use of at least two passwords/authentication codes for injection results in the zeroization of pre-existing secret keys. For devices supporting multiple key hierarchies (e.g., multi-acquirer devices), only the hierarchy (specific TMK and working keys) associated with the key being loaded must be zeroized. In all cases, the authentication values (passwords, authentication codes or similar) for each user on a given device must be different …
Modified
p. 47 → 50
Q 5 PCI PIN Security Requirement 20 states that all secret and private cryptographic keys ever-present and used for any function (e.g., key-encipherment or PIN-encipherment) by a transaction-originating terminal (device) that processes PINs must be unique (except by chance) to that device. How does this requirement apply to device testing? A Devices must implement unique secret and private keys for any function directly or indirectly related to PIN protection. The basic rule is that any private or secret key resident …
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 …
Modified
p. 49 → 52
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 …
Q 11 May (update) 2018: Remote key distribution using asymmetric techniques methodologies must provide for protection against man-in-the-middle attacks and the hijacking of PIN- acceptance devices where the devices are under a PKI hierarchy that facilitates more than one acquirer (e.g., a hierarchy under a PIN-acceptance device vendor’s Root). In order to achieve this, many vendors have implemented techniques that force the PIN-acceptance device to “bind” to a specific transaction-processing host’s certificate, and not accept commands digitally signed by any …
Modified
p. 49 → 52
a) The existing bound host can digitally sign an “unbind” command to the PIN-acceptance device, that when validated returns the PIN-acceptance device to its original unbound state.
Modified
p. 49 → 52
b) In situations where the bound host’s private key is not available to sign the command, or other similar scenarios, a forced decommission may occur. However, any such decommission done remotely requires a cryptographic (digital signature, MAC, etc.) technique, and must be unique per PIN-acceptance device.
Modified
p. 49 → 52
c) Decommissions may also be done manually directly at the device, using system administration menus that authenticate users via PINs, passphrases, etc.
Modified
p. 50 → 53
a) For devices under a PKI hierarchy that facilitates more than one acquirer (e.g., a hierarchy under a PIN-acceptance device vendor’s root), an acceptable technique is to 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. This is frequently done at initialization of a new PIN-acceptance device, and subject to unbinding techniques as noted in another FAQ.
Modified
p. 50 → 53
b) The acquirer KDH public key can be loaded only once and requires a factory return (preceded by a zeroization of acquirer keys function) to put the device back to ready state.
Modified
p. 50 → 53
c) An acquirer specific PKI hierarchy can be implemented. For this scenario, because of the rigor of criteria for operating a Certification Authority, it is best to have the PIN-acceptance device vendor operate the hierarchy, or else use a company that provides professional Certification Authority services.
Modified
p. 50 → 53
d) Certificate Revocation Lists can be distributed to the device to identify compromised key distribution hosts. This requires that device vendors maintain and distribute the CRLs for KDH keys that are part of their remote key distribution PKI. It further requires that the CRLs have a lifetime not to exceed one week to minimize the exposure window. Furthermore, it requires that the device cease processing if it does not possess a valid unexpired CRL.
Modified
p. 50 → 53
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 …
Q 13 Version 2 and higher 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 …
Removed
p. 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 seven characters.
Modified
p. 51 → 55
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:
Q 19 May (update) 2018: 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. 51 → 55
a) The conversion from a less secure methodology (non-TR-31 or non-TR-31 equivalent) to a more secure (TR-31 or equivalent) methodology must be nonreversible.
Modified
p. 51 → 55
b) When entering the plain-text KBPK (or equivalent) through the keypad, it must be entered as two or more components and require the use of at least two passwords/authentication codes. The passwords/authentication codes must be entered through the keypad or else conveyed encrypted into the device.
Modified
p. 52 → 55
c) Loading of a plaintext KBPK (or equivalent) using a key loader must be done using dual control and require the use of two or more passwords/authentication codes before injection of the key. These passwords/authentication codes are entered directly through the keypad of the applicable device or are conveyed encrypted into the device and must be at least seven characters in length. These passwords/authentication codes must either be unique per device (and per custodian), except by chance, or if vendor …
Modified
p. 52 → 55
Injection of plain-text secret keys or their components where the receiving device does not itself require the use of at least two PINs/passwords for injection results in the zeroization of pre-existing acquirer secret keys. For devices supporting multiple-acquirer key hierarchies (e.g., multi-acquirer devices), only the hierarchy (e.g., 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 …
Injection of plain-text secret keys or their components where the receiving device does not itself require the use of at least two passwords/authentication codes for injection results in the zeroization of pre-existing acquirer secret keys. For devices supporting multiple- acquirer key hierarchies (e.g., multi-acquirer devices), only the hierarchy (e.g., specific TMK and working keys) associated with the key being loaded must be zeroized. In all cases, the authentication values (passwords, authentication codes or similar) for each user on a given …
Modified
p. 52 → 55
d) It is not permitted to load the KBPK to the device encrypted by a non-TR-31 or non-TR-31 equivalent symmetric key. However, the KBPK may be loaded using asymmetric techniques.
Modified
p. 53 → 56
a) The key-usage information of any downloaded key must be cryptographically bound to the key value using accepted methods, and the device must enforce that the key is only used for the intended use.
Modified
p. 53 → 56
b) The addition of a new key type (slot) subsequent to the initial configuration of the device causes the zeroization of all other secret keys, Devices supporting remote key-distribution techniques using asymmetric techniques shall only support the use of such techniques for the loading of TMKs. Support shall not exist to use remote key-distribution techniques for working keys (e.g., PIN, data, MAC, etc.) unless the key-usage information is cryptographically bound to each individual key.
Modified
p. 53 → 56
c) Downloaded data key types must not be accepted by the device unless enciphered by a different terminal master key than sensitive keys such as the PEK or MAC key types.
Modified
p. 53 → 56
d) The device does not provide any support for a decrypt data or similar function.
Modified
p. 53 → 56
e) The device must ensure that keys with different purposes can never have the same value; this requirement must be maintained until the device is decommissioned (or until the applicable TMK(s) changes).
Modified
p. 53 → 56
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.
Q 24 May (update) 2018: Can secret keys or their components be used for other purposes such as passwords/authentication codes to enable the use of sensitive services? A No. The use of secret keys or their components for other purposes violates the requirement that keys be used for their sole intended purpose, e.g., key encipherment or PIN encipherment, etc.
Modified
p. 54 → 57
a) Specific menu commands to zeroize stored keys
Modified
p. 54 → 57
b) Inducement of a tamper event to zeroize those keys
Modified
p. 54 → 57
c) Encryption by a key of equal or greater strength that is itself zeroized, i.e., only cryptograms of the protected keys are recoverable.
Modified
p. 56 → 64
Q 9 Can USB authentication tokens or smart cards be considered to be the SCD required to enforce dual control under B16? A The use of dual tokens alone would not meet the requirement. The tokens would need to enforce the use of passwords, and they would need to include security to protect their contents.
Q 9 May (update) 2018: Can USB authentication tokens or smart cards be considered to be the SCD required to enforce dual control under B16? A The use of dual tokens alone would not meet the requirement. The tokens would need to enforce the use of passwords/authentication codes, and they would need to include security to protect their contents.
Modified
p. 57 → 65
This is not to infer that the device must force the implementation, but that it must provide support for such an implementation. Note this FAQ is effective 1 July 2015
This is not to infer that the device must force the implementation, but that it must provide support for such an implementation. Note this FAQ is effective 1 July 2015 POI Requirement B18
Modified
p. 58 → 66
Q 2 June 2015: Is there any impact on the device’s approval if the laboratory evaluated security policy is changed by the vendor? A Under V4, the content of the security policy is part of the evaluation of a device by the laboratory and is an integral input upon which the approval of a device is based. Deployers rely on the security policy in order to ensure that they do not breach the conditions of a device's approval. Any change …
Q 2 June 2015: Is there any impact on the device’s approval if the laboratory evaluated security policy is changed by the vendor? A Beginning with V4, the content of the security policy is part of the evaluation of a device by the laboratory and is an integral input upon which the approval of a device is based. Deployers rely on the security policy in order to ensure that they do not breach the conditions of a device's approval. Any …
Modified
p. 58 → 66
Q 3 August 2022: Vendors can have various options for both hardware and firmware that may be either security or non-security relevant. For non-security relevant options, vendors are allowed to designate in their hardware/firmware identifiers a lower case ‘x’ in the relevant position. Security relevant options must have specific numbers and/or letters assigned and listed as part of the approval. The program guide specifies that options, both security and non-security relevant must be clearly defined and documented as to the …
Q 4 August 2022: Vendors can have various options for both hardware and firmware that may be either security or non-security relevant. For non-security relevant options, vendors are allowed to designate in their hardware/firmware identifiers a lower case ‘x’ in the relevant position. Security relevant options must have specific numbers and/or letters assigned and listed as part of the approval. The program guide specifies that options, both security and non-security relevant must be clearly defined and documented as to the …
Modified
p. 60 → 67
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.
Q 6 May (update) 2018: 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 …
Modified
p. 60 → 67
a) 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. 60 → 68
b) Key hierarchies can only be established in accordance with Requirement B7. New key hierarchies must be authenticated using dual control (passwords/authentication codes) either via the key loader or directly via the EPP or POS PED. Existing key hierarchies may be replaced without using authentication if the loading results in the zeroization of pre- existing secret keys, i.e., the invoking of the key-loading function/command causes the zeroization prior to the actual loading of the new key. In addition, existing key …
Modified
p. 61 → 70
a) The ICCR slot entry area must be designed such that a cardholder has a full unlimited view of the housing surrounding the card slot opening. The card entry area should be extended to make it easier to observe the card slot area
Modified
p. 61 → 70
b) The part of the cover below the slot must be in a light color, for example white or silver, to improve visibility of the area and to make identification of any wires easier
Modified
p. 61 → 70
c) The ICCR contacts must be strongly protected to prevent attachment of bug wires
Modified
p. 61 → 70
d) There must not be any seams around the slot that can be used to hide wires
Modified
p. 61 → 70
e) 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. 61 → 70
f) The maximum angle of the ICCR slot with the horizon should be no more than a maximum of 70 degrees.
Modified
p. 61 → 70
g) The installation guidance and security policy must stipulate the allowed installation height ensuring a sufficient view on the card slot entry area and the lab must validate that when the device is set at the minimum height the area around the slot is visible.
Modified
p. 63 → 72
a) The application must reside and execute within the physically and logically secure boundary of the target of evaluation.
Modified
p. 63 → 72
b) The application must be cryptographically authenticated by the secure chip of the POI using algorithms and keys sizes consistent with those stipulated in K4.
Removed
p. 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.
•it only provides the data to an authenticated application. The firmware does not allow any other mechanism for card data export.
Modified
p. 65 → 75
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:
Q 2 December (update) 2017: 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. 65 → 75
•i.e.,
•the
a) 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. 65 → 75
b) Where a device can be configured to enter a state where all account data is not encrypted, the transition to or from this state is treated as a sensitive service.
Modified
p. 65 → 75
c) 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 is treated as a …
Modified
p. 65 → 75
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 …
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. 66 → 76
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).
3. Be subject to an independent expert review and said review is publicly 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. 67 → 77
a) The method of encryption used must ensure that the output produces a unique cryptogram each time that is statistically uncorrelated with any previous encrypted message across its whole length, even if the same input is used.
Modified
p. 67 → 77
b) The transaction message must be formatted and constructed by firmware/application code resident within the POI that is authenticated by using cryptographic techniques consistent with B4.