Document Comparison
PCI_PTS_POI_v3_1_Summary_Of_Changes.pdf
→
PCI_PTS_POI_v4_Summary_Of_Changes.pdf
11% similar
6 → 14
Pages
1181 → 3565
Words
21
Content Changes
Content Changes
21 content changes. 14 administrative changes (dates, page numbers) hidden.
Added
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.
Additional Guidance SR General 5 Main Differences from Prior Version Section updated.
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 …
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.
Additional Guidance SR General 5 Main Differences from Prior Version Section updated.
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 …
Added
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.
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.
Added
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 …
Added
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:
Applicability of Requirements 44-47 Modified to reflect aforementioned changes adding, moving and deleting requirements.
Requirement SR Appendix B:
Applicability of Requirements 44-47 Modified to reflect aforementioned changes adding, moving and deleting requirements.
Added
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 …
Added
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 …
Added
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 …
Added
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. 1
Payment Card Industry (PCI) PTS POI Security Requirements Summary of Changes from PCI PTS POI Version 3.0 to 3.1
Removed
p. 2
SR K12 34 If the device allows updates of firmware, the device cryptographically authenticates the firmware and if the authenticity is not confirmed, the firmware update is rejected and deleted.
Modified
p. 2 → 5
Requirement SR K18 35 The key-management techniques implemented in the device are consistent with B11.
Requirement SR K11 - version 3 - Deleted requirement and specified compliance in Core requirement B1: The device performs self-tests consistent with B1.
Modified
p. 2 → 5
Requirement SR K20 35 If the device permits access to internal areas (e.g., for service or maintenance), it is not possible using this access area to insert a bug that would disclose any secret or private keys or account data. Immediate access to secret or private keys or account data is either prevented by the design of the internal areas (e.g., by enclosing components with such data into tamper- resistant/responsive enclosures), and/or it has a mechanism so that accessing internal …
Requirement SR K20 • version 3 - Deleted in the same manner as requirement A3: If the device permits access to internal areas (e.g., for service or maintenance), it is not possible using this access area to insert a bug that would disclose any secret or private keys or account data. Immediate access to secret or private keys or account data is either prevented by the design of the internal areas (e.g., by enclosing components with such data into tamper- …
Removed
p. 3
Requirement SR K23 35 The following features of the device’s operating system must be in place: The operating system of the device must contain only the software (components and services) necessary for the intended operation. The operating system must be configured securely and run with least privilege. The security policy enforced by the device must not allow unauthorized or unnecessary functions. API functionality and commands that are not required to support specific functionality must be disabled (and where possible, removed).
Requirement SR K24 36 Access to sensitive services requires authentication. Sensitive services provide access to the underlying sensitive functions. Sensitive functions are those functions that process sensitive data such as cryptographic keys, account data, and passwords. Entering or exiting sensitive services shall not reveal or otherwise affect sensitive data.
Requirement SR K18 (old)
• deleted to reflect addition of K24 and K25 above 35 If the device allows access …
Requirement SR K24 36 Access to sensitive services requires authentication. Sensitive services provide access to the underlying sensitive functions. Sensitive functions are those functions that process sensitive data such as cryptographic keys, account data, and passwords. Entering or exiting sensitive services shall not reveal or otherwise affect sensitive data.
Requirement SR K18 (old)
• deleted to reflect addition of K24 and K25 above 35 If the device allows access …
Modified
p. 3
Requirement SR K11.1 34 Combined prior K12 with K11.1 The firmware must confirm the authenticity of all applications loaded onto the terminal consistent with B4. If the device allows software application and/or configuration updates, the device cryptographically authenticates all updates consistent with B4.
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.
Modified
p. 3 → 5
Requirement SR K25 36 Sensitive services are protected from unauthorized use consistent with B8.
Requirement SR K13 33 Rephrased: The device’s functionality shall not be influenced by logical anomalies consistent with B2.
Removed
p. 4
Requirement SR Glossary 49 Modified Secure Components definition to include protection of account data Additional Guidance SR Appendix B:
Applicability of Requirements 44-7 Modified to reflect requirements applicable to the Secure Card Reader Approval Class Additional Guidance DTR B1 16 Synchronized guidance with FAQs on use of SHA-2 vs. SHA-1.
Additional Guidance DTR B11 29 Synchronized guidance with FAQs on allowed key loading mechanisms for unattended devices.
Additional Guidance DTR B13 34 Synchronized guidance with FAQs on key uniqueness checking.
Additional Guidance DTR B18 42 Added additional guidance on implementation of least privilege and what constitutes sensitive functionality Additional Guidance DTR D4 49 Synchronized guidance with FAQs on where authentication of public keys used for offline transactions must occur.
Additional Guidance DTR F4 70 Corrected requirement statement to correctly encompass link layer as in scope Requirement DTR K1.1 96 Added guidance on protection of contactless account data Additional Guidance DTR K9 105 Added guidance on …
Applicability of Requirements 44-7 Modified to reflect requirements applicable to the Secure Card Reader Approval Class Additional Guidance DTR B1 16 Synchronized guidance with FAQs on use of SHA-2 vs. SHA-1.
Additional Guidance DTR B11 29 Synchronized guidance with FAQs on allowed key loading mechanisms for unattended devices.
Additional Guidance DTR B13 34 Synchronized guidance with FAQs on key uniqueness checking.
Additional Guidance DTR B18 42 Added additional guidance on implementation of least privilege and what constitutes sensitive functionality Additional Guidance DTR D4 49 Synchronized guidance with FAQs on where authentication of public keys used for offline transactions must occur.
Additional Guidance DTR F4 70 Corrected requirement statement to correctly encompass link layer as in scope Requirement DTR K1.1 96 Added guidance on protection of contactless account data Additional Guidance DTR K9 105 Added guidance on …
Modified
p. 4 → 9
Additional Guidance DTR B4 20 Added guidance for modules authenticating software.
Additional Guidance DTR B4 37-39 Added additional detailed steps to determine the adequacy of firmware authentication process.
Modified
p. 4 → 9
Additional Guidance DTR E4.1 63-4 Added additional guidance and test validation steps for unauthorized removal detection.
Additional Guidance DTR B7 46-48 Added additional detailed steps to validate device protections of sensitive services.
Removed
p. 5
Requirement VQ E4.1 47 Added question regarding whether the integrated devices possesses secure components previously assessed under A11.
Modified
p. 5 → 12
Additional Guidance VQs K11.1, K12, K18, K20, K21, K22, K23, Mult. VQs added/updated to reflect corresponding changes in Security Requirements as noted above.
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.
Modified
p. 6 → 14
Requirement To reflect the addition or modification or deletion of requirements for the addition of non-PIN acceptance devices to testing or for additional general criteria not impacting testing
Requirement To reflect the addition or modification or deletion of requirements.