Document Comparison
Point_of_Interaction_(POI)_Modular_Security_Requirements_Summary_of_Changes_v5-1.pdf
→
POI_Security_Requirements_v6_Summary_of_Changes_5-1_to_6-0.pdf
13% similar
10 → 5
Pages
2323 → 827
Words
17
Content Changes
Content Changes
17 content changes. 12 administrative changes (dates, page numbers) hidden.
Added
p. 2
Document Abbreviations Used Abbreviation Document Referenced SR / SRs PCI PTS POI Modular Security Requirements DTR / DTRs PCI PTS POI Modular Derived Test Requirements
Added
p. 3
Table 2: Summary of Changes Document and Requirements Change Type General Eliminated PCI Vendor Questionnaire. PCI laboratories will solicit information using proprietary methods that provide more efficient support for the gathering of that information.
Additional Guidance General Migrated as applicable many technical FAQs into the Derived Test Requirements or the Device Testing and Approval Program Guide.
• Evaluation Module 1: Physical and Logical
• Evaluation Module 2: POS Terminal Integration
• Evaluation Module 3: Communications and Interfaces
• Evaluation Module 4: Life Cycle Security Requirement SR General Firmware expires three years from date of approval, but shall not expire past the overall approval expiration of the device. Every third year the firmware must be laboratory validated against specified DTRs.
Requirement SR General POI v6 chipsets must provide support for ECC. Requirement SR General Migrated SRED and Open Protocols requirements into new evaluation modules and eliminated separate Open Protocols and SRED modules.
Requirement SR General Added tracking of …
Additional Guidance General Migrated as applicable many technical FAQs into the Derived Test Requirements or the Device Testing and Approval Program Guide.
• Evaluation Module 1: Physical and Logical
• Evaluation Module 2: POS Terminal Integration
• Evaluation Module 3: Communications and Interfaces
• Evaluation Module 4: Life Cycle Security Requirement SR General Firmware expires three years from date of approval, but shall not expire past the overall approval expiration of the device. Every third year the firmware must be laboratory validated against specified DTRs.
Requirement SR General POI v6 chipsets must provide support for ECC. Requirement SR General Migrated SRED and Open Protocols requirements into new evaluation modules and eliminated separate Open Protocols and SRED modules.
Requirement SR General Added tracking of …
Added
p. 4
Additional Guidance DTRs Introduction Provided additional guidance for lab reporting criteria, including minimal contents of reports and minimal test activities.
Additional Guidance DTRs
• All Sections Enhanced robustness of test scripts throughout. Requirement DTR B9 AES check values can only be calculated by MACing an all- zero block using the CMAC algorithm as specified in ISO 9797-1. TDES must support the same method and may support the deprecated legacy method.
Requirement DTR B9 Devices must support key blocks as specified by ISO 20038 and/or the ANSI TR-31 key-derivation method. Other methods can only exist as specified in the guidance.
Requirement DTR B9 The TR-31 key-calculation (variant) method for key blocks is deprecated and no longer allowed.
Requirement DTRs B9
• B11 Fixed-key support has been eliminated as an acceptable key-management technique for both PIN and account data encryption. This applies to both AES and TDES.
Requirement DTR Appendix A Added guidance for handheld devices with touch screens. …
Additional Guidance DTRs
• All Sections Enhanced robustness of test scripts throughout. Requirement DTR B9 AES check values can only be calculated by MACing an all- zero block using the CMAC algorithm as specified in ISO 9797-1. TDES must support the same method and may support the deprecated legacy method.
Requirement DTR B9 Devices must support key blocks as specified by ISO 20038 and/or the ANSI TR-31 key-derivation method. Other methods can only exist as specified in the guidance.
Requirement DTR B9 The TR-31 key-calculation (variant) method for key blocks is deprecated and no longer allowed.
Requirement DTRs B9
• B11 Fixed-key support has been eliminated as an acceptable key-management technique for both PIN and account data encryption. This applies to both AES and TDES.
Requirement DTR Appendix A Added guidance for handheld devices with touch screens. …
Added
p. 5
Additional Guidance DTR Appendix H New Appendix: “Evaluation Guidance for CPUs.” Additional Guidance DTR Appendix I Modified Security Policy Layout Example for changes in DTR B20.
Modified
p. 1
Payment Card Industry (PCI) PTS POI Security Requirements Summary of Changes from PCI PTS POI Version 5.0 to 5.1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point-of-Interaction (POI) Summary of Requirements Changes from Version 5.1 to 6.0
Removed
p. 2
PCI PTS POI Summary of Changes This document provides a summary of changes to the PTS POI version 5.0 family of documents from version 5.0 to version 5.1. Section 1 below provides an overview of the types of changes included in Version 5.1. Section 2 on the following pages provides a summary of material changes.
Modified
p. 2
Table 1: Change Types Change Type Definition Additional Guidance Explanation, definition, and/or instruction to increase understanding or provide further information or guidance on a particular topic.
Modified
p. 2
Requirement Change To reflect the addition or modification or deletion of requirements.
Requirement Change To reflect the addition modification, deletion, or restructuring of requirements
Removed
p. 3
Section 2: Summary of Material Changes Document and Reference Change Type Security Requirements SR Related Publications Added additional ANSI and NIST reference documents. Additional Guidance SR Required Device Information Added check box for new Secure Card Reader PIN (SCRP) approval class.
Additional Guidance SR Evaluation Module Information Split out Key Management PIN Encryption between TDEA and AES.
Additional Guidance SR D1 Stipulated that new SCRP approval class requires an attack potential of 26 for identification and initial exploitation, with a minimum of 13 for exploitation.
Requirement SR K24 Added new requirement for secure enablement tokens required from the Software-based PIN on COTS (SPoC) monitoring system for operation of the SCRP.
Additional Guidance SR Glossary Added “Authentication Code,” “Commercial off-the-shelf (COTS),” ” Key-distribution host (KDH),” “Monitoring System,” “Monitor Token,” “SCRP,” and “SPoC”. Modified “Check Value.” Additional Guidance Derived Test Requirements DTR General Made additional modifications to introduction …
Additional Guidance SR Evaluation Module Information Split out Key Management PIN Encryption between TDEA and AES.
Additional Guidance SR D1 Stipulated that new SCRP approval class requires an attack potential of 26 for identification and initial exploitation, with a minimum of 13 for exploitation.
Requirement SR K24 Added new requirement for secure enablement tokens required from the Software-based PIN on COTS (SPoC) monitoring system for operation of the SCRP.
Additional Guidance SR Glossary Added “Authentication Code,” “Commercial off-the-shelf (COTS),” ” Key-distribution host (KDH),” “Monitoring System,” “Monitor Token,” “SCRP,” and “SPoC”. Modified “Check Value.” Additional Guidance Derived Test Requirements DTR General Made additional modifications to introduction …
Modified
p. 3 → 4
Requirement SR Appendix B Amended Applicability of Requirements for new SCRP approval class.
Requirement SR Appendix B Modified Applicability of Requirements to reflect restructure, including for Open Protocols and SRED.
Removed
p. 4
SCA tests shall be performed in accordance with Appendix F including the scope of side-channel testing necessary to validate the device’s compliance based on the identification of relevant keys below and taking into consideration the appropriateness of testing re-use and demonstrably effective countermeasures.
Additional Guidance DTR A8 Modified and added additional detail to test steps for MSR testing, including combined ICCR/MSR readers and for attacks installing a second MSR reader.
Additional Guidance DTR B1 Added clarification to guidance:
The device must perform an internal self-test automatically at least once every day, in addition to power-up (excludes wake-up from hibernation mode).
Additional Guidance DTR B2/K13 Added additional test step to clarify expectation for usage of ASLR.
Additional Guidance DTR B3/K10 Added additional guidance for code considered firmware for SCRs and SCRPs:
Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements, except for SCRs …
Additional Guidance DTR A8 Modified and added additional detail to test steps for MSR testing, including combined ICCR/MSR readers and for attacks installing a second MSR reader.
Additional Guidance DTR B1 Added clarification to guidance:
The device must perform an internal self-test automatically at least once every day, in addition to power-up (excludes wake-up from hibernation mode).
Additional Guidance DTR B2/K13 Added additional test step to clarify expectation for usage of ASLR.
Additional Guidance DTR B3/K10 Added additional guidance for code considered firmware for SCRs and SCRPs:
Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements, except for SCRs …
Removed
p. 5
For SCRPs and SCRs intended for use with commercial- off-the-shelf devicese.g., mobile phones and tabletsthe SCRPs and SCRs must respond with their model name/number, hardware version, firmware version(s), and a unique device identifier to a query from the payment application on the COTS device.
If done between physically and logically disparate components it must use a secure channel as follows:
• Each secure channel must provide mutual authentication to uniquely identify each component prior to exchanging sensitive data, as well as protect against MITM and replay attacks.
• Mutual authentication between the communicating components must be based on cryptography that aligns with Appendix E of this document, “Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.”
• Cryptographic keys used to establish secure channels between components and for data encryption must be unique, except by chance.
Additional Guidance DTR B5 Added additional guidance for touchscreens:
Digit presses on touch-screen devices should never be displayed.
Additional Guidance …
If done between physically and logically disparate components it must use a secure channel as follows:
• Each secure channel must provide mutual authentication to uniquely identify each component prior to exchanging sensitive data, as well as protect against MITM and replay attacks.
• Mutual authentication between the communicating components must be based on cryptography that aligns with Appendix E of this document, “Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.”
• Cryptographic keys used to establish secure channels between components and for data encryption must be unique, except by chance.
Additional Guidance DTR B5 Added additional guidance for touchscreens:
Digit presses on touch-screen devices should never be displayed.
Additional Guidance …
Removed
p. 6
Added test step for cryptographic keys used by SCRP in provisioning process, including that SCRPs shall only support encrypted key loading methods.
Additional Guidance/ Requirement DTR B12 Added additional guidance and test steps for PIN-block formats and key-management techniques required or additionally allowed to be used by SCRPs.
The Security policy should include the following sections:
• General Description (DTRs B20.2
• B20.6)
• Installation and Guidance (DTRs B20.7
•B20.18)
• Operation and Maintenance (DTRs B20.19
• B20.27)
• Security (DTRs B20.28
• B20.33) This is the minimum information that must be presented. Additional information may be presented.
See Appendix H for an example of an acceptable Security Policy layout.
Additional Guidance DTR D1 Added requirements for SCRP to test step, indicating attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for exploitation.
Requirement DTR D4 Added additional guidance for PIN blocks used with SCRP:
For an SCRP, this requirement is applied without consideration of the conveyance …
Additional Guidance/ Requirement DTR B12 Added additional guidance and test steps for PIN-block formats and key-management techniques required or additionally allowed to be used by SCRPs.
The Security policy should include the following sections:
• General Description (DTRs B20.2
• B20.6)
• Installation and Guidance (DTRs B20.7
•B20.18)
• Operation and Maintenance (DTRs B20.19
• B20.27)
• Security (DTRs B20.28
• B20.33) This is the minimum information that must be presented. Additional information may be presented.
See Appendix H for an example of an acceptable Security Policy layout.
Additional Guidance DTR D1 Added requirements for SCRP to test step, indicating attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for exploitation.
Requirement DTR D4 Added additional guidance for PIN blocks used with SCRP:
For an SCRP, this requirement is applied without consideration of the conveyance …
Modified
p. 6 → 3
Additional Guidance/ Requirement DTR B20 Added additional guidance:
Additional Guidance SR General Reorganized requirements into four Evaluation Modules:
Removed
p. 7
Where the interface is supplied by an OEM module:
• If the module is under the control of the firmware and runs in the same space as the firmware, the OEM interface module must still be assessed to ensure that secure pairing (for wireless technologies listed above) is provided for and that secure communications is enforced by the interface.
• If an independent OEM module is used:
• The protocol and the pairing mechanism must be assessed; and
• The security of the link between the module and the firmware must be assessed.
• If the OEM module shares resources with the rest of the device, a vulnerability assessment is required to ensure that the OEM module cannot adversely impact the function of the device.
OEM modules that are found to have unaddressed exploitable vulnerabilities may result in the removal of the entire POI device approval.
Note: If the device implements an IP stack, the device must …
• If the module is under the control of the firmware and runs in the same space as the firmware, the OEM interface module must still be assessed to ensure that secure pairing (for wireless technologies listed above) is provided for and that secure communications is enforced by the interface.
• If an independent OEM module is used:
• The protocol and the pairing mechanism must be assessed; and
• The security of the link between the module and the firmware must be assessed.
• If the OEM module shares resources with the rest of the device, a vulnerability assessment is required to ensure that the OEM module cannot adversely impact the function of the device.
OEM modules that are found to have unaddressed exploitable vulnerabilities may result in the removal of the entire POI device approval.
Note: If the device implements an IP stack, the device must …
Removed
p. 8
DTRs A1.8, A1.11, and A1.13 must be completed for the ICCR where any specific references to “PIN” are to be read as “account data.” Modified test step to call out testing for contactless and manual PAN entry.
Additional Guidance DTR K4 Added guidance from existing FAQs on key management for SRED:
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 Fixed key implementations.
Additional Guidance DTR K11.2 Added guidance and test step on documentation and usage of APIs:
The vendor must provide to the PCI PTS laboratory a guidance document that states the exact scope of the PTS evaluated firmware (down to the level, including version, of libraries and binaries). This shall include all security-relevant APIs to confirm that they are used by …
Additional Guidance DTR K4 Added guidance from existing FAQs on key management for SRED:
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 Fixed key implementations.
Additional Guidance DTR K11.2 Added guidance and test step on documentation and usage of APIs:
The vendor must provide to the PCI PTS laboratory a guidance document that states the exact scope of the PTS evaluated firmware (down to the level, including version, of libraries and binaries). This shall include all security-relevant APIs to confirm that they are used by …
Removed
p. 9
Additional Guidance/ Requirement Program Guide PG
• Section 1 Modified Related Publications text. Additional Guidance PG
• Section 2 Modified the Device Management Requirements text to be consistent with SR and DTR documentation.
Additional Guidance PG
• Section 3 Added a reporting requirement for PTS vendors on firmware maintenance and modifications:
As of 1 May, the vendor must complete and submit to PCI an Attestation of Validation (AOV) confirming adherence to the program guide•i.e., either the firmware has not been amended or the changes made are within the wildcard parameters or the changes were submitted for evaluation. For devices supporting open protocols, the vendor must provide evidentiary materials that an auditable record of an ongoing vulnerability assessment process exists by providing a copy of the vendor’s sign-off form specified in Requirement G1. This applies to all unexpired approvals that exist for the vendor as of 31 December of the prior year. Failure to submit the …
• Section 1 Modified Related Publications text. Additional Guidance PG
• Section 2 Modified the Device Management Requirements text to be consistent with SR and DTR documentation.
Additional Guidance PG
• Section 3 Added a reporting requirement for PTS vendors on firmware maintenance and modifications:
As of 1 May, the vendor must complete and submit to PCI an Attestation of Validation (AOV) confirming adherence to the program guide•i.e., either the firmware has not been amended or the changes made are within the wildcard parameters or the changes were submitted for evaluation. For devices supporting open protocols, the vendor must provide evidentiary materials that an auditable record of an ongoing vulnerability assessment process exists by providing a copy of the vendor’s sign-off form specified in Requirement G1. This applies to all unexpired approvals that exist for the vendor as of 31 December of the prior year. Failure to submit the …