Document Comparison
PCI_PTS_POI_v4_Summary_Of_Changes.pdf
→
Point_of_Interaction_(POI)_Modular_Security_Requirements_Summary_of_Changes_v4.1.pdf
4% similar
14 → 7
Pages
3565 → 1771
Words
22
Content Changes
Content Changes
22 content changes. 16 administrative changes (dates, page numbers) hidden.
Added
p. 2
PCI PTS POI Summary of Changes This document provides a summary of changes to the PTS POI version 4.0 family of documents from version 4.0 to version 4.1. Section 1 below provides an overview of the types of changes included in Version 4.1. Section 2 on the following pages provides a summary of material changes.
Section 1: Documents and Change Types Abbreviation Document Title SR PCI PTS POI Modular Security Requirements DTR PCI PTS POI Modular Derived Test Requirements VQ PCI PTS POI Modular Evaluation Vendor Questionnaire Change Type Definition Additional Guidance Explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic.
Section 1: Documents and Change Types Abbreviation Document Title SR PCI PTS POI Modular Security Requirements DTR PCI PTS POI Modular Derived Test Requirements VQ PCI PTS POI Modular Evaluation Vendor Questionnaire Change Type Definition Additional Guidance Explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic.
Added
p. 3
Section 2: Summary of Material Changes Document and Reference Change Type Security Requirements SR General Modified PTS Approval Modules Selection Flow Diagram to clarify that EPPs may go through the Integration, Open Protocols, and SRED modules.
Device management in this document covers up to the point of initial key loading for payment transaction keys (keys used by the acquiring organization) or at the facility of initial deployment; and Subsequent to receipt of the device at the initial key-loading facility or at the facility of initial deployment, the responsibility for the device falls to the acquiring financial institution and its agents (e.g., merchants and processors).
Additional Guidance SR B4.2 Added a new Core requirement for the vendor to provide a documented and defined process for how signing mechanisms must be implemented for the signing of display prompts and application code in order to be authenticated.
Requirement Change SR Section J Added new …
Device management in this document covers up to the point of initial key loading for payment transaction keys (keys used by the acquiring organization) or at the facility of initial deployment; and Subsequent to receipt of the device at the initial key-loading facility or at the facility of initial deployment, the responsibility for the device falls to the acquiring financial institution and its agents (e.g., merchants and processors).
Additional Guidance SR B4.2 Added a new Core requirement for the vendor to provide a documented and defined process for how signing mechanisms must be implemented for the signing of display prompts and application code in order to be authenticated.
Requirement Change SR Section J Added new …
Added
p. 6
Requirement Change DTR I4 Mutual authentication is now provided for instead of only server authentication.
Requirement Change DTR K3 Added additional guidance:
If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key-encipherment algorithm(s) used as stipulated in Appendix D, they do not need to be considered.
Additional Guidance DTR K4 Added additional guidance:
The independent expert must be qualified via a combination of education, training, and experience in cryptology to provide objective technical evaluations that are independent of any ties to vendors and special interests. Independent expert qualifications are further defined in the glossary.
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 …
Requirement Change DTR K3 Added additional guidance:
If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key-encipherment algorithm(s) used as stipulated in Appendix D, they do not need to be considered.
Additional Guidance DTR K4 Added additional guidance:
The independent expert must be qualified via a combination of education, training, and experience in cryptology to provide objective technical evaluations that are independent of any ties to vendors and special interests. Independent expert qualifications are further defined in the glossary.
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 …
Added
p. 7
Impacts all requirements in Sections L and M.
Requirement Change DTR
• Appendix C: Configuration and Use of the sts Tool Updated sts guidance. Additional Guidance Vendor Questionnaire VQs Sections L and M
• Device Management New questions in support of new DTRs for Device Management Security Requirements.
Additional Guidance; Requirement Change
Requirement Change DTR
• Appendix C: Configuration and Use of the sts Tool Updated sts guidance. Additional Guidance Vendor Questionnaire VQs Sections L and M
• Device Management New questions in support of new DTRs for Device Management Security Requirements.
Additional Guidance; Requirement Change
Removed
p. 2
Submission by the vendor for assessment and publication on the PCI website of a user- available security policy addressing the proper use of the POI in a secure fashion, as further delineated in requirement B20.
Greater granularity and robustness of the underlying PCI-recognized laboratory test procedures for validation compliance of a device to these requirements as detailed in the Derived Test Requirements.
The reordering of the Core Physical Security Requirements The restructuring of the Open Protocols module The addition of a requirement for the vendor to provide a user-available security policy that will facilitate implementation of an approved POI device in a manner consistent with these requirements, including information on key- management responsibilities, administrative responsibilities, device functionality, identification, and environmental requirements Additional Guidance SR General 6 Modified process flow to include contactless readers.
Additional Guidance SR General 8 Updated references in Related Publications Additional Guidance SR General 9-13 …
Greater granularity and robustness of the underlying PCI-recognized laboratory test procedures for validation compliance of a device to these requirements as detailed in the Derived Test Requirements.
The reordering of the Core Physical Security Requirements The restructuring of the Open Protocols module The addition of a requirement for the vendor to provide a user-available security policy that will facilitate implementation of an approved POI device in a manner consistent with these requirements, including information on key- management responsibilities, administrative responsibilities, device functionality, identification, and environmental requirements Additional Guidance SR General 6 Modified process flow to include contactless readers.
Additional Guidance SR General 8 Updated references in Related Publications Additional Guidance SR General 9-13 …
Modified
p. 2 → 3
Additional Guidance SR General 5 Main Differences from Prior Version Section updated.
Additional Guidance SR General Further clarified that:
Removed
p. 3
Requirement SR A7, B16 and E3.4 16, 19, 24 Modified text describing applicability of the display prompt control requirements.
Additional Guidance SR B1 18 Added the highlighted text and rephrased the preceding text: The device performs a self-test, which includes integrity and authenticity tests upon start-up and at least once per day to check whether the device is in a compromised state. In the event of a failure, the device and its functionality fail in a secure manner. The device must reinitialize memory at least every 24 hours.
Requirement SR B4.1 Added a new Core requirement. Requirement previously existed only in K11.1: The firmware must support the authentication of applications loaded onto the terminal consistent with B4. If the device allows software application and/or configuration updates, the device cryptographically authenticates updates consistent with B4.
Additional Guidance SR B1 18 Added the highlighted text and rephrased the preceding text: The device performs a self-test, which includes integrity and authenticity tests upon start-up and at least once per day to check whether the device is in a compromised state. In the event of a failure, the device and its functionality fail in a secure manner. The device must reinitialize memory at least every 24 hours.
Requirement SR B4.1 Added a new Core requirement. Requirement previously existed only in K11.1: The firmware must support the authentication of applications loaded onto the terminal consistent with B4. If the device allows software application and/or configuration updates, the device cryptographically authenticates updates consistent with B4.
Removed
p. 4
Requirement SR D4 22 Consolidated D4.1, D4.2, D4.3 and D4.4 into a single comprehensive requirement: If the device encrypting the PIN and the ICC reader are not integrated into the same secure module, and the cardholder verification method is determined to be:
An enciphered PIN, the PIN block shall be enciphered between the device encrypting the PIN and the ICC reader using either an authenticated encipherment key of the IC card, or in accordance with ISO 9564. A plaintext PIN, the PIN block shall be enciphered from the device encrypting the PIN to the ICC reader (the ICC reader will then decipher the PIN for transmission in plaintext to the IC card) in accordance with ISO 9564. If the device encrypting the PIN and the ICC reader are integrated into the same secure module, and the cardholder verification method is determined to be:
An enciphered PIN, the PIN block …
An enciphered PIN, the PIN block shall be enciphered between the device encrypting the PIN and the ICC reader using either an authenticated encipherment key of the IC card, or in accordance with ISO 9564. A plaintext PIN, the PIN block shall be enciphered from the device encrypting the PIN to the ICC reader (the ICC reader will then decipher the PIN for transmission in plaintext to the IC card) in accordance with ISO 9564. If the device encrypting the PIN and the ICC reader are integrated into the same secure module, and the cardholder verification method is determined to be:
An enciphered PIN, the PIN block …
Removed
p. 5
Requirement SR H10
• version 3 - Deleted v3 requirement H10 and specified compliance in Core requirement B9. The security protocol makes use of a random generator that has been validated against NIST SP 800-22 or equivalent.
Requirement SR K1.2 32 Split out separate requirement from existing requirement K1.1: Failure of a single security mechanism does not compromise device security. Protection against a threat is based on a combination of at least two independent security mechanisms.
Requirement SR K11 - version 3 - Deleted requirement and specified compliance in Core requirement B1: The device performs self-tests consistent with B1.
Requirement SR K13 33 Rephrased: The device’s functionality shall not be influenced by logical anomalies consistent with B2.
Requirement SR K14 33 K14 and K15 combined and rephrased to reflect new structuring of Open Protocols Module: If the device is capable of communicating over an IP network or uses a public domain protocol (such as but …
• version 3 - Deleted v3 requirement H10 and specified compliance in Core requirement B9. The security protocol makes use of a random generator that has been validated against NIST SP 800-22 or equivalent.
Requirement SR K1.2 32 Split out separate requirement from existing requirement K1.1: Failure of a single security mechanism does not compromise device security. Protection against a threat is based on a combination of at least two independent security mechanisms.
Requirement SR K11 - version 3 - Deleted requirement and specified compliance in Core requirement B1: The device performs self-tests consistent with B1.
Requirement SR K13 33 Rephrased: The device’s functionality shall not be influenced by logical anomalies consistent with B2.
Requirement SR K14 33 K14 and K15 combined and rephrased to reflect new structuring of Open Protocols Module: If the device is capable of communicating over an IP network or uses a public domain protocol (such as but …
Removed
p. 6
Requirement SR M2 35 Requirement rewritten: Procedures are in place to transfer accountability for the device from the manufacturer to the facility of initial deployment. Where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment.
Requirement SR Appendix B:
Requirement SR Appendix B:
Modified
p. 6 → 3
Applicability of Requirements 44-47 Modified to reflect aforementioned changes adding, moving and deleting requirements.
Additional Guidance SR Appendix B: Applicability of Requirements Modified to reflect the additions of Requirement B4.2 and Section J.
Removed
p. 7
A device overview that summarizes the design and architecture and device features A review of the security-relevant features; including derivation of assets, threats and attacks A report summary that includes the tests (DTRs) performed with conclusions In support of some test steps, as directed by the test laboratory, the vendor must support the laboratory in various tasks (code review, fuzzing interfacing, DPA, etc.) to avoid prohibitively lengthy test activities. The vendor shall make source code available to the lab and provide assistance to make a systematic review of relevant security functions.
Note that a copy of the Vendor Questionnaire shall be submitted to the Report Portal along with the test report and any other supporting documents including, where applicable, the Open Protocols Module
• Protocol Declaration Form. For all DTRs, the tester shall state the following in writing: xxxxxx For all DTRs, the tester shall present sufficient information on …
Note that a copy of the Vendor Questionnaire shall be submitted to the Report Portal along with the test report and any other supporting documents including, where applicable, the Open Protocols Module
• Protocol Declaration Form. For all DTRs, the tester shall state the following in writing: xxxxxx For all DTRs, the tester shall present sufficient information on …
Modified
p. 8 → 5
Additional Guidance DTR A5 16-17 Added additional detailed steps to identify if any characteristics (e.g., emanations) available for monitoring from the device can be used to obtain PIN data.
Additional Guidance DTR B10 Added additional guidance for characteristics that prevent or significantly deter the use of the device for exhaustive PIN determination, stating:
Removed
p. 9
Additional Guidance DTR B2 32-33 Added additional detailed steps to validate that the device’s functionality is influenced by logical anomalies, including validation of all physical and logical interfaces.
Additional Guidance DTR B3 34-36 Added additional detailed steps and guidance to validate the adequacy of the vendor’s software development process for protecting the software from hidden and unauthorized or undocumented functions.
Additional Guidance DTR B5 43 Added additional detailed steps to assess protections against the differentiation of entered PIN data.
Additional Guidance DTR B6 44-45 Added additional detailed steps to determine that internal buffers cannot be used to determine sensitive information.
Additional Guidance DTR B8 49-50 Added additional detailed steps to protect against the unauthorized use of sensitive services.
Additional Guidance DTR B9 51-52 Added additional detailed steps and guidance to ensure it is generating numbers sufficiently unpredictable when used for security relevant functions. Scope now includes random numbers that are generated in connection with meeting …
Additional Guidance DTR B3 34-36 Added additional detailed steps and guidance to validate the adequacy of the vendor’s software development process for protecting the software from hidden and unauthorized or undocumented functions.
Additional Guidance DTR B5 43 Added additional detailed steps to assess protections against the differentiation of entered PIN data.
Additional Guidance DTR B6 44-45 Added additional detailed steps to determine that internal buffers cannot be used to determine sensitive information.
Additional Guidance DTR B8 49-50 Added additional detailed steps to protect against the unauthorized use of sensitive services.
Additional Guidance DTR B9 51-52 Added additional detailed steps and guidance to ensure it is generating numbers sufficiently unpredictable when used for security relevant functions. Scope now includes random numbers that are generated in connection with meeting …
Modified
p. 9 → 5
Additional Guidance DTR B4 37-39 Added additional detailed steps to determine the adequacy of firmware authentication process.
Additional Guidance DTR B20 Added an additional detailed step to ensure that the security policy includes any communication methods and protocols, including wireless, used by the device.
Modified
p. 9 → 5
Additional Guidance DTR B7 46-48 Added additional detailed steps to validate device protections of sensitive services.
Additional Guidance DTR B4 Added additional guidance:
Removed
p. 10
Additional Guidance DTR B11 55- 60, Added additional detailed steps to validate the adequacy of key-management techniques Additional Guidance DTR B12 61-62 Added additional detailed steps to validate the PIN-encryption technique implemented Additional Guidance DTR B13 63-64 Added additional detailed steps to ensure that it is not possible to encrypt or decrypt any arbitrary data using any cryptographic key.
Additional Guidance DTR B14 65 Added additional detailed steps to determine that clear-text PINs and clear-text cryptographic keys do not exist in unprotected environments.
Additional Guidance DTR B15 66 Added additional detailed steps to validate that the entry of any other transaction data is separate from the PIN-entry process Additional Guidance DTR B16 67-69 Added additional detailed steps to validate the adequacy of the logical management of display prompts Additional Guidance DTR B17 70-72 Added additional detailed steps to ensure the device enforces the separation between applications Additional Guidance DTR B18 73-74 Added …
Additional Guidance DTR B14 65 Added additional detailed steps to determine that clear-text PINs and clear-text cryptographic keys do not exist in unprotected environments.
Additional Guidance DTR B15 66 Added additional detailed steps to validate that the entry of any other transaction data is separate from the PIN-entry process Additional Guidance DTR B16 67-69 Added additional detailed steps to validate the adequacy of the logical management of display prompts Additional Guidance DTR B17 70-72 Added additional detailed steps to ensure the device enforces the separation between applications Additional Guidance DTR B18 73-74 Added …
Removed
p. 11
Additional Guidance DTR K3 124- Added additional detailed steps and guidance for the determination of secret and private keys in the device using both physical means and the monitoring of emanations Additional Guidance DTR K7 131 Added additional step to verify key uniqueness Additional Guidance DTR K8 132- Added additional detailed steps and guidance to validate that the device enforces that account data keys, key-encipherment keys, and PIN-encryption keys have different values and are appropriately used.
Additional Guidance DTR K10 135- Added additional detailed steps and guidance to validate the adequacy of the vendor’s software development process for protecting the software from hidden and unauthorized or undocumented functions.
Additional Guidance DTR K11.1 138- Added additional detailed steps to validate that the firmware confirms the authenticity of all applications Additional Guidance DTR K12 142- Added additional detailed steps to determine the adequacy of firmware authentication process.
Additional Guidance DTR K13 145- Added additional detailed …
Additional Guidance DTR K10 135- Added additional detailed steps and guidance to validate the adequacy of the vendor’s software development process for protecting the software from hidden and unauthorized or undocumented functions.
Additional Guidance DTR K11.1 138- Added additional detailed steps to validate that the firmware confirms the authenticity of all applications Additional Guidance DTR K12 142- Added additional detailed steps to determine the adequacy of firmware authentication process.
Additional Guidance DTR K13 145- Added additional detailed …
Removed
p. 12
Additional Guidance DTR K20 165- Added additional detailed steps to ensure the device enforces the separation between applications Additional Guidance DTR K21 167- Added additional detailed steps to validate that the operating system contains only the software necessary for the intended operation and is configured securely and run with least privilege.
Additional Guidance DTR K23 172- Added additional detailed steps to protect against the unauthorized use of sensitive services.
Additional Guidance DTRs B4.1, B20, K1.2, K14 and Open Protocols Module Mult. DTRs added/updated to reflect corresponding changes in Security Requirements as noted above.
Requirement DTR Appendix B 182- Updated attack calculation examples Additional Guidance DTR Appendix D 194 Added new Appendix to stipulate minimum and equivalent key sizes and strengths for approved algorithms Additional Guidance VQ General vii Updated references in Related Publications VQs Section A, B4.1, B16, B20, D4, Open Protocol Module, K14 Mult. VQs added/updated/moved/deleted to reflect corresponding changes in Security …
Additional Guidance DTR K23 172- Added additional detailed steps to protect against the unauthorized use of sensitive services.
Additional Guidance DTRs B4.1, B20, K1.2, K14 and Open Protocols Module Mult. DTRs added/updated to reflect corresponding changes in Security Requirements as noted above.
Requirement DTR Appendix B 182- Updated attack calculation examples Additional Guidance DTR Appendix D 194 Added new Appendix to stipulate minimum and equivalent key sizes and strengths for approved algorithms Additional Guidance VQ General vii Updated references in Related Publications VQs Section A, B4.1, B16, B20, D4, Open Protocol Module, K14 Mult. VQs added/updated/moved/deleted to reflect corresponding changes in Security …
Modified
p. 12 → 6
Additional Guidance DTR K22 169- Added additional detailed steps to validate device protections of sensitive services.
Additional Guidance DTR K16.1 Added additional guidance:
Removed
p. 14
Note: The changes above do not include those that are corrections of grammar or typographical errors or other rephrasing of existing statements.
Modified
p. 14 → 2
Requirement To reflect the addition or modification or deletion of requirements.
Requirement Change To reflect the addition or modification or deletion of requirements.