Document Comparison
P2PE_Standard_v2.0_r1.2.pdf
→
P2PE_v3.0_Standard.pdf
41% similar
294 → 262
Pages
117540 → 97148
Words
1480
Content Changes
From Revision History
- September 2011 1.0
Content Changes
1480 content changes. 238 administrative changes (dates, page numbers) hidden.
Added
p. 8
4A Use approved decryption devices.
4B Secure the decryption environment.
4C Monitor the decryption environment and respond to incidents.
4D Implement secure, hybrid decryption processes.
4E Component providers ONLY: report status to solution providers.
Control Objective 1 Account data is processed using equipment and methodologies that ensure they are kept secure.
Control Objective 2 Account data keys and key-management methodologies are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
Control Objective 3 Keys are conveyed or transmitted in a secure manner.
Control Objective 4 Key loading is handled in a secure manner.
Control Objective 5 Keys are used in a manner that prevents or detects their unauthorized usage.
Control Objective 6 Keys are administered in a secure manner.
Control Objective 7 Equipment used to process account data and keys is managed in a secure manner.
5A Account data is processed using algorithms and methodologies that ensure …
4B Secure the decryption environment.
4C Monitor the decryption environment and respond to incidents.
4D Implement secure, hybrid decryption processes.
4E Component providers ONLY: report status to solution providers.
Control Objective 1 Account data is processed using equipment and methodologies that ensure they are kept secure.
Control Objective 2 Account data keys and key-management methodologies are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
Control Objective 3 Keys are conveyed or transmitted in a secure manner.
Control Objective 4 Key loading is handled in a secure manner.
Control Objective 5 Keys are used in a manner that prevents or detects their unauthorized usage.
Control Objective 6 Keys are administered in a secure manner.
Control Objective 7 Equipment used to process account data and keys is managed in a secure manner.
5A Account data is processed using algorithms and methodologies that ensure …
Added
p. 12
− A merchant as a solution provider can perform all domains (including Appendix A) in their entirety.
• For software with access to clear-text account data intended for use on POI devices Domain 3
• Security requirements for management of the P2PE solution
• Maintenance of PCI DSS compliance for the decryption environment Domain 5
• Security requirements for P2PE key-management operations
• For software with access to clear-text account data intended for use on POI devices Domain 3
• Security requirements for management of the P2PE solution
• Maintenance of PCI DSS compliance for the decryption environment Domain 5
• Security requirements for P2PE key-management operations
Added
p. 16
• P2PE Component Provider types
• The P2PE Delta Change process.
Note: The PCI SSC does not approve or list merchant-managed solutions (MMS) on its website. Refer to the Program Guide for more information on MMS.
• The P2PE Delta Change process.
Note: The PCI SSC does not approve or list merchant-managed solutions (MMS) on its website. Refer to the Program Guide for more information on MMS.
Added
p. 17
Diagram 1: Example P2PE Implementation at a Glance Key Management and Remote/Local Cryptographic Key Loading Hardware Security Module (FIPS 140-2 or PCI HSM Approved) P2PE Key Management and Cryptography Account Data Application 1 Account Data Application 2 Non-account Data Application 3 P2PE Key Management and Cryptography Plain-text account data Encrypted (or truncated) Communications w/o account data Transaction account data flow (encrypted or truncated data only) Assessed to PCI PTS POI (SRED) Assessed to P2PE Domain 1 Assessed to P2PE Domain 2
PCI DSS validation as required by the merchant's acquirer or payment brand Customer presentment of payment card POS software and other Merchant systems (Encrypted and/or truncated payment card data may pass through these systems, or be transmitted directly to solution provider from the POI.) Communications Interface (Including Open Protocols, remote and key management) Assessed to P2PE Domain 3 Assessed to P2PE Appendix A (Merchant-managed Solutions only) Assessed to P2PE Domain …
PCI DSS validation as required by the merchant's acquirer or payment brand Customer presentment of payment card POS software and other Merchant systems (Encrypted and/or truncated payment card data may pass through these systems, or be transmitted directly to solution provider from the POI.) Communications Interface (Including Open Protocols, remote and key management) Assessed to P2PE Domain 3 Assessed to P2PE Appendix A (Merchant-managed Solutions only) Assessed to P2PE Domain …
Added
p. 19
• Key Management, Part 2: Mechanisms Using Symmetric Key Management Techniques
•3: Information Technology
• Key Management, Part 3: Mechanisms Using Asymmetric Techniques (RSA and Diffie-Hellman) ISO 13491: Banking
• Secure Cryptographic Devices (Retail) ISO TR 14742: Financial services - Recommendations on cryptographic algorithms and their use ISO 16609: Banking
• Requirements for message authentication using symmetric techniques ISO 18031: Information technology -- Security techniques -- Random bit generation ISO/IEC 18033-3: Information Technology
• Encryption algorithms
• Part 3: Block Ciphers ISO TR 19038: Guidelines on Triple DEA Modes of Operation ISO 20038: Banking and related financial services -- Key wrap using AES NIST NIST Special Publication 800-22: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications NIST Special Publication 800-57: Recommendation for Key Management NIST Special Publication 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management NIST Special Publication 800-131: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key …
•3: Information Technology
• Key Management, Part 3: Mechanisms Using Asymmetric Techniques (RSA and Diffie-Hellman) ISO 13491: Banking
• Secure Cryptographic Devices (Retail) ISO TR 14742: Financial services - Recommendations on cryptographic algorithms and their use ISO 16609: Banking
• Requirements for message authentication using symmetric techniques ISO 18031: Information technology -- Security techniques -- Random bit generation ISO/IEC 18033-3: Information Technology
• Encryption algorithms
• Part 3: Block Ciphers ISO TR 19038: Guidelines on Triple DEA Modes of Operation ISO 20038: Banking and related financial services -- Key wrap using AES NIST NIST Special Publication 800-22: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications NIST Special Publication 800-57: Recommendation for Key Management NIST Special Publication 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management NIST Special Publication 800-131: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key …
Added
p. 21
It is not the intent of Domain 1 that solution providers (or component providers) actively manage POI devices onsite at merchant locations.
Note: The PCI PTS POI approval listing must not be expired.
Note: The PCI PTS POI approval listing must not be expired.
Added
p. 25
• Does not use any POI vendor default device passwords.
1B-1.1.a Examine documented POI device configuration procedures and documented account privilege assignment rules to verify that merchant logical access to POI devices is restricted as follows:
• Does not use the POI vendor’s default passwords.
• Does not use the POI vendor’s default passwords.
1B-1.1.b For a sample of all POI device types intended for use in a solution, logon to the device using an authorized test merchant account. Verify that merchant account level logical access meets the following:
• Only views transaction-related data.
• Cannot view or access cryptographic keys.
• Cannot view or access clear-text PAN.
• Cannot view or access SAD.
1B-1.1.a Examine documented POI device configuration procedures and documented account privilege assignment rules to verify that merchant logical access to POI devices is restricted as follows:
• Does not use the POI vendor’s default passwords.
• Does not use the POI vendor’s default passwords.
1B-1.1.b For a sample of all POI device types intended for use in a solution, logon to the device using an authorized test merchant account. Verify that merchant account level logical access meets the following:
• Only views transaction-related data.
• Cannot view or access cryptographic keys.
• Cannot view or access clear-text PAN.
• Cannot view or access SAD.
Added
p. 27
Note: Authorized solution provider personnel must use multi-factor or cryptographic authentication for all remote access to a terminal management system (TMS) or similar system used to either directly access or to manage merchant POI devices.
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-2.4 Solution provider must implement secure identification and authentication procedures for remote access to POI devices deployed at merchant encryption environments.
Note: A POI system build includes at least the following information:
• Firmware version number(s)
Note: A “critical software security update” is one that addresses an imminent risk to account data, either directly or indirectly.
Note: These security patches can be deployed via “push” from the solution provider or vendor, or via “pull” from the POI device or merchant. In all cases, the solution provider is ultimately responsible to ensure security patches are installed in a timely manner.
• Changes to any security-sensitive configuration options within the …
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-2.4 Solution provider must implement secure identification and authentication procedures for remote access to POI devices deployed at merchant encryption environments.
Note: A POI system build includes at least the following information:
• Firmware version number(s)
Note: A “critical software security update” is one that addresses an imminent risk to account data, either directly or indirectly.
Note: These security patches can be deployed via “push” from the solution provider or vendor, or via “pull” from the POI device or merchant. In all cases, the solution provider is ultimately responsible to ensure security patches are installed in a timely manner.
• Changes to any security-sensitive configuration options within the …
Added
p. 39
The P2PE Standard does not require P2PE Applications used in a P2PE solution to be validated to any other PCI Standard.
Added
p. 48
− Description and justification for the functionality − Who approved the new installation or updated functionality prior to release − Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data
2B-1.1.1 Examine the software-development and testing procedures and interview responsible personnel to verify that live PANs are not used for testing or development.
2B-1.3.2 Documented approval of the change by appropriate authorized parties.
• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries
• A list of potential threats and vulnerabilities resulting from account-data-flow analyses and assigned risk ratings (e.g., high, medium, or low priority) to each
• Documentation of application risk-assessment results for management review and approval 2B-1.4.2 Examine written software development procedures and interview responsible personnel to verify the vendor uses application risk-assessment techniques as part of the software development process, and that the processes include:
2B-1.1.1 Examine the software-development and testing procedures and interview responsible personnel to verify that live PANs are not used for testing or development.
2B-1.3.2 Documented approval of the change by appropriate authorized parties.
• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries
• A list of potential threats and vulnerabilities resulting from account-data-flow analyses and assigned risk ratings (e.g., high, medium, or low priority) to each
• Documentation of application risk-assessment results for management review and approval 2B-1.4.2 Examine written software development procedures and interview responsible personnel to verify the vendor uses application risk-assessment techniques as part of the software development process, and that the processes include:
Added
p. 59
− Link Layer protocols − IP protocols − Security protocols − IP services
Added
p. 63
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-4.2 The application must not be able to decrypt SRED- encrypted account data⎯i.e., the application must not be able to recover the original clear-text account data from the encrypted account data.
2B-4.2.a Examine the application’s Implementation Guide required at 2C-3 of this document and verify the description of the application’s function includes the following:
• Confirmation that the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
2B-4.2.b Perform a source-code review to verify that the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
2B-4.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that …
2B-4.2.a Examine the application’s Implementation Guide required at 2C-3 of this document and verify the description of the application’s function includes the following:
• Confirmation that the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
2B-4.2.b Perform a source-code review to verify that the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
2B-4.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that …
Added
p. 69
• Who approved the new installation or updated functionality prior to release
• Who approved the new installation or updated functionality prior to release
• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Details to describe any whitelisting functionality implemented by the application as follows:
• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data
• Who approved the new installation or updated functionality prior to release
• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Details to describe any whitelisting functionality implemented by the application as follows:
• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data
Added
p. 80
• Notification of any changes that require a Delta Change per the P2PE Program Guide
• Notification of any changes that require a Delta Change per the P2PE Program Guide
• Evidence of adherence to PCI’s process for P2PE Delta Changes
• Notification of any changes that require a Delta Change per the P2PE Program Guide
• Evidence of adherence to PCI’s process for P2PE Delta Changes
Added
p. 83
Within a P2PE solution, the decryption environment is where incoming encrypted account data is decrypted back to its original clear-text. This environment therefore consists of the secure cryptographic devices (and a Host System for hybrid environments) and cryptographic keys involved in the account-data decryption process. Requirements in Domain 4 entail securing all decryption systems and associated cryptographic keys, along with implementing monitoring and response procedures.
Added
p. 84
Note: HSM approval listings must be current⎯HSMs must have a non-expired PCI PTS HSM approval or a non-expired FIPS 140-2 or 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).
Added
p. 88
Note: The intent is to ensure the decryption environment can authenticate each unique POI device within a P2PE solution with which it is communicating.
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.5 Inspections of decryption devices by authorized personnel must be performed at least quarterly to detect tampering or modification of devices. Inspections to include:
− Description and justification for the functionality − Who approved the new installation or updated functionality prior to release − Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 4B-1.9 Review documented policies and procedures to verify that that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment ensures the that the ONLY allowed output of clear-text account data is for non-PCI payment brand account/card data, and includes the following:
− Description and justification for the functionality − Who approved the …
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.5 Inspections of decryption devices by authorized personnel must be performed at least quarterly to detect tampering or modification of devices. Inspections to include:
− Description and justification for the functionality − Who approved the new installation or updated functionality prior to release − Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 4B-1.9 Review documented policies and procedures to verify that that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment ensures the that the ONLY allowed output of clear-text account data is for non-PCI payment brand account/card data, and includes the following:
− Description and justification for the functionality − Who approved the …
Added
p. 94
4C-1.3.1 Checking for incoming clear-text account data.
• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled 4C-1.5 Implement mechanisms to provide immediate notification of suspicious activity to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers).
Note: This diagram is for illustrative purposes only.
Key Management and Remote/Local Cryptographic Key Loading Hardware Security Module (FIPS 140-2 or PCI HSM Approved) P2PE Key Management and Cryptography Account Data Application 1 Account Data Application 2 Non-account Data Application 3 P2PE Key Management and Cryptography Plain-text account data Encrypted (or truncated) Communications w/o account data Transaction account data flow (encrypted or truncated data only) Assessed to PCI PTS POI (SRED) Assessed to P2PE Domain 1 Assessed to P2PE Domain 2
PCI DSS validation as required by the merchant's acquirer …
• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled 4C-1.5 Implement mechanisms to provide immediate notification of suspicious activity to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers).
Note: This diagram is for illustrative purposes only.
Key Management and Remote/Local Cryptographic Key Loading Hardware Security Module (FIPS 140-2 or PCI HSM Approved) P2PE Key Management and Cryptography Account Data Application 1 Account Data Application 2 Non-account Data Application 3 P2PE Key Management and Cryptography Plain-text account data Encrypted (or truncated) Communications w/o account data Transaction account data flow (encrypted or truncated data only) Assessed to PCI PTS POI (SRED) Assessed to P2PE Domain 1 Assessed to P2PE Domain 2
PCI DSS validation as required by the merchant's acquirer …
Added
p. 101
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.9 Alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.14.3 The swap/page files and/or core dumps must never be backed up or copied.
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-2 Access controls for the Host System are configured securely.
Note: For information on variability and equivalency of password strength/complexity (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.).
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-2.6.2 A Host System …
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.9 Alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.14.3 The swap/page files and/or core dumps must never be backed up or copied.
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-2 Access controls for the Host System are configured securely.
Note: For information on variability and equivalency of password strength/complexity (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.).
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-2.6.2 A Host System …
Added
p. 113
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.17 Use of an emergency entry or exit mechanism must cause an alarm event.
• Details of any suspicious activity that occurred, per 4C-1.2
Control Objective 1 Account data is processed using equipment and methodologies that ensure they are kept secure.
Domain 5 requirements address secure cryptographic key-management operations for the encryption environment and the decryption environment, as well as environments performing symmetric-key distribution using asymmetric keys (remote key distribution), certification authority/registration authority and key-injection or key-generation.
Vendor-controlled secret and private keys used in connection with the following activities are also in scope:
• When used in connection with vendor-operated PKIs used for remote key loading using asymmetric techniques. This applies specifically to the distribution of acquirer keys to transaction-originating devices (POIs) for use in connection with account-data encryption, whether the actual distribution of acquirer keys occurs …
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.17 Use of an emergency entry or exit mechanism must cause an alarm event.
• Details of any suspicious activity that occurred, per 4C-1.2
Control Objective 1 Account data is processed using equipment and methodologies that ensure they are kept secure.
Domain 5 requirements address secure cryptographic key-management operations for the encryption environment and the decryption environment, as well as environments performing symmetric-key distribution using asymmetric keys (remote key distribution), certification authority/registration authority and key-injection or key-generation.
Vendor-controlled secret and private keys used in connection with the following activities are also in scope:
• When used in connection with vendor-operated PKIs used for remote key loading using asymmetric techniques. This applies specifically to the distribution of acquirer keys to transaction-originating devices (POIs) for use in connection with account-data encryption, whether the actual distribution of acquirer keys occurs …
Added
p. 119
Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key- distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account-data encryption. If the key loading is not performed remotely and authentication is provided by another method
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates, the remote key-establishment and distribution applications requirements will not apply. “Remotely” means whenever the key-loading device and the POI device are neither co-located nor connected via a direct mechanism, such as a cable.
ANSI TR-34 presents a methodology that is compliant with these requirements. TR34 describes a method for transporting a symmetric key from one SCD to another over an uncontrolled channel. A typical example usage of TR34 would be to load individual initial symmetric transport keys from a Key Distribution Host (KDH) to a …
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates, the remote key-establishment and distribution applications requirements will not apply. “Remotely” means whenever the key-loading device and the POI device are neither co-located nor connected via a direct mechanism, such as a cable.
ANSI TR-34 presents a methodology that is compliant with these requirements. TR34 describes a method for transporting a symmetric key from one SCD to another over an uncontrolled channel. A typical example usage of TR34 would be to load individual initial symmetric transport keys from a Key Distribution Host (KDH) to a …
Added
p. 120
Key-Injection Facilities The term key-injection facility (KIF) describes those entities that perform key injection of POI devices used for account-data encryption and key injection of HSMs used for decryption. Key injection may be performed by the solution provider or by a third party such as a POI terminal manufacturer or vendor. Domain 5 contains requirements that apply to key-injection facilities, or other entities that are performing KIF-related services for others, such as key generation or key loading.
Key-injection systems that allow clear-text secret and/or private keys and/or their components to appear in unprotected memory (e.g., within a computer and outside of the secure boundary of a secure cryptographic device) are inherently less secure. Any such systems are subject to additional controls as delineated in the criteria in this domain.
Key-injection systems that allow clear-text secret and/or private keys and/or their components to appear in unprotected memory (e.g., within a computer and outside of the secure boundary of a secure cryptographic device) are inherently less secure. Any such systems are subject to additional controls as delineated in the criteria in this domain.
Added
p. 121
• Secret Key = Symmetric key (also known as a shared secret key).
Requirement 1: Account data is processed in equipment that conforms to requirements for secure cryptographic devices (SCDs). Account data never appears in the clear outside of an SCD.
1-1 Not used in P2PE 1-2 Key-injection facilities must only inject keys into equipment that conforms to the requirements for SCDs.
1-2 Examine documented procedures and system documentation to verify that key- injection platforms and systems used for managing cryptographic keys are required to conform to the requirements for SCDs.
1-3 All hardware security modules (HSMs) must be either:
• FIPS 140-2 or 140-3 Level 3 or higher certified, or
Note: HSM approval listings must be current⎯HSMs must have a non-expired PCI PTS HSM approval or a non- expired FIPS 140-2 or 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).
Note: Key-injection platforms and systems must include hardware …
Requirement 1: Account data is processed in equipment that conforms to requirements for secure cryptographic devices (SCDs). Account data never appears in the clear outside of an SCD.
1-1 Not used in P2PE 1-2 Key-injection facilities must only inject keys into equipment that conforms to the requirements for SCDs.
1-2 Examine documented procedures and system documentation to verify that key- injection platforms and systems used for managing cryptographic keys are required to conform to the requirements for SCDs.
1-3 All hardware security modules (HSMs) must be either:
• FIPS 140-2 or 140-3 Level 3 or higher certified, or
Note: HSM approval listings must be current⎯HSMs must have a non-expired PCI PTS HSM approval or a non- expired FIPS 140-2 or 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).
Note: Key-injection platforms and systems must include hardware …
Added
p. 123
• The PCI PTS HSM or FIPS 140 Approval Number
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 1-4.a For all PCI-approved HSMs used, examine HSM devices and examine the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
• The PCI PTS HSM number
• Review the PCI approval listing(s) for any implementation-specific notes and if present, verify they are accounted for.
1-4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS 140-2 or 140-3 Level 3 (or higher) approval listing for each HSM:
• The FIPS 140 Approval Number
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 1-4.a For all PCI-approved HSMs used, examine HSM devices and examine the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
• The PCI PTS HSM number
• Review the PCI approval listing(s) for any implementation-specific notes and if present, verify they are accounted for.
1-4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS 140-2 or 140-3 Level 3 (or higher) approval listing for each HSM:
• The FIPS 140 Approval Number
Added
p. 124
• Maintain current documentation that describes or illustrates the architecture of the KIF, including all KIF functionality.
• Maintain documentation detailing the flow of keys from the key generation, through the functionality to the destination device.
1-5.a Interview relevant personnel and examine documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
1-5.b Interview relevant personnel and examine documentation that describes and/or illustrates the architecture of the KIF to verify that all KIF components, key-management flows, and personnel interaction with key-management flows are identified and documented.
1-5.c Examine the key-management flows and interview personnel to verify:
Note: PIN requirements 2, 3, and 4 are all PIN-specific and are therefore omitted from P2PE.
5-1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Generation of cryptographic keys or key components …
• Maintain documentation detailing the flow of keys from the key generation, through the functionality to the destination device.
1-5.a Interview relevant personnel and examine documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
1-5.b Interview relevant personnel and examine documentation that describes and/or illustrates the architecture of the KIF to verify that all KIF components, key-management flows, and personnel interaction with key-management flows are identified and documented.
1-5.c Examine the key-management flows and interview personnel to verify:
Note: PIN requirements 2, 3, and 4 are all PIN-specific and are therefore omitted from P2PE.
5-1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Generation of cryptographic keys or key components …
Added
p. 127
6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear-text key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component.
Note: This does not apply to logically partitioned devices located in data centers that are concurrently used for other purposes, such as transaction processing.
6-1.4.a Examine documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering prior to use. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during …
Note: This does not apply to logically partitioned devices located in data centers that are concurrently used for other purposes, such as transaction processing.
6-1.4.a Examine documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering prior to use. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during …
Added
p. 128
SCDs used for key generation must meet Requirement 5-1.
6-2.b Observe the generation process and examine documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD except where Requirement 5 and Requirement 13 are met.
6-2.c Where single-purpose computers with an installed SCD or a modified PED are used, verify that either:
• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) or where clear keying material passes through memory of the PC, the PC requirements of Requirement 13 are met.
6-2.b Observe the generation process and examine documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD except where Requirement 5 and Requirement 13 are met.
6-2.c Where single-purpose computers with an installed SCD or a modified PED are used, verify that either:
• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) or where clear keying material passes through memory of the PC, the PC requirements of Requirement 13 are met.
Added
p. 129
Printers used for this purpose are not used for other purposes, are managed under dual control in a secure room that meets the requirements of 32-9 and are not networked.
6-3.b Observe processes for printing key components to verify that:
• Key components are printed within blind mailers or sealed in tamper-evident and authenticable packaging (that is able to be authenticated) immediately after printing, such that no one but the authorized custodian ever has physical access to the output;
• Printers are used only under dual control and only within a secure room that meets the requirements of 32-9; and
• Printers are not networked.
6-3.b Observe processes for printing key components to verify that:
• Key components are printed within blind mailers or sealed in tamper-evident and authenticable packaging (that is able to be authenticated) immediately after printing, such that no one but the authorized custodian ever has physical access to the output;
• Printers are used only under dual control and only within a secure room that meets the requirements of 32-9; and
• Printers are not networked.
Added
p. 130
• Other types of displaying or recording (e.g., printer memory, printer drum).
• Specific direction as to the method of destruction is included in the procedure.
Examine logs of past destructions and deletions to verify that procedures are followed.
• The method of destruction is consistent with Requirement 24.
6-5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:
• Specific direction as to the method of destruction is included in the procedure.
Examine logs of past destructions and deletions to verify that procedures are followed.
• The method of destruction is consistent with Requirement 24.
6-5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:
Added
p. 132
• Conveying clear-text private key shares or secret key components/shares without containing them within tamper-evident and authenticable packaging
• Affixing key or component values to or inside devices
• Writing key or component values in procedure manual 6-6.b From observation of key-management processes verify that clear-text private or secret keys or their components are not transmitted across insecure channels, including but not limited to:
• Faxing, e-mailing, or otherwise electronically conveying clear-text keys or components
7-2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs. The minimum log contents include date and time, object name/identifier, purpose, name and signature of individual(s) involved, and tamper-evident package number(s) and serial number(s) of device(s) involved.
It is the responsibility of both the sending and receiving parties to ensure these keys are managed securely during transport.
• Affixing key or component values to or inside devices
• Writing key or component values in procedure manual 6-6.b From observation of key-management processes verify that clear-text private or secret keys or their components are not transmitted across insecure channels, including but not limited to:
• Faxing, e-mailing, or otherwise electronically conveying clear-text keys or components
7-2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs. The minimum log contents include date and time, object name/identifier, purpose, name and signature of individual(s) involved, and tamper-evident package number(s) and serial number(s) of device(s) involved.
It is the responsibility of both the sending and receiving parties to ensure these keys are managed securely during transport.
Added
p. 135
• Examine documented procedures for sending components in tamper-evident, authenticable packaging to verify that:
They define how the details of the package serial number are to be transmitted.
There is a requirement that the package serial number is to be sent separately from the package itself.
Each component is to be sent to/from only the custodian(s) authorized for the component.
At least two communication channels are used to send the components of a given key (not just separation by sending on different days).
Prior to the use of the components, the serial numbers are to be confirmed.
• Confirm through observation, interview, and inspection of the records of past key transfers that the process used to transport clear-text key components using pre- numbered, tamper-evident, authenticable packaging, is sufficient to ensure:
At least two communication channels were used to send the components of a given key (not just separation by sending on different days).
Each component was sent to/from …
They define how the details of the package serial number are to be transmitted.
There is a requirement that the package serial number is to be sent separately from the package itself.
Each component is to be sent to/from only the custodian(s) authorized for the component.
At least two communication channels are used to send the components of a given key (not just separation by sending on different days).
Prior to the use of the components, the serial numbers are to be confirmed.
• Confirm through observation, interview, and inspection of the records of past key transfers that the process used to transport clear-text key components using pre- numbered, tamper-evident, authenticable packaging, is sufficient to ensure:
At least two communication channels were used to send the components of a given key (not just separation by sending on different days).
Each component was sent to/from …
Added
p. 139
Self-signed root certificates protect the integrity of the data within the certificate but do not guarantee the authenticity of the data. The authenticity of the root certificates is based on the use of secure procedures to distribute them. Specifically, they must be directly installed into the PIN pad of the ATM or POS device and not remotely loaded to the device subsequent to manufacture.
Requirement 9: During its transmission, conveyance, or movement between any two locations or organizational entities, any single unencrypted secret or private key component or share must at all times be protected.
These requirements also apply to keys moved between locations of the same organization.
• Any keys encrypted under this (combined) key 9-2.a Verify documented procedures include requirements for all packaging or mailers containing clear-text key components to be examined for evidence of tampering before being opened.
• Any keys encrypted under this (combined) key 9-3 Only an authorized key …
Requirement 9: During its transmission, conveyance, or movement between any two locations or organizational entities, any single unencrypted secret or private key component or share must at all times be protected.
These requirements also apply to keys moved between locations of the same organization.
• Any keys encrypted under this (combined) key 9-2.a Verify documented procedures include requirements for all packaging or mailers containing clear-text key components to be examined for evidence of tampering before being opened.
• Any keys encrypted under this (combined) key 9-3 Only an authorized key …
Added
p. 142
Note: See Requirement 26 for logging.
9-5 Pre-numbered, tamper-evident, authenticable bags must be used for the conveyance of clear-text key components not in an SCD. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers.
• Examine logs to verify that procedures are followed.
9-5 Pre-numbered, tamper-evident, authenticable bags must be used for the conveyance of clear-text key components not in an SCD. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers.
• Examine logs to verify that procedures are followed.
Added
p. 143
• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened.
• The components are repackaged at receipt into separate tamper-evident and authenticable packages for storage at the receiving location. Records reflect the receipt of the shipped bag and association with subsequent individual bags.
9-6.a If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that:
• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or within PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened.
• The components are repackaged at receipt into …
• The components are repackaged at receipt into separate tamper-evident and authenticable packages for storage at the receiving location. Records reflect the receipt of the shipped bag and association with subsequent individual bags.
9-6.a If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that:
• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or within PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened.
• The components are repackaged at receipt into …
Added
p. 145
TDEA keys used for encrypting keys must be at least triple-length keys (have an effective bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment.
RSA keys encrypting keys greater in strength than 80 bits have a bit strength at least 112 bits.
10-2 Not used in P2PE 10-3 Not used in P2PE 10-4 Not used in P2PE 10-5 Not used in P2PE
RSA keys encrypting keys greater in strength than 80 bits have a bit strength at least 112 bits.
10-2 Not used in P2PE 10-3 Not used in P2PE 10-4 Not used in P2PE 10-5 Not used in P2PE
Added
p. 148
12-1.f Examine locations where keys may have been recorded that don't meet this requirement. As applicable, examine HSM startup documentation (including Disaster Recovery or Business Continuity Planning documentation) and procedure manuals to ensure that there are no key or component values recorded.
Trace historical movement of higher-order keys (MFK, KEK, and BDK) in and out of secure storage to ensure there is no break in the package-number chain that would call into question authorized handling and sufficient storage of the component or share. This must address at a minimum the time frame from the date of the prior audit.
Trace historical movement of higher-order keys (MFK, KEK, and BDK) in and out of secure storage to ensure there is no break in the package-number chain that would call into question authorized handling and sufficient storage of the component or share. This must address at a minimum the time frame from the date of the prior audit.
Added
p. 149
• Separate key-loading devices for each component/share (continued on next page) 12-3.a Identify instances where a key-loading device is used to load clear-text keys. Examine documented procedures for loading of clear-text cryptographic keys to verify:
• Procedures require dual control to authorize any key-loading session.
• The techniques to be used to achieve dual control are identified.
• There is a requirement to change any default passwords/authentication codes and set passwords/authentication codes that have at least five characters.
• There is a requirement that if passwords/authentication codes or tokens are used, they are maintained separately.
12-3.b For each type of production SCD loaded using a key-loading device, observe for the process (e.g., a demonstration) of loading clear-text cryptographic keys and interview personnel. Verify that:
• Dual control is necessary to authorize the key-loading session.
• Expected techniques are used.
• Default passwords/authentications codes are reset.
• Any passwords/authentication codes used are a minimum of five characters.
• Any passwords/authentication codes …
• Procedures require dual control to authorize any key-loading session.
• The techniques to be used to achieve dual control are identified.
• There is a requirement to change any default passwords/authentication codes and set passwords/authentication codes that have at least five characters.
• There is a requirement that if passwords/authentication codes or tokens are used, they are maintained separately.
12-3.b For each type of production SCD loaded using a key-loading device, observe for the process (e.g., a demonstration) of loading clear-text cryptographic keys and interview personnel. Verify that:
• Dual control is necessary to authorize the key-loading session.
• Expected techniques are used.
• Default passwords/authentications codes are reset.
• Any passwords/authentication codes used are a minimum of five characters.
• Any passwords/authentication codes …
Added
p. 150
Note: Passwords/authentication codes to the same object may be assigned to a custodian group team⎯e.g., custodian team for component A.
Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. If a PED that has been modified to perform these functions has not been validated and approved to the KLD approval class, the PED must be managed in accordance with Requirement 13-9.
Note: Concatenation of key components together to form the key is unacceptable; e.g., concatenating two 8- hexadecimal character halves to form a 16-hexadecimal secret key.
12-4.b Confirm key-component lengths through interview and examination of blank component forms and documented procedures. Examine device configuration settings and interview personnel to verify that key components used to create a key are the same …
Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. If a PED that has been modified to perform these functions has not been validated and approved to the KLD approval class, the PED must be managed in accordance with Requirement 13-9.
Note: Concatenation of key components together to form the key is unacceptable; e.g., concatenating two 8- hexadecimal character halves to form a 16-hexadecimal secret key.
12-4.b Confirm key-component lengths through interview and examination of blank component forms and documented procedures. Examine device configuration settings and interview personnel to verify that key components used to create a key are the same …
Added
p. 151
12-6 Thorough examination of documented procedures, interviews, and observation, confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key.
• For AES DUKPT, using the option to derive a key- encryption key called the DUKPT Update Key so that the host can send a device a new initial key encrypted under that key. Note this also requires that a new initial key ID is also sent.
12-7.b Examine documented procedures to verify that keys are withdrawn from use if they were loaded to a device that has been compromised or gone missing.
• For AES DUKPT, using the option to derive a key- encryption key called the DUKPT Update Key so that the host can send a device a new initial key encrypted under that key. Note this also requires that a new initial key ID is also sent.
12-7.b Examine documented procedures to verify that keys are withdrawn from use if they were loaded to a device that has been compromised or gone missing.
Added
p. 153
• Separate key-loading devices for each component.
12-9.a Examine documented key-injection procedures to verify that the procedures define the use of dual control and split knowledge controls for the loading of keys into devices.
• The sending and receiving SCDs must be inspected prior to key loading to ensure that they have not been subject to any prior tampering or unauthorized modification that could lead to the disclosure of clear-text keying material.
• Examine documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that:
SCDs are inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.
The SCD is inspected to ensure it has not been subject to any prior tampering or unauthorized modification, which could lead to the disclosure of clear-text keying …
12-9.a Examine documented key-injection procedures to verify that the procedures define the use of dual control and split knowledge controls for the loading of keys into devices.
• The sending and receiving SCDs must be inspected prior to key loading to ensure that they have not been subject to any prior tampering or unauthorized modification that could lead to the disclosure of clear-text keying material.
• Examine documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that:
SCDs are inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.
The SCD is inspected to ensure it has not been subject to any prior tampering or unauthorized modification, which could lead to the disclosure of clear-text keying …
Added
p. 156
13-2.a Examine documentation to verify that only SCDs are used in the loading of clear- text secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. For example, computer keyboards or keyboards attached to an HSM must never be used for the loading of clear-text secret or private keys or their components.
Added
p. 157
• All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement 24.
13-3.a Examine documented procedures for the loading of secret or private key components from electronic medium to a cryptographic device. Verify that procedures define specific instructions to be followed as a result of key injection, including:
• Instructions to erase or otherwise destroy all traces of the component from the electronic medium, including the method to use.
13-3.b Observe key-loading processes to verify that the injection process results in one of the following:
• The medium used for key injection is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or
13-3.c Examine records/logs of erasures to confirm that:
• The documented procedure was followed.
• The method used was in accordance with Requirement 24.
Note: A PCI-approved …
13-3.a Examine documented procedures for the loading of secret or private key components from electronic medium to a cryptographic device. Verify that procedures define specific instructions to be followed as a result of key injection, including:
• Instructions to erase or otherwise destroy all traces of the component from the electronic medium, including the method to use.
13-3.b Observe key-loading processes to verify that the injection process results in one of the following:
• The medium used for key injection is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or
13-3.c Examine records/logs of erasures to confirm that:
• The documented procedure was followed.
• The method used was in accordance with Requirement 24.
Note: A PCI-approved …
Added
p. 159
13-6 Validate through interview and observation that if components are in human-readable form, they are visible only to designated component custodians and only for the duration of time required for this person to privately enter the key component into an SCD.
Note: Effective 1 January 2021, entities engaged in key loading on behalf of others must not be allowed to use PC based key-loading methodologies where clear-text secret and/or private keying material appears in the clear in memory outside the secure boundary of an SCD.
Effective 1 January 2023, entities only performing key loading for devices for which they are the processor must no longer have this option.
Note: Effective 1 January 2021, entities engaged in key loading on behalf of others must not be allowed to use PC based key-loading methodologies where clear-text secret and/or private keying material appears in the clear in memory outside the secure boundary of an SCD.
Effective 1 January 2023, entities only performing key loading for devices for which they are the processor must no longer have this option.
Added
p. 165
Note: Where key-loading is performed for POI devices, the secure environment as defined in Requirement 32-9 must additionally be met.
Added
p. 166
• Effective 1 January 2021 the injection of clear-text secret or private keying material must not be allowed for entities engaged in key injection on behalf of others. Only encrypted key injection will be allowed for POI v3 and higher devices.
• Effective 1 January 2023, the same restriction applies to entities engaged in key injection of devices for which they are the processors.
14-2.a Examine documented procedures to ensure they require that cable attachments are examined at the beginning of an entity’s key-activity operations (system power on/authorization) or application-signing operations.
• Effective 1 January 2023, the same restriction applies to entities engaged in key injection of devices for which they are the processors.
14-2.a Examine documented procedures to ensure they require that cable attachments are examined at the beginning of an entity’s key-activity operations (system power on/authorization) or application-signing operations.
Added
p. 167
14-4 Any physical tokens (e.g., brass keys or chip cards) used to enable key loading or the signing of authenticated applications must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control. These tokens must be secured in a manner similar to key components, including tamper-evident, authenticable packaging and the use of access-control logs for when removed or placed into secure storage.
14-5 Default passwords/authentication codes used to enforce dual-control mechanisms must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change.
Note: Check values are computed by encrypting an all- zero block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). Either this method must be …
14-5 Default passwords/authentication codes used to enforce dual-control mechanisms must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change.
Note: Check values are computed by encrypting an all- zero block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). Either this method must be …
Added
p. 169
• Be within a PKCS#10 (authentication and integrity occurs via other mechanisms); or
15-3 Mechanisms must exist to prevent a non-authorized KDH from performing key transport, key exchange, or key establishment with POIs. POIs and key-distribution hosts (KDHs) using public-key schemes must validate authentication credentials of other such devices involved in the communication immediately prior to any key transport, exchange, or establishment.
Note: Examples of this kind of validation include ensuring the SCD serial number is listed in a table of “permitted” devices, checking current certificate revocation lists or embedding valid authorized KDH certificates in devices and disallowing communication with unauthorized KDHs, as delineated by techniques defined in the Technical FAQs for PCI PTS POI Security Requirements.
15-3.a Examine documented procedures to confirm they define procedures for mutual authentication of the sending and receiving devices, as follows:
15-3.b Interview applicable personnel to verify that mutual authentication of the sending and receiving devices is performed, …
15-3 Mechanisms must exist to prevent a non-authorized KDH from performing key transport, key exchange, or key establishment with POIs. POIs and key-distribution hosts (KDHs) using public-key schemes must validate authentication credentials of other such devices involved in the communication immediately prior to any key transport, exchange, or establishment.
Note: Examples of this kind of validation include ensuring the SCD serial number is listed in a table of “permitted” devices, checking current certificate revocation lists or embedding valid authorized KDH certificates in devices and disallowing communication with unauthorized KDHs, as delineated by techniques defined in the Technical FAQs for PCI PTS POI Security Requirements.
15-3.a Examine documented procedures to confirm they define procedures for mutual authentication of the sending and receiving devices, as follows:
15-3.b Interview applicable personnel to verify that mutual authentication of the sending and receiving devices is performed, …
Added
p. 170
• Within an implementation design, there must be no means available for “man-in-the-middle” attacks
• e.g., through binding of the KDH certificate upon the initial communication.
• System implementations must be designed and implemented to prevent replay attacks
•e.g., through the use of random nonces and time stamps as noted in ANSI TR-34.
15-4 Examine system and process documentation to verify that key-establishment and distribution procedures are designed such that:
• There are no means available in the implementation design for “man-in-the-middle” attacks.
15-5 Key pairs generated external to the device that uses the key pair must be securely transferred and loaded into the device and must provide for key protection in accordance with this document. That is, the secrecy of the private key and the integrity of the public key must be ensured. The process must ensure that once keys are injected they are no longer available for injection into other POI devices•i.e., key pairs …
• e.g., through binding of the KDH certificate upon the initial communication.
• System implementations must be designed and implemented to prevent replay attacks
•e.g., through the use of random nonces and time stamps as noted in ANSI TR-34.
15-4 Examine system and process documentation to verify that key-establishment and distribution procedures are designed such that:
• There are no means available in the implementation design for “man-in-the-middle” attacks.
15-5 Key pairs generated external to the device that uses the key pair must be securely transferred and loaded into the device and must provide for key protection in accordance with this document. That is, the secrecy of the private key and the integrity of the public key must be ensured. The process must ensure that once keys are injected they are no longer available for injection into other POI devices•i.e., key pairs …
Added
p. 171
Requirement 17: Unique, secret cryptographic keys must be in use for each identifiable link between host computer systems of two organizations or logically separate systems within the same organization.
17-1 Where two organizations or logically separate systems share a key to encrypt account data (including a key-encipherment key used to encrypt a data-encryption key) communicated between them, that key must:
Note: This requirement does not apply after the decryption environment.
17-1.a Examine the documented key matrix and operational procedures and interview personnel to determine whether any keys are shared between organizations or logically separate systems.
17-1.b For all keys shared between two organizations or logically separate systems for encrypting account data (including key-encryption keys used to encrypt a data-encryption key) perform the following:
• Generate or otherwise obtain key-check values for any key-encipherment keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than 10 zone connections …
17-1 Where two organizations or logically separate systems share a key to encrypt account data (including a key-encipherment key used to encrypt a data-encryption key) communicated between them, that key must:
Note: This requirement does not apply after the decryption environment.
17-1.a Examine the documented key matrix and operational procedures and interview personnel to determine whether any keys are shared between organizations or logically separate systems.
17-1.b For all keys shared between two organizations or logically separate systems for encrypting account data (including key-encryption keys used to encrypt a data-encryption key) perform the following:
• Generate or otherwise obtain key-check values for any key-encipherment keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than 10 zone connections …
Added
p. 173
• Implement Key Blocks for internal connections and key storage within Service Provider Environments
• this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019 (past).
• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 June 2021.
• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 June 2023.
Acceptable methods of implementing the integrity requirements include, but are not limited to:
• A MAC computed over the concatenation of the clear- text attributes and the enciphered portion of the key block, which includes the key itself⎯e.g., TR-31;
• A digital signature computed over that same data;
• An integrity check that is an implicit part of the key- encryption process such as that which is used in the AES key-wrap process specified in ANSI X9.102.
18-3 Using the cryptographic-key summary to identify secret keys conveyed or …
• this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019 (past).
• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 June 2021.
• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 June 2023.
Acceptable methods of implementing the integrity requirements include, but are not limited to:
• A MAC computed over the concatenation of the clear- text attributes and the enciphered portion of the key block, which includes the key itself⎯e.g., TR-31;
• A digital signature computed over that same data;
• An integrity check that is an implicit part of the key- encryption process such as that which is used in the AES key-wrap process specified in ANSI X9.102.
18-3 Using the cryptographic-key summary to identify secret keys conveyed or …
Added
p. 174
18-4.a Examine documented procedures to verify that:
18-5.a Examine documented procedures to verify that:
• POI devices only communicate with CAs for the purpose of certificate signing, or for key injection where the certificate-issuing authority generates the key pair on behalf of the device;
• POI devices only communicate with KDHs for key management, normal transaction processing, and certificate (entity) status checking.
18-4.b Interview responsible personnel and observe POI configurations to verify that:
• POI devices only communicate with CAs for the purpose of certificate signing, or for key-injection where the certificate issuing authority generates the key pair on behalf of the device;
• POI devices only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking.
18-5 KDHs must only communicate with POI devices for the purpose of key management and normal transaction processing, and with CAs for the purpose of certificate signing and certificate (entity) status checking.
• KDHs only communicate with …
18-5.a Examine documented procedures to verify that:
• POI devices only communicate with CAs for the purpose of certificate signing, or for key injection where the certificate-issuing authority generates the key pair on behalf of the device;
• POI devices only communicate with KDHs for key management, normal transaction processing, and certificate (entity) status checking.
18-4.b Interview responsible personnel and observe POI configurations to verify that:
• POI devices only communicate with CAs for the purpose of certificate signing, or for key-injection where the certificate issuing authority generates the key pair on behalf of the device;
• POI devices only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking.
18-5 KDHs must only communicate with POI devices for the purpose of key management and normal transaction processing, and with CAs for the purpose of certificate signing and certificate (entity) status checking.
• KDHs only communicate with …
Added
p. 176
19-1 Encryption keys must only be used for the purpose they were intended⎯i.e., key-encryption keys must not be used as PIN-encryption keys, PIN-encryption keys must not be used for account-data, etc. Derivation Keys may be derived into multiple keys, each with its own purpose. For example, a DUKPT Initial Key may be used to derive both a PIN encryption key and a data encryption key. The derivation key would only be used for its own purpose, key derivation. This is necessary to limit the magnitude of exposure should any key(s) be compromised. Using keys only as they are intended also significantly strengthens the security of the underlying system.
Added
p. 177
• When used for remote key distribution, must not be used in connection with any other purpose.
Note: The restriction does not apply to certificate signing requests e.g., PKCS #10.
• Not used in connection with any other purpose when used for remote key distribution.
Note: The restriction does not apply to certificate signing requests e.g., PKCS #10.
• Not used in connection with any other purpose when used for remote key distribution.
Added
p. 178
Note: For logically partitioned HSMs and computing platforms, if one or more logical partitions of a physical device are used for production and one or more other logical partitions are used for testing, including QA or similar, the entire configuration that is impacted
• computing platform(s) and networking equipment
•must be managed and controlled as production.
19-5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements.
• computing platform(s) and networking equipment
•must be managed and controlled as production.
19-5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements.
Added
p. 179
19-6.a Examine documented procedures for requesting certificate issue, renewal, and replacement to verify procedures include generation of a unique key pair for each:
• Each key pair generated results in only one certificate 19-6.b Interview responsible personnel, examine records of past KDH-signing requests, and observe certificate issuing and replacement processes to verify that:
19-7 KDH private keys must not be shared between devices except for load balancing and disaster recovery.
19-7 Examine documented processes to verify that KDH private keys are not permitted to be shared between devices, except for load balancing and disaster recovery.
19-8 POI device private keys must not be shared between POI devices.
19-8.a Examine documented processes to verify that POI device private keys are not permitted to be shared between POI devices.
19-8.b Inspect public key certificates on the host processing system to confirm that a unique certificate exists for each connected POI device.
19-9 Mechanisms must be utilized to preclude the …
• Each key pair generated results in only one certificate 19-6.b Interview responsible personnel, examine records of past KDH-signing requests, and observe certificate issuing and replacement processes to verify that:
19-7 KDH private keys must not be shared between devices except for load balancing and disaster recovery.
19-7 Examine documented processes to verify that KDH private keys are not permitted to be shared between devices, except for load balancing and disaster recovery.
19-8 POI device private keys must not be shared between POI devices.
19-8.a Examine documented processes to verify that POI device private keys are not permitted to be shared between POI devices.
19-8.b Inspect public key certificates on the host processing system to confirm that a unique certificate exists for each connected POI device.
19-9 Mechanisms must be utilized to preclude the …
Added
p. 180
19-9.1.a Examine certificate policy and documented procedures to verify that the following:
• Signature keys for updating valid/authorized host lists in POI devices.
19-9.1.b Interview responsible personnel and observe demonstration to verify that the following:
• Signature keys for updating valid/authorized host lists in POIs.
19-9.2 CAs that issue certificates to other CAs must not be used to issue certificates to POIs (i.e., a CA cannot sign certificates to both subordinate CAs and end-entity [POI] devices).
19-9.2 If a CA issues certificates to other CAs, examine the CA certificate policy and documented procedures to verify that the CA does not also issue certificates to POI devices.
19-10 Public-key-based implementations must provide mechanisms for restricting and controlling the use of public and private keys. For example, this can be accomplished through the use of X.509 compliant certificate extensions.
19-10 Examine documented procedures to verify that mechanisms are defined for restricting and controlling the use of public and private …
• Signature keys for updating valid/authorized host lists in POI devices.
19-9.1.b Interview responsible personnel and observe demonstration to verify that the following:
• Signature keys for updating valid/authorized host lists in POIs.
19-9.2 CAs that issue certificates to other CAs must not be used to issue certificates to POIs (i.e., a CA cannot sign certificates to both subordinate CAs and end-entity [POI] devices).
19-9.2 If a CA issues certificates to other CAs, examine the CA certificate policy and documented procedures to verify that the CA does not also issue certificates to POI devices.
19-10 Public-key-based implementations must provide mechanisms for restricting and controlling the use of public and private keys. For example, this can be accomplished through the use of X.509 compliant certificate extensions.
19-10 Examine documented procedures to verify that mechanisms are defined for restricting and controlling the use of public and private …
Added
p. 181
• Certificates associated with encryption for remote key- distribution functions must not be used for any other purpose.
• Certificates associated with authentication of the KDH must not be used for any other purpose.
• Certificates associated with authentication of the POI must not be used for any other purpose.
• Certificates associated with authentication of POI firmware and POI applications must not be used for any other purpose.
If CA separation is used to ensure certificate segmentation:
• Sub-CAs used to produce certificates used for remote key-delivery functions must not be used to produce certificates used for any other purpose.
• Sub-CAs used to produce certificates for POI firmware and POI application authentication must not be used for any other purpose.
(continued on next page) 19-12.a Examine implementation schematics and other relevant documentation to identify PKI architecture and where certificates are used in the implementation.
19.12.b Identify mechanism(s) used to restrict certificates to a single-purpose use as …
• Certificates associated with authentication of the KDH must not be used for any other purpose.
• Certificates associated with authentication of the POI must not be used for any other purpose.
• Certificates associated with authentication of POI firmware and POI applications must not be used for any other purpose.
If CA separation is used to ensure certificate segmentation:
• Sub-CAs used to produce certificates used for remote key-delivery functions must not be used to produce certificates used for any other purpose.
• Sub-CAs used to produce certificates for POI firmware and POI application authentication must not be used for any other purpose.
(continued on next page) 19-12.a Examine implementation schematics and other relevant documentation to identify PKI architecture and where certificates are used in the implementation.
19.12.b Identify mechanism(s) used to restrict certificates to a single-purpose use as …
Added
p. 182
• The method of segmentation between certificates must be reflected in the certificate practice statement (CPS) for the CA.
• Certificates issued for remote key-distribution purposes must include a mechanism to identify designation for this purpose.
• Each SCD using a certificate in a remote key-delivery function must ensure there is a designation included in the certificate indicating that it is for use in the remote key-delivery function for which it is being used.
Each SCD using a certificate in a remote key-delivery function must ensure that if there is a designation included in a certificate that indicates it is for use in a remote key- delivery function, the SCD does not use it for any other purpose.
19-12.d If policy-based certificate segmentation is used to ensure certificate segmentation, confirm that all of the following are true:
• The method of segmentation between certificates is clearly stated in the certificate practice statement (CPS) for the …
• Certificates issued for remote key-distribution purposes must include a mechanism to identify designation for this purpose.
• Each SCD using a certificate in a remote key-delivery function must ensure there is a designation included in the certificate indicating that it is for use in the remote key-delivery function for which it is being used.
Each SCD using a certificate in a remote key-delivery function must ensure that if there is a designation included in a certificate that indicates it is for use in a remote key- delivery function, the SCD does not use it for any other purpose.
19-12.d If policy-based certificate segmentation is used to ensure certificate segmentation, confirm that all of the following are true:
• The method of segmentation between certificates is clearly stated in the certificate practice statement (CPS) for the …
Added
p. 185
• Different BDKs by geographic region, market segment, processing platform, or sales unit.
COMPONENT PROVIDERS ONLY: Must use at least one unique Base Derivation Key (BDK) per acquiring organization and must be able to support segmentation of multiple BDKS of acquiring organizations.
• Different BDKs for each financial institution;
• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model;
COMPONENT PROVIDERS ONLY: Must use at least one unique Base Derivation Key (BDK) per acquiring organization and must be able to support segmentation of multiple BDKS of acquiring organizations.
• Different BDKs for each financial institution;
• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model;
Added
p. 186
• Keys must be uniquely identifiable in all hosts and POI Devices⎯e.g., EPPs/PEDs. Keys must be identifiable via cryptographically verifiable means⎯e.g., through the use of digital signatures or key check values.
Note for hybrid decryption solutions: Requirements specific to hybrid decryption solutions are denoted throughout Control Objective 6.
Note: Key-injection facilities may have clear-text keying material outside of an SCD when used within a secure room in accordance with Requirement 32.
21-1.a Examine documented procedures for key storage and usage to verify that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions).
Note for hybrid decryption solutions: Requirements specific to hybrid decryption solutions are denoted throughout Control Objective 6.
Note: Key-injection facilities may have clear-text keying material outside of an SCD when used within a secure room in accordance with Requirement 32.
21-1.a Examine documented procedures for key storage and usage to verify that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions).
Added
p. 189
In an m-of-n scheme where n=5, where three shares are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key shares (e.g., share A and share B; and a second custodian (with, in this example, share C) would be required to reconstruct the final key, ensuring that dual control is maintained.
21-3.1.b Inspect any tamper-evident packaging used to secure key components
21-3.1.b Inspect any tamper-evident packaging used to secure key components
Added
p. 191
21-4 Private keys used to sign certificates, certificate status lists, messages, or for key protection must exist only in one or more of the following forms:
• Within a secure cryptographic device that meets applicable PCI PTS requirements for such a device,
• As components using a recognized secret-sharing scheme (e.g., Shamir) that are at all times managed under dual control and split knowledge.
21-4.a Examine documented key-management procedures to verify that private keys used to sign certificates, certificate-status lists, messages, or for key protection must exist only in one or more of the approved forms at all times.
21-4.b Observe key-management operations and interview key custodians and key- management supervisory personnel to verify that private keys used to sign certificates, certificate-status lists, messages, or for key protection must exist only in one or more of the approved forms at all times.
Requirement 22: Procedures must exist and must be demonstrably in use to replace …
• Within a secure cryptographic device that meets applicable PCI PTS requirements for such a device,
• As components using a recognized secret-sharing scheme (e.g., Shamir) that are at all times managed under dual control and split knowledge.
21-4.a Examine documented key-management procedures to verify that private keys used to sign certificates, certificate-status lists, messages, or for key protection must exist only in one or more of the approved forms at all times.
21-4.b Observe key-management operations and interview key custodians and key- management supervisory personnel to verify that private keys used to sign certificates, certificate-status lists, messages, or for key protection must exist only in one or more of the approved forms at all times.
Requirement 22: Procedures must exist and must be demonstrably in use to replace …
Added
p. 192
22-1.4.a Interview responsible personnel and examine documented processes to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions 22-1.5 Interview responsible personnel and examine documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions 22-2 If attempts to load a secret key or key component into a KLD or POI device (or a Host System, for hybrid decryption solutions) fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI device (or …
• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions 22-1.5 Interview responsible personnel and examine documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions 22-2 If attempts to load a secret key or key component into a KLD or POI device (or a Host System, for hybrid decryption solutions) fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI device (or …
Added
p. 194
22-3 Through the examination of documented procedures, interviews and observation confirm that Root CAs provide for segmentation of risk to address key compromise.
22-4 Mechanisms must be in place to respond to address compromise of a CA due to, for example, key compromise or mismanagement. This must include procedures to revoke or otherwise invalidate the usage of subordinate certificates, and notification of affected entities.
22-4.a Examine documented procedures to verify that mechanisms are defined to respond to compromise of a CA. Verify the mechanisms include procedures to:
22-4.b Interview responsible personnel to verify that the defined mechanisms to respond to compromise of a CA are in place and include:
22-4.1 The CA must cease issuance of certificates if a compromise is known or suspected and perform a damage assessment, including a documented analysis of how and why the event occurred.
22-4.1.a Examine documented procedures to verify that the following are required in the event a …
22-4 Mechanisms must be in place to respond to address compromise of a CA due to, for example, key compromise or mismanagement. This must include procedures to revoke or otherwise invalidate the usage of subordinate certificates, and notification of affected entities.
22-4.a Examine documented procedures to verify that mechanisms are defined to respond to compromise of a CA. Verify the mechanisms include procedures to:
22-4.b Interview responsible personnel to verify that the defined mechanisms to respond to compromise of a CA are in place and include:
22-4.1 The CA must cease issuance of certificates if a compromise is known or suspected and perform a damage assessment, including a documented analysis of how and why the event occurred.
22-4.1.a Examine documented procedures to verify that the following are required in the event a …
Added
p. 195
22-4.3.b Interview responsible personnel and observe implemented mechanisms to verify the prevention of the use of fraudulent certificates 22-4.4 The compromised CA must notify any superior or subordinate CAs of the compromise. The compromise damage analysis must include a determination of whether subordinate CAs and KDHs must have their certificates reissued and distributed to them or be notified to apply for new certificates.
22-4.4.a Examine documented procedures to verify that the following procedures are required in the event of a compromise:
− Reissue and distribute certificates to affected parties, or − Notify the affected parties to apply for new certificates.
22-4.4.b Interview responsible personnel to verify that the following procedures are performed in the event a compromise:
− Reissues and distributes certificates to affected parties, or − Notifies the affected parties to apply for new certificates.
22-5 Minimum cryptographic strength for the CA system must be:
• EPP/PED devices and KDHs have a minimum RSA 2048 …
22-4.4.a Examine documented procedures to verify that the following procedures are required in the event of a compromise:
− Reissue and distribute certificates to affected parties, or − Notify the affected parties to apply for new certificates.
22-4.4.b Interview responsible personnel to verify that the following procedures are performed in the event a compromise:
− Reissues and distributes certificates to affected parties, or − Notifies the affected parties to apply for new certificates.
22-5 Minimum cryptographic strength for the CA system must be:
• EPP/PED devices and KDHs have a minimum RSA 2048 …
Added
p. 199
Controls must include:
25-1.1 Examine key-custodian assignments for each component to verify that:
25-1.1 Examine key-custodian assignments for each component to verify that:
Added
p. 201
The components collectively held by an individual and his or her direct reports must not constitute a quorum (or must not provide any information about the value of the key that is not derivable from a single component).
A custodian must not become a custodian for a component/share of a key where the custodian has previously been or is currently a custodian for another component/share of that key if that would collectively constitute a quorum to form the actual key.
• A key custodian is not and has not been a custodian for another component/share of a key where that collectively would constitute a quorum to form the actual key.
A custodian must not become a custodian for a component/share of a key where the custodian has previously been or is currently a custodian for another component/share of that key if that would collectively constitute a quorum to form the actual key.
• A key custodian is not and has not been a custodian for another component/share of a key where that collectively would constitute a quorum to form the actual key.
Added
p. 202
• Ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian);
• Receive explicit training to instruct them from sharing key components with their direct manager;
• Sign key-custodian agreements that include an attestation to the requirement; and
• Receive training that includes procedures to report any violations.
25-2 All user access to material that can be used to construct secret and private keys (such as key components or key shares used to reconstitute a key) must be directly attributable to an individual user (e.g., through the use of unique IDs).
Note: Individual user IDs may be assigned to a role or group.
25-2.a Examine documented procedures to confirm that access to material that can be used to construct secret and private keys is directly attributable to an individual user.
25-2.b Observe the access-control mechanisms in place to verify that access to material that can be used to construct …
• Receive explicit training to instruct them from sharing key components with their direct manager;
• Sign key-custodian agreements that include an attestation to the requirement; and
• Receive training that includes procedures to report any violations.
25-2 All user access to material that can be used to construct secret and private keys (such as key components or key shares used to reconstitute a key) must be directly attributable to an individual user (e.g., through the use of unique IDs).
Note: Individual user IDs may be assigned to a role or group.
25-2.a Examine documented procedures to confirm that access to material that can be used to construct secret and private keys is directly attributable to an individual user.
25-2.b Observe the access-control mechanisms in place to verify that access to material that can be used to construct …
Added
p. 203
• Outside network access (e.g., using a separate platform in the DMZ) must exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
25-3.1 Examine network diagrams and observe network and system configurations to verify:
• Outside network access must exist only for the purposes of “pushing” certificate- status information to relying parties (e.g., KDHs).
25-3.2 For CAs operated online•e.g., POI-signing CAs: CA or Registration Authority (RA) software updates must not be done over the network (local console access must be used for CA or RA software updates).
25-3.2 Examine software update processes to verify that local console access is used for all CA or RA software updates.
25-3.3 For CAs operated online•e.g., POI-signing CAs: Non-console access must use multi-factor authentication. This also applies to the use of remote console access.
25-3.3 Examine remote-access mechanisms and system configurations to verify that all non-console access, including remote access, requires multi-factor authentication.
25-3.4 For CAs …
25-3.1 Examine network diagrams and observe network and system configurations to verify:
• Outside network access must exist only for the purposes of “pushing” certificate- status information to relying parties (e.g., KDHs).
25-3.2 For CAs operated online•e.g., POI-signing CAs: CA or Registration Authority (RA) software updates must not be done over the network (local console access must be used for CA or RA software updates).
25-3.2 Examine software update processes to verify that local console access is used for all CA or RA software updates.
25-3.3 For CAs operated online•e.g., POI-signing CAs: Non-console access must use multi-factor authentication. This also applies to the use of remote console access.
25-3.3 Examine remote-access mechanisms and system configurations to verify that all non-console access, including remote access, requires multi-factor authentication.
25-3.4 For CAs …
Added
p. 204
25-4.a Examine documented procedures to verify they include the following:
• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) 25-4.b Observe CA operations and interview responsible personnel to verify:
• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) 25-5 All CA systems that are not operated exclusively offline must be hardened to prevent insecure network access, to include:
• Services that are not necessary or that allow non- secure access (e.g., rlogin, rshell, telnet, ftp, etc.) must be removed or disabled.
25-5.a Examine system documentation to verify the following is required:
25-5.b For a sample of systems, examine documentation supporting the enablement of active services and ports, and observe system configurations to verify:
• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) 25-4.b Observe CA operations and interview responsible personnel to verify:
• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) 25-5 All CA systems that are not operated exclusively offline must be hardened to prevent insecure network access, to include:
• Services that are not necessary or that allow non- secure access (e.g., rlogin, rshell, telnet, ftp, etc.) must be removed or disabled.
25-5.a Examine system documentation to verify the following is required:
25-5.b For a sample of systems, examine documentation supporting the enablement of active services and ports, and observe system configurations to verify:
Added
p. 205
Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades must only be enabled when necessary and otherwise must be disabled from login.
25-5.1.a Examine documented procedures to verify that:
25-5.1.b Examine system configurations and interview responsible personnel to verify that:
25-5.2 Vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step must be changed, removed, or disabled before installing a system on the network.
25-5.2.a Examine documented procedures to verify that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on the network.
25-5.2.b Examine system configurations and interview responsible personnel to verify that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on …
25-5.1.a Examine documented procedures to verify that:
25-5.1.b Examine system configurations and interview responsible personnel to verify that:
25-5.2 Vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step must be changed, removed, or disabled before installing a system on the network.
25-5.2.a Examine documented procedures to verify that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on the network.
25-5.2.b Examine system configurations and interview responsible personnel to verify that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on …
Added
p. 206
• All key-management operations, such as key generation, loading, transmission, backup, recovery, compromise, destruction, and certificate generation or revocation
• Protection of the logs from alteration and destruction 25-6.a Examine system configurations and audit trails to verify that all key-management operations are logged.
25-6.b For a sample of key-management operations, examine audit trails to verify they include:
• Mechanisms exist to protect logs from alteration and destruction 25-6.1 Audit logs must be archived for a minimum of two years.
25-6.1 Examine audit trail files to verify that they are archived for a minimum of two years.
25-6.2 Records pertaining to certificate issuance and revocation must be retained for the life of the associated certificate, at a minimum.
25-6.2.a For a sample of certificate issuances, examine audit records to verify that the records are retained for at least the life of the associated certificate.
25-6.2.b For a sample of certificate revocations, examine audit records to verify that the …
• Protection of the logs from alteration and destruction 25-6.a Examine system configurations and audit trails to verify that all key-management operations are logged.
25-6.b For a sample of key-management operations, examine audit trails to verify they include:
• Mechanisms exist to protect logs from alteration and destruction 25-6.1 Audit logs must be archived for a minimum of two years.
25-6.1 Examine audit trail files to verify that they are archived for a minimum of two years.
25-6.2 Records pertaining to certificate issuance and revocation must be retained for the life of the associated certificate, at a minimum.
25-6.2.a For a sample of certificate issuances, examine audit records to verify that the records are retained for at least the life of the associated certificate.
25-6.2.b For a sample of certificate revocations, examine audit records to verify that the …
Added
p. 207
• Success or failure of the event 25-7 CA application logs must use a digital signature or a symmetric MAC (based on one of the methods stated in ISO 16609
25-7.a Examine log security controls to verify that CA application logs use a digital signature or a symmetric MAC (based on one of the methods stated in ISO 16609
25-7.b Examine documentation and interview personnel and observe to verify that signing/MACing key(s) used for this are protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
25-7.a Examine log security controls to verify that CA application logs use a digital signature or a symmetric MAC (based on one of the methods stated in ISO 16609
25-7.b Examine documentation and interview personnel and observe to verify that signing/MACing key(s) used for this are protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
Added
p. 208
• Fail to a configuration that denies all services and require a firewall administrator to re-enable services after a failure.
• Fail to a configuration that denies all services and require a firewall administrator to re-enable services after a failure.
25-7.1.a Examine network and system configurations to verify that certificate- processing system components operated online are protected from unauthorized access by firewall(s).
25-7.1.b Examine firewall configurations to verify they are configured to:
25-7.2 Online certificate-processing systems must employ individually, or in combination, network and host-based intrusion detection systems (IDS) to detect inappropriate access. At a minimum, database servers and the application servers for RA and web, as well as the intervening segments, must be covered.
25-7.2.a Observe network-based and/or host-based IDS configurations to verify that on-line certificate-processing systems are protected by IDS to detect inappropriate access.
25-7.2.b Verify that IDS coverage includes all database servers, RA application servers and web servers, as well as the intervening …
• Fail to a configuration that denies all services and require a firewall administrator to re-enable services after a failure.
25-7.1.a Examine network and system configurations to verify that certificate- processing system components operated online are protected from unauthorized access by firewall(s).
25-7.1.b Examine firewall configurations to verify they are configured to:
25-7.2 Online certificate-processing systems must employ individually, or in combination, network and host-based intrusion detection systems (IDS) to detect inappropriate access. At a minimum, database servers and the application servers for RA and web, as well as the intervening segments, must be covered.
25-7.2.a Observe network-based and/or host-based IDS configurations to verify that on-line certificate-processing systems are protected by IDS to detect inappropriate access.
25-7.2.b Verify that IDS coverage includes all database servers, RA application servers and web servers, as well as the intervening …
Added
p. 209
25.8.2.a For a sample of system components, examine user ID lists to verify the following:
25.8.2.b Examine authentication policies/procedures to verify that group and shared passwords or other authentication methods are explicitly prohibited.
25.8.2.c Interview system administrators to verify that group and shared passwords or other authentication methods are not distributed, even if requested.
25.8.2.b Examine authentication policies/procedures to verify that group and shared passwords or other authentication methods are explicitly prohibited.
25.8.2.c Interview system administrators to verify that group and shared passwords or other authentication methods are not distributed, even if requested.
Added
p. 210
25.8.8.a Examine policies and procedures and interview personnel to determine that the embedding of passwords in shell scripts, command files, communication scripts, etc. is strictly prohibited.
25.8.8.b Inspect a sample of shell scripts, command files, communication scripts, etc. to verify that passwords are not embedded in shell scripts, command files, or communication scripts.
25.8.8.b Inspect a sample of shell scripts, command files, communication scripts, etc. to verify that passwords are not embedded in shell scripts, command files, or communication scripts.
Added
p. 210
25.8.9.a If log-on security tokens are used, observe devices in use to verify that the security tokens have an associated usage-authentication mechanism, such as a biometric or associated PIN/passphrase to enable their usage.
25.8.9.b Examine token-configuration settings to verify parameters are set to require that PINs/passwords be at least eight decimal digits in length, or equivalent.
25.8.9.b Examine token-configuration settings to verify parameters are set to require that PINs/passwords be at least eight decimal digits in length, or equivalent.
Added
p. 210
25.9.a Examine documented procedures and system configuration standards to verify a method is defined to synchronize all critical system clocks and times for all systems involved in key-management operations.
25.9.b For a sample of critical systems, examine the time-related system parameters to verify that system clocks and times are synchronized for all systems involved in key-management operations.
25.9.c If a manual process is defined, verify that the documented procedures require that it occur at least quarterly.
25.9.d If a manual process is defined, examine system configurations and synchronization logs to verify that the process occurs at least quarterly.
• Name and signature of a non-custodian (for that component/share) witness
Note for hybrid decryption solutions: Clear-text cryptographic keys used on the Host System must not be included in any system back-up (refer to Requirement 4D-1.14) 27-1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as …
25.9.b For a sample of critical systems, examine the time-related system parameters to verify that system clocks and times are synchronized for all systems involved in key-management operations.
25.9.c If a manual process is defined, verify that the documented procedures require that it occur at least quarterly.
25.9.d If a manual process is defined, examine system configurations and synchronization logs to verify that the process occurs at least quarterly.
• Name and signature of a non-custodian (for that component/share) witness
Note for hybrid decryption solutions: Clear-text cryptographic keys used on the Host System must not be included in any system back-up (refer to Requirement 4D-1.14) 27-1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as …
Added
p. 213
28-1 Written procedures must exist and all affected parties must be aware of those procedures. All activities related to key administration must be documented. This includes all aspects of key administration, as well as:
• Training of all key custodians regarding their responsibilities, and forming part of their annual security training
• Training of all key custodians regarding their responsibilities, and forming part of their annual security training
28-2 CA operations must be dedicated to certificate issuance and management. All physical and logical CA system components must be separated from key- distribution systems.
28-2.a Examine documented procedures to verify:
28-2.b Observe CA system configurations and operations to verify they are dedicated to certificate issuance and management.
28-2.c Observe system and network configurations and physical access controls to verify that all physical and logical CA system components are separated from key- distribution systems.
• Training of all key custodians regarding their responsibilities, and forming part of their annual security training
• Training of all key custodians regarding their responsibilities, and forming part of their annual security training
28-2 CA operations must be dedicated to certificate issuance and management. All physical and logical CA system components must be separated from key- distribution systems.
28-2.a Examine documented procedures to verify:
28-2.b Observe CA system configurations and operations to verify they are dedicated to certificate issuance and management.
28-2.c Observe system and network configurations and physical access controls to verify that all physical and logical CA system components are separated from key- distribution systems.
Added
p. 214
• The CA must operate in accordance with its CPS.
The CPS must be consistent with the requirements described within this document. The CA must operate in accordance with its CPS.
28-3.a Examine documented certification practice statement (CPS) to verify that the CPS is consistent with the requirements described within this document.
28-3.b Examine documented operating procedures to verify they are defined in accordance with the CPS.
28-3.c Interview personnel and observe CA processes to verify that CA operations are in accordance with its CPS.
28-4 Each CA operator must develop a certificate policy. (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.) 28-4 Examine documented certificate policy to verify that the CA has one in place.
The CPS must be consistent with the requirements described within this document. The CA must operate in accordance with its CPS.
28-3.a Examine documented certification practice statement (CPS) to verify that the CPS is consistent with the requirements described within this document.
28-3.b Examine documented operating procedures to verify they are defined in accordance with the CPS.
28-3.c Interview personnel and observe CA processes to verify that CA operations are in accordance with its CPS.
28-4 Each CA operator must develop a certificate policy. (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.) 28-4 Examine documented certificate policy to verify that the CA has one in place.
Added
p. 215
• Verification of the certificate applicant’s possession of the associated private key through the use of a digitally signed certificate request pursuant to PKCS #10 or another cryptographically equivalent demonstration;
• Determination that the organization exists by using at least one third-party identity-proofing service or database or, alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization;
28-5.a Examine documented procedures to verify that unless the certificate request is generated within the same secure room meeting the requirements of the Level 3 environment, they include validating the identity of the certificate requestor and recipient before issuing a digital certificate for the recipient’s associated public key.
28-5.b Observe certificate-issuing processes to verify that the identities of the certificate requestor and recipient are validated before issuing a digital certificate for the recipient’s associated public key.
• Determination that the organization exists by using at least one third-party identity-proofing service or database or, alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization;
28-5.a Examine documented procedures to verify that unless the certificate request is generated within the same secure room meeting the requirements of the Level 3 environment, they include validating the identity of the certificate requestor and recipient before issuing a digital certificate for the recipient’s associated public key.
28-5.b Observe certificate-issuing processes to verify that the identities of the certificate requestor and recipient are validated before issuing a digital certificate for the recipient’s associated public key.
Added
p. 216
28-5.1.a Examine documented procedures to verify that certificate-signing requests, including certificate or key-validity status changes, require validation that:
28-5.1.b Observe certificate-signing requests, including certificate or key-validity status changes, to verify they include validation that:
28-5.2 RAs must retain documentation and audit trails relating to the identification of entities for all certificates issued and certificates whose status had changed for the life of the associated certificates.
28-5.2 Examine documentation and audit trails to verify that the identification of entities is retained for the life of the associated certificates:
28-5.1.b Observe certificate-signing requests, including certificate or key-validity status changes, to verify they include validation that:
28-5.2 RAs must retain documentation and audit trails relating to the identification of entities for all certificates issued and certificates whose status had changed for the life of the associated certificates.
28-5.2 Examine documentation and audit trails to verify that the identification of entities is retained for the life of the associated certificates:
Added
p. 217
• both prior to and subsequent to the loading of cryptographic keys
•and that precautions are taken to minimize the threat of compromise once deployed.
Note: Where POI is mentioned in Requirement 29, the requirements apply to the solution provider managing POI devices prior to deployment to distribution channels or to the merchants that will process payments with the POI device. Merchant protection and use of POI devices once deployed are not the subject of these P2PE requirements and are instead covered by guidance provided to merchants by the solution provider in the P2PE Instruction Manual (PIM). See the PIM Template for more information about guidance required to be included in the PIM.
Likewise, distribution channels used by a solution provider to distribute POI devices to the end merchant are also not the subjects of these P2PE requirements. However, regardless of the distribution channel used, the merchant that will process payments with the …
•and that precautions are taken to minimize the threat of compromise once deployed.
Note: Where POI is mentioned in Requirement 29, the requirements apply to the solution provider managing POI devices prior to deployment to distribution channels or to the merchants that will process payments with the POI device. Merchant protection and use of POI devices once deployed are not the subject of these P2PE requirements and are instead covered by guidance provided to merchants by the solution provider in the P2PE Instruction Manual (PIM). See the PIM Template for more information about guidance required to be included in the PIM.
Likewise, distribution channels used by a solution provider to distribute POI devices to the end merchant are also not the subjects of these P2PE requirements. However, regardless of the distribution channel used, the merchant that will process payments with the …
Added
p. 221
Note: Unauthorized access includes that by customs officials. o Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised.
29-4.1.a Interview responsible personnel to verify that device serial numbers are compared to the serial number documented by the sender.
Documentation (e.g., a checklist or similar suitable to use as a log) of configuration settings must exist and be signed and dated by personnel responsible for the implementation. This documentation must include identifying information for the HSM, such as serial number and/or asset identifiers. This documentation must be retained and updated for each affected HSM any time changes to configuration settings would impact security.
29-4.2.a Obtain and examine the defined security policy to be enforced by the HSM.
29-4.2.d Not used in P2PE 29-4.2.e Not used in P2PE 29-4.2.f Examine documentation to verify:
• Configuration settings are defined, signed, and dated …
29-4.1.a Interview responsible personnel to verify that device serial numbers are compared to the serial number documented by the sender.
Documentation (e.g., a checklist or similar suitable to use as a log) of configuration settings must exist and be signed and dated by personnel responsible for the implementation. This documentation must include identifying information for the HSM, such as serial number and/or asset identifiers. This documentation must be retained and updated for each affected HSM any time changes to configuration settings would impact security.
29-4.2.a Obtain and examine the defined security policy to be enforced by the HSM.
29-4.2.d Not used in P2PE 29-4.2.e Not used in P2PE 29-4.2.f Examine documentation to verify:
• Configuration settings are defined, signed, and dated …
Added
p. 223
29-4.3 Examine HSM configurations and observe processes to verify that HSMs are not enabled in a sensitive state when connected to online systems.
29-4.4.1 Running self-tests to ensure the correct operation of the device.
29-4.4.2 Installing (or re-installing) devices only after confirming that the device has not been tampered with or compromised.
29-4.4.4 Maintaining records of the tests and inspections, and retaining records for at least one year.
Key-injection facilities (or applicable entities providing key-management services) must ensure protection against unauthorized use of SCDs (e.g., HSMs) used in the key-injection platform that are capable of encrypting a key and producing cryptograms of that key.
Requirement 31: Procedures must be in place and implemented to protect any SCDs•and ensure the destruction of any cryptographic keys or key material within such devices•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.
Note: The requirements within Requirement 31 apply to the solution provider …
29-4.4.1 Running self-tests to ensure the correct operation of the device.
29-4.4.2 Installing (or re-installing) devices only after confirming that the device has not been tampered with or compromised.
29-4.4.4 Maintaining records of the tests and inspections, and retaining records for at least one year.
Key-injection facilities (or applicable entities providing key-management services) must ensure protection against unauthorized use of SCDs (e.g., HSMs) used in the key-injection platform that are capable of encrypting a key and producing cryptograms of that key.
Requirement 31: Procedures must be in place and implemented to protect any SCDs•and ensure the destruction of any cryptographic keys or key material within such devices•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.
Note: The requirements within Requirement 31 apply to the solution provider …
Added
p. 226
Note: Dual control is not explicitly required by the HSM itself. E.g., an HSM with a decommission-type physical button (e.g., a zeroize button) is acceptable provided physical access to the HSM (and therefore the mechanism for decommissioning) requires dual control.
Added
p. 227
32-1.b Verify that documented procedures cover requirements 32-1.1 through 32-1.5 below.
Added
p. 228
32-1.4 Devices must not use default passwords/authentication codes.
Added
p. 229
32-2.1.a Examine physical security policies to verify three tiers of physical security are defined as follows:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices 32-2.1.b Observe the physical facility to verify three tiers of physical security are implemented as follows:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Level 1 Barrier 32-2.2 The entrance to the CA facility/building must include the following controls:
32-2.2.1 The facility entrance only allows authorized personnel to enter the facility.
32-2.2.1.a Examine physical-security procedures and policies to verify they require that the facility entrance allows only authorized personnel to enter the facility.
32-2.2.1.b Observe the facility entrance and observe personnel entering the facility to verify that only authorized personnel are allowed to enter the facility.
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices 32-2.1.b Observe the physical facility to verify three tiers of physical security are implemented as follows:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Level 1 Barrier 32-2.2 The entrance to the CA facility/building must include the following controls:
32-2.2.1 The facility entrance only allows authorized personnel to enter the facility.
32-2.2.1.a Examine physical-security procedures and policies to verify they require that the facility entrance allows only authorized personnel to enter the facility.
32-2.2.1.b Observe the facility entrance and observe personnel entering the facility to verify that only authorized personnel are allowed to enter the facility.
Added
p. 230
32-2.2.2.a Examine physical-security procedures and policies to verify they require that the facility have a guarded entrance or a foyer with a receptionist or the entryway prevents access to visitors.
32-2.2.2.b Observe the facility entrance to verify it has a guarded entrance or a foyer with a receptionist.
32-2.2.3 Visitors (guests) to the facility must be authorized and be registered in a logbook.
32-2.2.3.a Examine physical-security procedures and policies to verify they require visitors to the facility to be authorized and be registered in a logbook.
32-2.2.3.b Observe the facility entrance and observe personnel entering the facility to verify that visitors are authorized and registered in a logbook.
Level 2 Barrier 32-2.3 The Level 2 barrier/entrance must only allow authorized personnel beyond this entrance.
32-2.3.a Examine physical-security procedures and policies to verify that only authorized personnel are allowed beyond the Level 2 barrier/entrance.
32-2.3.b Observe personnel entering the Level 2 barrier/entrance to verify that only authorized personnel …
32-2.2.2.b Observe the facility entrance to verify it has a guarded entrance or a foyer with a receptionist.
32-2.2.3 Visitors (guests) to the facility must be authorized and be registered in a logbook.
32-2.2.3.a Examine physical-security procedures and policies to verify they require visitors to the facility to be authorized and be registered in a logbook.
32-2.2.3.b Observe the facility entrance and observe personnel entering the facility to verify that visitors are authorized and registered in a logbook.
Level 2 Barrier 32-2.3 The Level 2 barrier/entrance must only allow authorized personnel beyond this entrance.
32-2.3.a Examine physical-security procedures and policies to verify that only authorized personnel are allowed beyond the Level 2 barrier/entrance.
32-2.3.b Observe personnel entering the Level 2 barrier/entrance to verify that only authorized personnel …
Added
p. 231
32-2.5.a Examine documented policies and procedures to verify that all certificate- processing systems must be located within a Level 3 environment.
32-2.5.b Examine physical locations of certificate operations to verify that all certificate-processing systems are located within a Level 3 secure room.
32-2.5.c Observe operations and interview personnel to confirm that the Level 3 secure room is not used for any business activity other than certificate operations.
32-2.5.1 Doors to the Level 3 secure room must have locking mechanisms.
32-2.5.1 Observe Level 3 environment entrances to verify that all doors to the Level 3 environment have locking mechanisms.
32-2.5.2 The Level 3 environment must be enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars.
32-2.5.2.a Examine physical security documentation for the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such …
32-2.5.b Examine physical locations of certificate operations to verify that all certificate-processing systems are located within a Level 3 secure room.
32-2.5.c Observe operations and interview personnel to confirm that the Level 3 secure room is not used for any business activity other than certificate operations.
32-2.5.1 Doors to the Level 3 secure room must have locking mechanisms.
32-2.5.1 Observe Level 3 environment entrances to verify that all doors to the Level 3 environment have locking mechanisms.
32-2.5.2 The Level 3 environment must be enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars.
32-2.5.2.a Examine physical security documentation for the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such …
Added
p. 232
32-2.6.1.a Examine documented policies and procedures to verify they require personnel authorized as having access through the Level 3 barrier to:
32-2.6.1.b Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws) on CA personnel prior such personnel being authorized for access through the Level 3 barrier.
32-2.6.1.c Interview a sample of personnel authorized for access through the Level 3 barrier to verify that they are assigned resources of the CA with defined business needs and duties.
32-2.6.2 Other personnel requiring entry to this level must be accompanied by two (2) authorized and assigned resources at all times.
32-2.6.2.a Examine documented policies and procedures to verify that personnel requiring entry to this level must be accompanied by two (2) authorized and assigned resources at all times.
32-2.6.2.b Interview a sample of responsible personnel to verify that personnel requiring entry to this level are accompanied by two (2) authorized …
32-2.6.1.b Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws) on CA personnel prior such personnel being authorized for access through the Level 3 barrier.
32-2.6.1.c Interview a sample of personnel authorized for access through the Level 3 barrier to verify that they are assigned resources of the CA with defined business needs and duties.
32-2.6.2 Other personnel requiring entry to this level must be accompanied by two (2) authorized and assigned resources at all times.
32-2.6.2.a Examine documented policies and procedures to verify that personnel requiring entry to this level must be accompanied by two (2) authorized and assigned resources at all times.
32-2.6.2.b Interview a sample of responsible personnel to verify that personnel requiring entry to this level are accompanied by two (2) authorized …
Added
p. 233
32-2.7.2.b Observe mechanisms in use and authorized personnel within the environment to verify that anti-pass-back is enforced by the conduct of a test.
32-2.7.3 Dual occupancy requirements are managed using electronic (e.g., badge and/or biometric) systems.
32-2.7.3.a Examine documented policies and procedures to verify that dual occupancy requirements are defined to be managed using electronic (e.g., badge and/or biometric) systems.
32-2.7.3.b Observe mechanisms in use and authorized personnel within the environment to verify that dual-occupancy requirements are managed using electronic systems.
32-2.7.4 Any time a single occupancy exceeds 30 seconds, the system must automatically generate an alarm and audit event that is followed up by security personnel.
32-2.7.4.a Examine documented policies and procedures to verify that any time one person is alone in the room for more than 30 seconds, the system must automatically generate an alarm and an audit event that is followed up by security personnel.
32-2.7.4.b Observe mechanisms in use to verify that …
32-2.7.3 Dual occupancy requirements are managed using electronic (e.g., badge and/or biometric) systems.
32-2.7.3.a Examine documented policies and procedures to verify that dual occupancy requirements are defined to be managed using electronic (e.g., badge and/or biometric) systems.
32-2.7.3.b Observe mechanisms in use and authorized personnel within the environment to verify that dual-occupancy requirements are managed using electronic systems.
32-2.7.4 Any time a single occupancy exceeds 30 seconds, the system must automatically generate an alarm and audit event that is followed up by security personnel.
32-2.7.4.a Examine documented policies and procedures to verify that any time one person is alone in the room for more than 30 seconds, the system must automatically generate an alarm and an audit event that is followed up by security personnel.
32-2.7.4.b Observe mechanisms in use to verify that …
Added
p. 234
32-2.9.1 A minimum of one or more cameras must provide continuous monitoring (e.g., CCTV system) of the Level 3 environment, including the entry and exit.
32-2.9.1.a Observe the Level 3 physical environment to verify that cameras are in place to monitor the Level 3 environment, including the entry and exit.
32-2.9.1.b Examine monitoring system configurations (e.g., CCTV systems) to verify that continuous monitoring is provided.
32-2.9.1.c If motion-activated systems are used for monitoring, observe system configurations for the motion-activated systems to verify they are separate from the intrusion-detection system.
32-2.9.2 The cameras must record to time-lapse VCRs or similar mechanisms, with a minimum of five frames equally recorded over every three seconds.
32-2.9.2 Examine monitoring system configurations to verify;
32-2.9.3 Continuous or motion-activated, appropriate lighting must be provided for the cameras.
32-2.9.3.a Observe the Level 3 physical environment to verify that continuous or motion-activated lighting is provided for each camera monitoring the environment.
32-2.9.3.b Examine a sample of …
32-2.9.1.a Observe the Level 3 physical environment to verify that cameras are in place to monitor the Level 3 environment, including the entry and exit.
32-2.9.1.b Examine monitoring system configurations (e.g., CCTV systems) to verify that continuous monitoring is provided.
32-2.9.1.c If motion-activated systems are used for monitoring, observe system configurations for the motion-activated systems to verify they are separate from the intrusion-detection system.
32-2.9.2 The cameras must record to time-lapse VCRs or similar mechanisms, with a minimum of five frames equally recorded over every three seconds.
32-2.9.2 Examine monitoring system configurations to verify;
32-2.9.3 Continuous or motion-activated, appropriate lighting must be provided for the cameras.
32-2.9.3.a Observe the Level 3 physical environment to verify that continuous or motion-activated lighting is provided for each camera monitoring the environment.
32-2.9.3.b Examine a sample of …
Added
p. 235
32-2.9.5.a Examine documented access policies and procedures to verify that personnel with access to the Level 3 environment are not permitted to have access to the media containing recorded surveillance data for that environment.
32-2.9.5.b Examine Level 3 access lists as well as access controls to the media containing surveillance data, to verify that personnel with access to the Level 3 environment do not have access to the media containing recorded surveillance data.
32-2.9.6 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days.
If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy (primary and backup) to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
32-2.9.6.a Examine storage of captured recordings to verify that at least the most recent 45 days of images are securely archived.
32-2.9.6.b If digital-recording mechanisms are used, examine system configurations …
32-2.9.5.b Examine Level 3 access lists as well as access controls to the media containing surveillance data, to verify that personnel with access to the Level 3 environment do not have access to the media containing recorded surveillance data.
32-2.9.6 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days.
If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy (primary and backup) to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
32-2.9.6.a Examine storage of captured recordings to verify that at least the most recent 45 days of images are securely archived.
32-2.9.6.b If digital-recording mechanisms are used, examine system configurations …
Added
p. 236
32-3.1.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors.
32-3.1.b Examine the configuration of window sensors to verify that the alarm mechanism is active.
32-3.1.c Test at least one window (if they can be opened) to verify that the alarms function appropriately.
32-3.2 Any windows or glass walls must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
32-3.2 Observe all windows and glass walls in the secure room to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure area.
32-3.3 The intrusion-detection system(s) must be connected to the alarm system and automatically activated every time all authorized personnel have performed an authenticated exit of the secure room. The system must be configured to activate within 30 seconds.
32-3.3.a Examine security system configurations to verify:
• The intrusion-detection system(s) is automatically activated every time all authorized personnel …
32-3.1.b Examine the configuration of window sensors to verify that the alarm mechanism is active.
32-3.1.c Test at least one window (if they can be opened) to verify that the alarms function appropriately.
32-3.2 Any windows or glass walls must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
32-3.2 Observe all windows and glass walls in the secure room to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure area.
32-3.3 The intrusion-detection system(s) must be connected to the alarm system and automatically activated every time all authorized personnel have performed an authenticated exit of the secure room. The system must be configured to activate within 30 seconds.
32-3.3.a Examine security system configurations to verify:
• The intrusion-detection system(s) is automatically activated every time all authorized personnel …
Added
p. 237
• For visitor access, the initials of the person escorting the visitor 32-4.1 Examine the access logbook to verify it contains the following information:
• For visitor access, the initials of the person escorting the visitor 32-4.2 The logbook must be maintained within the Level 3 secure environment.
32-4.2 Observe the location of the access logbook and verify that it is maintained within the Level 3 secure environment.
32-5 All access-control and monitoring systems (including intrusion-detection systems) are powered through an uninterruptible power source (UPS).
32-5 Inspect uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems, including intrusion-detection systems, are powered through the UPS.
32-6 All alarm events must be documented. 32-6.a Examine security policies and procedures to verify they require that all alarm events be logged.
32-6.b Examine security-system configurations and documented alarm events to verify that all alarm events are logged.
32-6.1 An individual must not sign off on an …
• For visitor access, the initials of the person escorting the visitor 32-4.2 The logbook must be maintained within the Level 3 secure environment.
32-4.2 Observe the location of the access logbook and verify that it is maintained within the Level 3 secure environment.
32-5 All access-control and monitoring systems (including intrusion-detection systems) are powered through an uninterruptible power source (UPS).
32-5 Inspect uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems, including intrusion-detection systems, are powered through the UPS.
32-6 All alarm events must be documented. 32-6.a Examine security policies and procedures to verify they require that all alarm events be logged.
32-6.b Examine security-system configurations and documented alarm events to verify that all alarm events are logged.
32-6.1 An individual must not sign off on an …
Added
p. 238
32-6.3.a Examine documented procedures to verify they require that all alarms for physical intrusion must be responded to within 30 minutes by personnel assigned security duties.
32-6.3.b Examine a sample of alarm events and interview personnel assigned with security-response duties to verify that alarms for physical intrusion are responded to within 30 minutes.
32-6.3.c Conduct a test to verify the appropriate response occurs.
32-7 A process must be implemented for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems to ensure accuracy of logs. It must be ensured that synchronization errors between CCTV, intrusion detection, and access control cannot exceed one minute.
32-7.a Examine documented procedures to verify that mechanisms are defined (may be automated or manual) for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems to ensure accuracy of logs.
32-7.b Examine system configurations for access, intrusion-detection, and monitoring (camera) systems to verify …
32-6.3.b Examine a sample of alarm events and interview personnel assigned with security-response duties to verify that alarms for physical intrusion are responded to within 30 minutes.
32-6.3.c Conduct a test to verify the appropriate response occurs.
32-7 A process must be implemented for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems to ensure accuracy of logs. It must be ensured that synchronization errors between CCTV, intrusion detection, and access control cannot exceed one minute.
32-7.a Examine documented procedures to verify that mechanisms are defined (may be automated or manual) for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems to ensure accuracy of logs.
32-7.b Examine system configurations for access, intrusion-detection, and monitoring (camera) systems to verify …
Added
p. 241
• Effective 1 January 2021 the injection of clear-text secret or private keying material must not be allowed for entities engaged in key injection on behalf of others. Only encrypted key injection will be allowed for POI v3 and higher devices.
Added
p. 241
• Effective 1 January 2023, the same restriction applies to entities engaged in key injection of devices for which they are the processors. Note: This does not apply to key components entered into the keypad of a secure cryptographic device, such as a device approved against the PCI PTS POI Security Requirements. It does apply to all other methods of loading of clear-text keying material for POI v3 and higher devices.
Added
p. 242
Note: In KIF environments where Level 1 and Level 2 physical barrier controls are in place and confirmed, the secure room may be implemented within a “caged” environment. A caged environment is an enclosed secure room that meets the criteria of Requirement 32 but is not made of solid walls. Refer to applicable requirements within this Domain for additional information on Level 1 and Level 2 physical barrier controls. All other criteria stated in Requirements 13-9 and 32-9 relating to clear-text secret and/or private keys and/or their components existing in unprotected memory outside the secure boundary of an SCD for loading keys apply.
Added
p. 244
32-9.12 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days.
32-9.12.a Examine storage of captured recordings to verify that at least the most recent 45 days of images are securely archived.
32-9.12.b If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
Requirement 33: Documented procedures must exist and be demonstrably in use to ensure the security and integrity of account-data processing equipment (e.g., POI devices and HSMs) placed into service, initialized, deployed, used, and decommissioned.
33-1 Written procedures must exist, and all affected parties must be aware of those procedures. Records must be maintained of the tests and inspections performed on account- data processing devices before they are placed into service, as well as devices being decommissioned.
Requirement 5A: Account data is …
32-9.12.a Examine storage of captured recordings to verify that at least the most recent 45 days of images are securely archived.
32-9.12.b If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
Requirement 33: Documented procedures must exist and be demonstrably in use to ensure the security and integrity of account-data processing equipment (e.g., POI devices and HSMs) placed into service, initialized, deployed, used, and decommissioned.
33-1 Written procedures must exist, and all affected parties must be aware of those procedures. Records must be maintained of the tests and inspections performed on account- data processing devices before they are placed into service, as well as devices being decommissioned.
Requirement 5A: Account data is …
Added
p. 247
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) 5A-1.3.2.a Examine key-management policies and procedures and verify a list of all devices used to generate keys managed as part of the P2PE solution is required, and includes:
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) 5A-1.3.2.b Observe documentation and interview personnel and confirm that a list of all devices used to generate keys managed as part of the P2PE solution exists, and includes:
Requirement 5H: For hybrid decryption solutions: Implement secure hybrid key management Domain 5 Requirements Testing Procedures 5H-1 Hybrid decryption solutions securely manage the Data Decryption Keys (DDKs) that decrypt account data in software on a Host System.
Note: DDKs used to decrypt account data in a Host System are the ONLY keys that can ever be managed in software per these 5H Requirements; all other cryptographic keys used in hybrid decryption solutions are …
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) 5A-1.3.2.b Observe documentation and interview personnel and confirm that a list of all devices used to generate keys managed as part of the P2PE solution exists, and includes:
Requirement 5H: For hybrid decryption solutions: Implement secure hybrid key management Domain 5 Requirements Testing Procedures 5H-1 Hybrid decryption solutions securely manage the Data Decryption Keys (DDKs) that decrypt account data in software on a Host System.
Note: DDKs used to decrypt account data in a Host System are the ONLY keys that can ever be managed in software per these 5H Requirements; all other cryptographic keys used in hybrid decryption solutions are …
Added
p. 254
MM-A Restrict access between the merchant decryption environment and all other networks/systems.
MM-B Restrict traffic between the encryption environment and any other CDE.
MM-C Restrict personnel access between the encryption environment and the merchant decryption environment.
Target Audience: This appendix, in addition to applicable Domains, applies only to merchants that manage their own P2PE solutions.
Some merchants may choose to manage their own P2PE solution on behalf of their own merchant encryption environments rather than fully outsourcing the solution to a third-party solution provider. This type of P2PE solution is defined as a “merchant-managed solution” since the merchant is acting as its own P2PE solution provider. This appendix specifies the additional requirements that must be met for a merchant- managed solution with the objective of reducing the presence of clear-text account data within their encryption environments.
This appendix is only applicable to merchants acting as their own P2PE solution providers, as defined in this Standard. …
MM-B Restrict traffic between the encryption environment and any other CDE.
MM-C Restrict personnel access between the encryption environment and the merchant decryption environment.
Target Audience: This appendix, in addition to applicable Domains, applies only to merchants that manage their own P2PE solutions.
Some merchants may choose to manage their own P2PE solution on behalf of their own merchant encryption environments rather than fully outsourcing the solution to a third-party solution provider. This type of P2PE solution is defined as a “merchant-managed solution” since the merchant is acting as its own P2PE solution provider. This appendix specifies the additional requirements that must be met for a merchant- managed solution with the objective of reducing the presence of clear-text account data within their encryption environments.
This appendix is only applicable to merchants acting as their own P2PE solution providers, as defined in this Standard. …
Added
p. 255
Note: If a merchant outsources the decryption environment to a PCI-listed P2PE decryption-management component provider, this appendix would not apply for the merchant-managed solution, and use of a PCI-listed component provider would be noted in the merchant-as-a-solution- provider’s P2PE Report on Validation (P-ROV). If a merchant outsources the decryption environment to a non-listed decryption service provider, this appendix would also not apply and Domain 4 (covering the outsourced decryption services) would be assessed as part of the merchant-as- solution-provider’s P2PE assessment and included in the merchant’s P-ROV.
• Only use hardware-based decryption as part of the P2PE solution (use of hybrid decryption in a merchant-managed P2PE solution is not permitted).
• Satisfy all P2PE domain requirements (Domains 1, 2, 3, 4, and 5) in this standard, including this Appendix.
• Undergo a full P2PE assessment by a qualified P2PE assessor.
• Only use hardware-based decryption as part of the P2PE solution (use of hybrid decryption in a merchant-managed P2PE solution is not permitted).
• Satisfy all P2PE domain requirements (Domains 1, 2, 3, 4, and 5) in this standard, including this Appendix.
• Undergo a full P2PE assessment by a qualified P2PE assessor.
Added
p. 256
Note: The TMS environment is in scope for PCI DSS Merchant Store Cardholder Data Storage & Processing Payment Decryption Notes Note: This diagram is for illustrative purposes only. Other implementations are acceptable as long as they meet the requirements specified in this appendix.
Note: This diagram focuses on traffic flows related to P2PE transaction processing and may not may not show all relevant payment transaction traffic.
Note: This diagram focuses on traffic flows related to P2PE transaction processing and may not may not show all relevant payment transaction traffic.
Added
p. 257
MM-A-1.1 Current documentation must be maintained that describes, or illustrates, the architecture of the merchant- managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
MM-A-1.1.a Interview responsible personnel and review documentation to verify that procedures exist for maintaining documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
MM-A-1.1.b Interview responsible personnel and review merchant documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs to verify that the document is kept current.
MM-A-1.2 Decryption systems must reside on a network …
MM-A-1.1.a Interview responsible personnel and review documentation to verify that procedures exist for maintaining documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
MM-A-1.1.b Interview responsible personnel and review merchant documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs to verify that the document is kept current.
MM-A-1.2 Decryption systems must reside on a network …
Added
p. 258
MM-A-1.3.a Inspect network and system configuration settings to verify that only necessary services, protocols, daemons, etc. are enabled, and any functions not required for performing or supporting decryption operations are disabled or isolated from decryption operations.
MM-A-1.3.b Review the documented record of services, protocols, daemons, etc. that are required by the decryption systems and verify that each service includes justification.
MM-A-1.4 Systems providing logical authentication services to system components within the decryption environment must:
MM-A-1.4.a Examine documented policies and procedures, and interview responsible personnel to verify that systems providing logical authentication services to system components within the decryption environment reside within the decryption environment and are dedicated to supporting the decryption environment.
MM-A-1.4.b Review system configurations and observe processes to verify that systems providing authentication services to system components within the decryption environment reside within the decryption environment and are dedicated to supporting the decryption environment.
MM-A-1.3.b Review the documented record of services, protocols, daemons, etc. that are required by the decryption systems and verify that each service includes justification.
MM-A-1.4 Systems providing logical authentication services to system components within the decryption environment must:
MM-A-1.4.a Examine documented policies and procedures, and interview responsible personnel to verify that systems providing logical authentication services to system components within the decryption environment reside within the decryption environment and are dedicated to supporting the decryption environment.
MM-A-1.4.b Review system configurations and observe processes to verify that systems providing authentication services to system components within the decryption environment reside within the decryption environment and are dedicated to supporting the decryption environment.
Added
p. 259
MM-A-1.5.a Examine documented policies and procedures, and interview responsible personnel to verify that logical administrative/privileged access to the systems within the decryption environment must be authorized and originate from within the merchant decryption environment.
MM-A-1.5.b Examine firewall/router configurations to verify that logical administrative/privileged access to systems within the decryption environment is authorized and originates from within the merchant decryption environment.
MM-A-1.6 All remote access features on all systems in the merchant decryption environment must be permanently disabled and/or otherwise prevented from being used MM-A-1.6 Review system configurations and observe processes to verify that all remote access features on all systems within the merchant decryption environment are permanently disabled and/or otherwise prevented from being used.
MM-A-1.7 Systems in the merchant decryption environment must not store account data.
MM-A-1.7.a Review configurations of all devices and systems in the merchant decryption environment to confirm none of the systems store account data.
MM-A-1.7.b Review data flows and interview personnel …
MM-A-1.5.b Examine firewall/router configurations to verify that logical administrative/privileged access to systems within the decryption environment is authorized and originates from within the merchant decryption environment.
MM-A-1.6 All remote access features on all systems in the merchant decryption environment must be permanently disabled and/or otherwise prevented from being used MM-A-1.6 Review system configurations and observe processes to verify that all remote access features on all systems within the merchant decryption environment are permanently disabled and/or otherwise prevented from being used.
MM-A-1.7 Systems in the merchant decryption environment must not store account data.
MM-A-1.7.a Review configurations of all devices and systems in the merchant decryption environment to confirm none of the systems store account data.
MM-A-1.7.b Review data flows and interview personnel …
Added
p. 260
MM-A-2.1.2.a Review firewall configuration standards to verify that inbound and outbound traffic necessary for performing and/or supporting decryption operations is identified and documented.
MM-A-2.1.2.b Examine firewall configurations to verify that inbound and outbound traffic between the decryption environment and any CDE is limited to only that which is necessary for performing and/or supporting decryption operations, and all other traffic is specifically denied (e.g., by using an explicit “deny all” or an implicit deny after an allow statement).
MM-A-2.2 Inbound and outbound traffic between the merchant CDE and the encryption environment must be restricted to approved POI devices located within the encryption environment.
MM-A-2.2 Examine network and system configurations to verify that inbound and outbound traffic between the merchant CDE and the encryption environment is restricted to approved POI devices located within the encryption environment.
MM-A-2.3 Processes must be implemented to prevent unauthorized physical connections (e.g., wireless access) to the decryption environment as follows:
MM-A-2.3.a Review …
MM-A-2.1.2.b Examine firewall configurations to verify that inbound and outbound traffic between the decryption environment and any CDE is limited to only that which is necessary for performing and/or supporting decryption operations, and all other traffic is specifically denied (e.g., by using an explicit “deny all” or an implicit deny after an allow statement).
MM-A-2.2 Inbound and outbound traffic between the merchant CDE and the encryption environment must be restricted to approved POI devices located within the encryption environment.
MM-A-2.2 Examine network and system configurations to verify that inbound and outbound traffic between the merchant CDE and the encryption environment is restricted to approved POI devices located within the encryption environment.
MM-A-2.3 Processes must be implemented to prevent unauthorized physical connections (e.g., wireless access) to the decryption environment as follows:
MM-A-2.3.a Review …
Added
p. 261
MM-B-1.1.a Review documentation to verify that inbound and outbound traffic necessary for transaction processing and/or terminal management purposes is identified and documented.
MM-B-1.1.b Examine firewall configurations to verify that any traffic between the encryption environment and any other CDE is limited as follows:
• Only traffic that is necessary for transaction processing and/or terminal management purposes Verify all other traffic between those two networks is specifically denied (e.g., by using an explicit “deny all” or an implicit deny after an allow statement).
MM-B-1.1.c Observe traffic between the encryption environment and any other CDE to verify the traffic is limited to systems directly related to supporting P2PE transactions, transaction processing, and/or terminal-management functions.
MM-B-1.2 Processes must be implemented to prevent clear-text account data from being transmitted from the CDE back to the encryption environment.
MM-B-1.2.a Review documented policies and procedures for the CDE to verify that the transmission of clear-text account data from the CDE back …
MM-B-1.1.b Examine firewall configurations to verify that any traffic between the encryption environment and any other CDE is limited as follows:
• Only traffic that is necessary for transaction processing and/or terminal management purposes Verify all other traffic between those two networks is specifically denied (e.g., by using an explicit “deny all” or an implicit deny after an allow statement).
MM-B-1.1.c Observe traffic between the encryption environment and any other CDE to verify the traffic is limited to systems directly related to supporting P2PE transactions, transaction processing, and/or terminal-management functions.
MM-B-1.2 Processes must be implemented to prevent clear-text account data from being transmitted from the CDE back to the encryption environment.
MM-B-1.2.a Review documented policies and procedures for the CDE to verify that the transmission of clear-text account data from the CDE back …
Added
p. 262
MM-C-1.1 Separation of duties must exist such that encryption environment personnel are prohibited from accessing any system components in the decryption environment or any CDE. Access-control mechanisms must include both physical and logical controls.
MM-C-1.1.a Examine documented policies and procedures, and interview responsible personnel to verify that encryption environment personnel are prohibited from accessing any system components in the decryption environment or the CDE.
MM-C-1.1.b For a sample of system components in the CDE and the decryption environment, review system configurations and access-control lists to verify that encryption environment personnel do not have access to any system components in the decryption environment or the CDE.
MM-C-1.1.a Examine documented policies and procedures, and interview responsible personnel to verify that encryption environment personnel are prohibited from accessing any system components in the decryption environment or the CDE.
MM-C-1.1.b For a sample of system components in the CDE and the decryption environment, review system configurations and access-control lists to verify that encryption environment personnel do not have access to any system components in the decryption environment or the CDE.
Modified
p. 1
Payment Card Industry (PCI) Point-to-Point Encryption Solution Requirements and Testing Procedures Version 2.0 (Revision 1.2)
Payment Card Industry (PCI) Point-to-Point Encryption Security Requirements and Testing Procedures Version 3.0
Removed
p. 4
Types of Solution Providers P2PE Solution Provider:
Modified
p. 4 → 6
A P2PE solution provider is an entity with a third-party relationship with respect to its merchant customers (e.g., a processor, acquirer, or payment gateway) that has overall responsibility for the design and implementation of a specific P2PE solution, and manages P2PE solutions for its merchant customers. The solution provider has overall responsibility for ensuring that all P2PE requirements are met, including any P2PE requirements performed by third-party organizations on behalf of the solution provider (e.g., certification authorities and key-injection facilities).
Types of Solution Providers P2PE Solution Provider A P2PE solution provider is an entity with a third-party relationship with respect to its merchant customers (e.g., a processor, acquirer, or payment gateway) that has overall responsibility for the design and implementation of a specific P2PE solution and manages P2PE solutions for its merchant customers. The solution provider has overall responsibility for ensuring that all P2PE requirements are met, including any P2PE requirements performed by third-party organizations on behalf of the solution …
Modified
p. 4 → 6
Merchant as a Solution Provider/Merchant-managed Solution The terms “merchant as a solution provider” and “merchant-managed solution” apply to merchants who choose to manage their own P2PE solutions on behalf of their own merchant encryption environments rather than outsourcing the solution to a third-party P2PE solution provider. Domain 4 defines the separation needed between encryption environments where the encrypting POI devices are physically located and the merchant’s account data decryption environment (and other merchant cardholder data environments) for a merchant-managed solution. …
Merchant as a Solution Provider/Merchant-managed Solution The terms “merchant as a solution provider” and “merchant-managed solution” apply to merchants who choose to manage their own P2PE solutions on behalf of their own merchant encryption environments rather than outsourcing the solution to a third-party P2PE solution provider. Appendix A defines the separation needed between encryption environments where the encrypting POI devices are physically located and the merchant’s account-data decryption environment (and other merchant cardholder data environments) for a merchant-managed solution. Appendix …
Modified
p. 4 → 6
For merchant-managed solutions, where the term “merchant” is used in Domains 1, 3, 5, and 6 of this document, those requirements refer to the merchant’s encryption environments and represent requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
For merchant-managed solutions, where the term “merchant” is used in Domains 1, 3, 4, and 5 of this document, those requirements refer to the merchant’s encryption environments and represent requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
Removed
p. 6
5A Use approved decryption devices.
5B Secure the decryption environment.
5C Monitor the decryption environment and respond to incidents.
5D Implement secure, hybrid decryption processes.
5E Component providers ONLY: report status to solution providers.
6A Account data is processed using algorithms and methodologies that ensure they are kept secure.
6B Account data keys and key-management methodologies are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
6C Keys are conveyed or transmitted in a secure manner.
6D Key loading is handled in a secure manner.
6E Keys are used in a manner that prevents or detects their unauthorized usage.
6F Keys are administered in a secure manner.
6G Equipment used to process account data and keys is managed in a secure manner.
6H For hybrid decryption solutions: Implement secure hybrid-key management.
6I Component providers ONLY: report status to solution providers.
5B Secure the decryption environment.
5C Monitor the decryption environment and respond to incidents.
5D Implement secure, hybrid decryption processes.
5E Component providers ONLY: report status to solution providers.
6A Account data is processed using algorithms and methodologies that ensure they are kept secure.
6B Account data keys and key-management methodologies are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
6C Keys are conveyed or transmitted in a secure manner.
6D Key loading is handled in a secure manner.
6E Keys are used in a manner that prevents or detects their unauthorized usage.
6F Keys are administered in a secure manner.
6G Equipment used to process account data and keys is managed in a secure manner.
6H For hybrid decryption solutions: Implement secure hybrid-key management.
6I Component providers ONLY: report status to solution providers.
Modified
p. 6 → 9
MM-A Restrict access between the merchant decryption environment and all other networks/systems.
Modified
p. 6 → 9
MM-B Restrict traffic between the encryption environment and any other CDE.
Modified
p. 6 → 9
MM-C Restrict personnel access between the encryption environment and the merchant decryption environment.
Modified
p. 7 → 10
Note that for P2PE solutions using hybrid decryption, SCDs are used for encryption of account data as well as for storage and management of cryptographic keys, but are not required for decryption of account data.
Note that for P2PE solutions using hybrid decryption, SCDs are used for encryption of account data as well as for storage and management of cryptographic keys; however they are not required for decryption of account data.
Modified
p. 7 → 10
P2PE Solutions: Hardware Decryption or Hybrid Decryption For PCI P2PE solutions, the encryption environment at the point of merchant acceptance consists exclusively of hardware encryption done within PCI-approved POI devices.
P2PE Solutions: Hardware Decryption or Hybrid Decryption For PCI P2PE solutions, the encryption environment at the point of merchant acceptance consists exclusively of hardware encryption performed within PCI-approved POI devices.
Modified
p. 7 → 10
PCI P2PE decryption environments require HSMs for all management of cryptographic keys, and that HSMs be used for decryption of account data (hardware decryption), or optionally account data decryption can occur outside of an HSM in non-SCD “Host Systems” (hybrid decryption) meeting additional hybrid decryption requirements specified in Domains 5 and 6, in sections 5D and 6H respectively.
PCI P2PE decryption environments require HSMs for all management of cryptographic keys, and that HSMs be used for decryption of account data (hardware decryption); or optionally account-data decryption can occur outside an HSM in non-SCD “Host Systems” (hybrid decryption) meeting additional hybrid decryption requirements specified in Domains 4 and 5, in Sections 4D and 5H, respectively.
Modified
p. 8 → 11
SCD Type and Usage Domain PCI-Approved POI Device for Account-Data Encryption FIPS 140-2 Level 3 or PCI Approved HSM for Account-Data Decryption SCD for Cryptographic Key Injection or Key Operations Encryption Device and Application Management Applicable N/A N/A Application Security N/A N/A N/A P2PE Solution Management N/A N/A N/A Merchant-managed Solutions N/A N/A N/A Decryption Environment 1 N/A Applicable N/A P2PE Cryptographic Key Operations and Device Management1 (Includes Annexes) Applicable Applicable Applicable 1 For hybrid decryption environments, note that while …
SCD Type and Usage Domain PCI-Approved POI Device for Account-Data Encryption FIPS 140-2 or 140-3 Level 3 or 4 or PCI Approved HSM for Account-Data Decryption SCD for Cryptographic Key Injection, Key Operations, or Software/Whitelist Signing Encryption Device and Application Management Applicable N/A N/A Application Security N/A N/A N/A P2PE Solution Management N/A N/A N/A Decryption Environment1 N/A Applicable N/A P2PE Cryptographic Key Operations and Device Management1 Applicable Applicable Applicable 1 For hybrid decryption environments, note that while account-data decryption …
Removed
p. 9
P2PE component providers may optionally be assessed for the following services:
Encryption-management services (Domains 1 & 6 including Annex A as applicable) Decryption-management services (Domains 5 & 6 including Annex A as applicable), Key-Injection facility services (Annex B of Domain 6 including Annex A as applicable) Certification Authority/Registration Authority services (Domain 6 and Annex A Part A2, including Annex A1 as applicable) Note that P2PE component providers are allowed to outsource elements of their respective P2PE domain(s); however, they are still ultimately responsible for ensuring all P2PE requirements for the applicable domain(s) are met. Only entities meeting all P2PE requirements for the domain(s) related to services they are offering are eligible for being listed on the PCI SSC’s list of Validated P2PE Components, whether these requirements are met directly or via outsourcing. Companies only meeting a partial set of domain requirements are not eligible for PCI SSC’s listing.
Encryption-management services (Domains 1 & 6 including Annex A as applicable) Decryption-management services (Domains 5 & 6 including Annex A as applicable), Key-Injection facility services (Annex B of Domain 6 including Annex A as applicable) Certification Authority/Registration Authority services (Domain 6 and Annex A Part A2, including Annex A1 as applicable) Note that P2PE component providers are allowed to outsource elements of their respective P2PE domain(s); however, they are still ultimately responsible for ensuring all P2PE requirements for the applicable domain(s) are met. Only entities meeting all P2PE requirements for the domain(s) related to services they are offering are eligible for being listed on the PCI SSC’s list of Validated P2PE Components, whether these requirements are met directly or via outsourcing. Companies only meeting a partial set of domain requirements are not eligible for PCI SSC’s listing.
Modified
p. 9 → 12
A “P2PE component provider” is an entity that provides a service assessed to a specific set of P2PE requirements and which results in a P2PE component provider listing on the PCI SSC website. P2PE component providers’ services are performed on behalf of other P2PE solution providers for use in P2PE solutions.
A “P2PE component provider” is an entity that provides a service assessed to a specific set of P2PE requirements and results in a P2PE component provider listing on the PCI SSC website. P2PE component providers’ services are performed on behalf of other P2PE solution providers for use in P2PE solutions.
Modified
p. 9 → 12
1. Undergo a P2PE assessment of relevant P2PE requirements on their own and submit the applicable P2PE Report of Validation (P-ROV) to PCI SSC for review and acceptance. Upon acceptance, the P2PE component is listed on PCI SSC’s list of Validated P2PE Components. Or:
1. Undergo a P2PE assessment of relevant P2PE requirements on their own and submit the applicable P2PE Report on Validation (P-ROV) to
Modified
p. 9 → 12
2. Have their services reviewed during the course of each of their solution-provider customers’ P2PE assessments.
2. Have their services reviewed during the course of each of their solution-provider or component-provider customers’ P2PE assessments.
Modified
p. 9 → 12
1. The solution provider can perform all domains (excluding Domain 4) in their entirety. o A merchant as a solution provider can perform all domains (including Domain 4) in their entirety.
1. The solution provider can perform all domains in their entirety.
Modified
p. 9 → 12
3. A solution provider (or a merchant as a solution provider) can outsource certain P2PE functions (see upper sidebar) to PCI-listed P2PE component providers and report use of the PCI-listed P2PE component(s) in their P2PE Report on Validation (P-ROV).
3. A solution provider (or a merchant as a solution provider) can outsource certain P2PE functions to PCI-listed P2PE component providers and report use of the PCI-listed P2PE component(s) in their P2PE Report on Validation (P-ROV).
Removed
p. 10
P2PE Assessments: Solution Providers, Component Providers, and other Third Parties Refer to the P2PE Program Guide for specific requirements relative to assessing and listing of P2PE component providers.
There are two approaches for an application vendor to have a P2PE application assessed for use in a P2PE solution (note that in both cases, a PA-QSA (P2PE) performs the assessment per Domain 2 requirements):
1. Undergo an independent assessment to all Domain 2 requirements:
• Submit the application P2PE Report on Validation (P-ROV) to PCI SSC for review and acceptance, and
• Upon acceptance, the P2PE application is listed on PCI SSC’s list of Validated P2PE Applications.
2. Undergo an assessment to all Domain 2 requirements as part of the full assessment of the P2PE solution(s) in which the application will be used:
• Submit the application P-ROV to PCI SSC along with the solution P-ROV.
Note that application vendors using option 2 may optionally have their applications …
There are two approaches for an application vendor to have a P2PE application assessed for use in a P2PE solution (note that in both cases, a PA-QSA (P2PE) performs the assessment per Domain 2 requirements):
1. Undergo an independent assessment to all Domain 2 requirements:
• Submit the application P2PE Report on Validation (P-ROV) to PCI SSC for review and acceptance, and
• Upon acceptance, the P2PE application is listed on PCI SSC’s list of Validated P2PE Applications.
2. Undergo an assessment to all Domain 2 requirements as part of the full assessment of the P2PE solution(s) in which the application will be used:
• Submit the application P-ROV to PCI SSC along with the solution P-ROV.
Note that application vendors using option 2 may optionally have their applications …
Modified
p. 11 → 13
Note: P2PE applications and P2PE non-payment software do not meet the PTS definition of “firmware” and are not reviewed as part of the PTS POI assessment. Additionally, software meeting the PTS definition of “firmware” is not reassessed during a P2PE assessment (PTS firmware is not considered a P2PE payment application, nor is it P2PE non-payment software).
Note: P2PE applications and P2PE non-payment software do not meet the PTS definition of “firmware” and are not reviewed as part of the PTS POI assessment. Therefore, both P2PE Applications and P2PE non-payment software must be assessed as part of this Standard. Additionally, software meeting the PTS definition of “firmware” is not reassessed during a P2PE assessment (PTS firmware is not considered a P2PE payment application, nor is it P2PE non-payment software).
Removed
p. 12
P2PE Domain Entity Undergoing P2PE Validation Encryption Device and Application Management
Removed
p. 12
• Encryption-management services component provider Application Security
• P2PE application vendor P2PE Solution Management
• Merchant as a solution provider Merchant-managed Solutions 2
• Merchant as a solution provider Decryption Environment
• Decryption-management services component provider P2PE Cryptographic Key Operations and Device Management (Includes Annexes)
• Solution provider OR merchant as a solution provider AND/OR
• Encryption-management or decryption-management services component provider AND/OR
• KIF or CA/RA services component provider3 2 Note that for merchant-managed solutions, the “merchant as a solution provider” is responsible for all solution provider roles above (in addition to Domain 4).
• P2PE application vendor P2PE Solution Management
• Merchant as a solution provider Merchant-managed Solutions 2
• Merchant as a solution provider Decryption Environment
• Decryption-management services component provider P2PE Cryptographic Key Operations and Device Management (Includes Annexes)
• Solution provider OR merchant as a solution provider AND/OR
• Encryption-management or decryption-management services component provider AND/OR
• KIF or CA/RA services component provider3 2 Note that for merchant-managed solutions, the “merchant as a solution provider” is responsible for all solution provider roles above (in addition to Domain 4).
Removed
p. 13
The following example P2PE domain responsibility scenarios are included in Appendix A to illustrate various possible roles of P2PE solution providers, P2PE component providers, P2PE application vendors, and the applicability of the P2PE domains (and subsequently the relevant requirements) for these entities that may contribute to a given P2PE solution. These scenarios are for illustration purposes only and are not meant to show every possible scenario
1. Solution provider uses a third-party POI application and manages all other solution functions.
2. Solution provider uses a third-party POI application and outsources all other solution functions.
3. Solution provider writes its own POI application(s), outsources decryption management, and manages all other solution functions.
4. Solution provider uses a third-party POI application(s), outsources device and decryption management, and manages all other solution functions.
5. Solution provider uses a third-party POI application(s), outsources to a KIF, and manages all other solution functions.
6. Solution provider outsources KIF and CA/RA functions, …
1. Solution provider uses a third-party POI application and manages all other solution functions.
2. Solution provider uses a third-party POI application and outsources all other solution functions.
3. Solution provider writes its own POI application(s), outsources decryption management, and manages all other solution functions.
4. Solution provider uses a third-party POI application(s), outsources device and decryption management, and manages all other solution functions.
5. Solution provider uses a third-party POI application(s), outsources to a KIF, and manages all other solution functions.
6. Solution provider outsources KIF and CA/RA functions, …
Modified
p. 14
Here is a high-level summary of the six P2PE domains:
Here is a high-level summary of the five P2PE domains:
Modified
p. 14
Domain 1
• Security requirements for the encryption environmentincluding those for:
• Security requirements for the encryption environment
Domain 1
• Security requirements for the encryption environment
• Security requirements for the encryption environment
Modified
p. 14
All PCI-approved POI devices included in the P2PE solution (for the merchant to use for payment acceptance).
• All PCI-approved POI devices included in the P2PE solution (for the merchant to use for payment acceptance)
Modified
p. 14
• P2PE non-payment software (those with no access to clear-text account data
•e.g., a loyalty or advertising application) Domain 2
• Security requirements for P2PE applicationsFor software with access to clear-text account data intended for use on POI devices.
•e.g.,
• Security requirements for P2PE applications
• Integration of all software onto POI devices − P2PE payment applications (subject to a Domain 2 assessment) − P2PE non-payment software (those with no access to clear-text account data•e.g., a loyalty or advertising application) Domain 2
• Security requirements for P2PE applications
• Security requirements for P2PE applications
Modified
p. 14
The solution provider’s overall management of the P2PE solution including any third-party relationships, communications between various P2PE entities, and/or use of P2PE component providers.
• The solution provider’s overall management of the P2PE solution including any third-party relationships, communications between various P2PE entities, and/or use of P2PE component providers
Modified
p. 14
The merchant-focused P2PE Instruction Manual (PIM) that the solution provider prepares for and distributes to merchants (for their encryption environments), including completion of the PCI-provided PIM Template.
• The merchant-focused P2PE Instruction Manual (PIM) that the solution provider prepares for and distributes to merchants (for their encryption environments), including completion of the PCI-provided PIM Template Domain 4
• Security requirements for the decryption environment
• Security requirements for the decryption environment
Modified
p. 14
Management of all system components located within or connected to the decryption environment, including those used for decryption of account data, and Maintenance of PCI DSS compliance for the decryption environment.
• Management of all system components located within or connected to the decryption environment, including those used for decryption of account data, and
Modified
p. 14
•
•including all HSMs, key-loading devices, etc.
• Secure key management
•including all HSMs, key-loading devices, etc.
•including all HSMs, key-loading devices, etc.
Modified
p. 14
•used by the solution provider or third party for cryptographic-key operations performed in support of account-data encryption POI devices (Domain 1) and decryption HSMs (Domains 5).
•used by the solution provider or third party for cryptographic-key operations performed in support of account-data encryption POI devices and decryption HSMs
Removed
p. 15
Applications on POI devices with access to clear-text data meet requirements derived from the Payment Application Data Security Standard (PA-DSS).
The decryption environment is PCI DSS compliant.
The decryption environment is PCI DSS compliant.
Modified
p. 15
POI devices (for account data encryption) are approved per PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements.
• POI devices (for account-data encryption) are approved per PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements
Modified
p. 15
HSMs in the decryption environment used for account-data decryption and related cryptographic-key operations are approved per PCI PTS HSM (or FIPS 140-2 level 3).
• HSMs in the decryption environment used for account-data decryption and related cryptographic-key operations are approved per PCI PTS HSM or FIPS 140-2 or 140-3 Level 3 (or 4)
Modified
p. 15
Cryptographic-key operations for both encryption and decryption environments using key-management practices derived from the PTS PIN Security Standard.
• Cryptographic-key operations for both encryption and decryption environments using key-management practices from the PTS PIN Security Standard
Modified
p. 15
Please note that this standard for point-to-point encryption solutions does not supersede the PCI Data Security Standard, PCI PIN Security Requirements, or any other PCI Standards, nor do these requirements constitute a recommendation from the Council or obligate merchants, service providers, or financial institutions to purchase or deploy such solutions. As with all other PCI standards, any mandates, regulations, or rules regarding these requirements are provided by the participating payment brands.
• The decryption environment is PCI DSS compliant Please note that this standard for point-to-point encryption solutions does not supersede the PCI Data Security Standard, PCI PIN Security Requirements, or any other PCI Standards, nor do these requirements constitute a recommendation from the Council or obligate merchants, service providers, or financial institutions to purchase or deploy such solutions. As with all other PCI standards, any mandates, regulations, or rules regarding these requirements are provided by the participating payment brands.
Modified
p. 15
Selected samples must be representative of all variations or types of a particular system component. Samples must be of sufficient size to provide the assessor with assurance that controls are implemented as expected across the entire population.
Selected samples must be representative of all variations or types of a particular system component. Samples must be of sufficient size to provide the assessor with assurance that controls are implemented as expected across the entire population. Samples should be varied, where possible, with each assessment.
Modified
p. 15
POI devices and applications/software must include every unique combination of hardware, firmware, and versions and configurations of both P2PE applications and P2PE non-payment software used by the solution.
• POI devices and applications/software must include every unique combination of hardware, firmware, and versions and configurations of both P2PE applications and P2PE non-payment software used by the solution.
Modified
p. 15
Samples of keys / key components must include all key types and/or functions.
• Samples of keys / key components must include all key types and/or functions.
Modified
p. 15
Note: All HSMs (or Host Systems used in hybrid decryption) used for account-data decryption in the decryption environment must be reviewed to verify their secure configuration and therefore cannot be sampled.
Removed
p. 16
The P2PE Designated Change process for all new PCI-approved POI devices or P2PE applications added to an existing P2PE solution after validation.
Modified
p. 16
Document the rationale behind the sampling technique and sample size, Document any standardized processes and controls used to determine sample size, Document how it was verified that the standardized processes/controls ensure consistency and apply to all items in the population, and Explain how the sample is appropriate and representative of the overall population.
• Document the rationale behind the sampling technique and sample size, • Document any standardized processes and controls used to determine sample size, • Document how it was verified that the standardized processes/controls ensure consistency and apply to all items in the population, and • Explain how the sample is appropriate and representative of the overall population.
Modified
p. 16
P2PE Report on Validation submission and acceptance processes.
• P2PE Report on Validation submission and acceptance processes
Modified
p. 16
Annual renewal process for solutions included on the list of Validated P2PE Solutions.
• Annual renewal process for solutions included on the list of Validated P2PE Solutions
Modified
p. 16
Vendor Release Agreements for vendors and providers of P2PE solutions, applications, and solution components.
• Vendor Release Agreements for vendors and providers of P2PE solutions, applications, and solution components
Modified
p. 16
Notification responsibilities in the event a listed P2PE solution is determined to be at fault in a compromise.
• Notification responsibilities in the event a listed P2PE solution is determined to be at fault in a compromise
Modified
p. 16
PCI SSC reserves the right to require revalidation due to significant changes to the P2PE Solution Requirements and/or due to specifically identified vulnerabilities in a listed P2PE solution.
PCI SSC reserves the right to require revalidation due to significant changes to the P2PE Security Requirements and/or due to specifically identified vulnerabilities in a listed P2PE Solution, P2PE Application, or P2PE Component.
Removed
p. 17
Diagram Title Description Diagram 1 P2PE Solution and/or Component Validation Workflow at a Glance This chart shows the process for developing and validating a P2PE solution is provided below. The diagram illustrates the parties responsible for implementing requirements for each domain, and how validation of each domain and/or P2PE components can ultimately lead to a P2PE solution validation.
Diagram 2 Example P2PE Implementation at a Glance This diagram illustrates a generic P2PE implementation and which domains apply to each of the areas involved.
The remainder of this document details the P2PE validation requirements and testing procedures on a domain-by-domain basis.
Diagram 2 Example P2PE Implementation at a Glance This diagram illustrates a generic P2PE implementation and which domains apply to each of the areas involved.
The remainder of this document details the P2PE validation requirements and testing procedures on a domain-by-domain basis.
Modified
p. 17
Note: This diagram is for illustrative purposes and shows only one type of scenario that may occur.
Removed
p. 20
It is not the intent of Domain 1 that solution providers actively manage POI devices when deployed at merchant locations; the intent is that the solution provider maintains knowledge of the location and status of POI devices once deployed to merchants. It may be necessary for knowledge sharing and cross-cooperation regarding the location and status of devices when different entities are responsible for managing POI devices and cryptographic keys for different functions.
Note: All encryption devices, including POIs devices and related key-management SCDs, must additionally meet all requirements specified in Domain 6.
Note: All encryption devices, including POIs devices and related key-management SCDs, must additionally meet all requirements specified in Domain 6.
Modified
p. 20 → 21
Domain 1 requirements encompass the use of secure point-of-interaction (POI) devices and P2PE applications and/or P2PE non-payment software. The POI device must be a PCI-approved POI device, and is typically a PIN- entry device (PED), a secure card reader (SCR), or other non-PED device that is PCI-approved. Domain 1 requirements also include the confirmation that all P2PE applications and P2PE non-payment software are properly reviewed, installed, and configured on the device.
Domain 1 requirements encompass the use of secure point-of- interaction (POI) devices and P2PE applications and/or P2PE non-payment software. The POI device must be a PCI-approved POI device with SRED. Domain 1 requirements also include the confirmation that all P2PE applications and P2PE non-payment software are properly reviewed, installed, and configured on the device.
Modified
p. 20 → 21
Note: Domain 1 includes the only requirements applicable to P2PE non-payment software (software on PCI-approved POI devices without access to account data). For software that never has access to account data, only Requirements at 1C-2 are applicable•this will validate that this software is not accessing account data, and is not bypassing or overriding any security features provided by the other approved components of the device.
Note: Domain 1 includes the only requirements applicable to P2PE non- payment software (software on PCI-approved POI devices without access to account data). For software that never has access to account data, only Requirements at 1C-2 are applicable•this will validate that this software is not accessing account data, and is not bypassing or overriding any security features provided by the other approved components of the device. However, requirements in Domain 5 apply to the SCD used for signing non-payment software …
Modified
p. 20 → 21
For more information, refer to the section entitled “P2PE Solutions and Use of P2PE Applications and/or P2PE Non-payment Software.” Within this domain, the term “solution provider” refers to whichever entity is undergoing the P2PE assessment. This may be a solution provider, an encryption-management component provider, or the merchant as a solution provider.
For more information, refer to the section entitled “P2PE Solutions and Use of P2PE Applications and/or P2PE Non-payment Software.” Within this domain, the term “solution provider” refers to whichever entity is undergoing the P2PE assessment. This may be a solution provider, a component provider, or a merchant as a solution provider.
Modified
p. 21 → 22
Requirement 1A: Account data must be encrypted in equipment that is resistant to physical and logical compromise.
Requirement 1A: Account data must be encrypted in equipment that is resistant to physical and logical compromise Domain 1 Requirements Testing Procedures 1A-1 PCI-approved POI devices with SRED are used for transaction acceptance.
Modified
p. 21 → 22
1A-1.1 Encryption operations must be performed using a POI device approved per the PCI PTS program (e.g., a PCI- approved PED or SCR), with SRED (secure reading and exchange of data). The PTS approval listing must match the deployed devices in the following characteristics:
1A-1.1 Account-data encryption operations must be performed using a POI device approved per the PCI PTS program with SRED (secure reading and exchange of data). The PTS approval listing must match the deployed devices in the following characteristics:
Modified
p. 21 → 22
• Firmware version number
• Firmware version number(s)
Modified
p. 21 → 22
• Firmware version number
• Firmware version number(s)
Modified
p. 21 → 22
1A-1.1 For each POI device type used in the solution, examine the POI device and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
Modified
p. 21 → 22
1A-1.1.1.a Examine the solution provider’s documented procedures and interview personnel to verify that procedures are defined to ensure that SRED capabilities are enabled and active on all POI devices prior to devices being deployed to merchant encryption environments.
1A-1.1.1.a Examine documented procedures and interview personnel to verify that procedures are defined to ensure that SRED capabilities are enabled and active on all POI devices prior to devices being deployed to merchant encryption environments.
Modified
p. 21 → 22
1A-1.2 POI devices must be configured to use only SRED- validated account-data capture mechanisms.
1A-1.2 POI devices must be configured to use only SRED-validated account-data capture mechanisms.
Modified
p. 21 → 22
1A-1.2.a For all POI device types intended for use in the P2PE solution, identify and document all account-data capture interfaces.
1A-1.2.a For all POI device types used in the P2PE solution, identify and document all account-data capture interfaces.
Removed
p. 22
Domain 1 Requirements Testing Procedures 1A-1.2.1 All capture mechanisms on the POI device must be SRED-validated, or must be disabled or otherwise prevented from being used for P2PE transactions such that they cannot be enabled by the merchant.
1A-1.2.1.b Verify that the documented procedures include ensuring that all non-SRED- validated capture mechanisms are disabled or otherwise prevented from being used for P2PE transactions prior to devices being deployed to merchant encryption environments.
1A-1.4.b Using forensic tools and/or other data tracing methods, inspect a sample of transactions to verify that clear-text account data is not disclosed to any component or device outside of the PCI-approved POI device.
1A-1.2.1.b Verify that the documented procedures include ensuring that all non-SRED- validated capture mechanisms are disabled or otherwise prevented from being used for P2PE transactions prior to devices being deployed to merchant encryption environments.
1A-1.4.b Using forensic tools and/or other data tracing methods, inspect a sample of transactions to verify that clear-text account data is not disclosed to any component or device outside of the PCI-approved POI device.
Modified
p. 22 → 23
Requirement 1A: Account data must be encrypted in equipment that is resistant to physical and logical compromise.
Requirement 1A: Account data must be encrypted in equipment that is resistant to physical and logical compromise Domain 1 Requirements Testing Procedures 1A-1.2.1 All account-data capture mechanisms on the POI device must be SRED-validated, or must be disabled or otherwise prevented from being used for P2PE transactions such that they cannot be enabled by the merchant.
Modified
p. 22 → 23
1A-1.2.1.a Examine POI configuration and deployment procedures to verify they include either:
1A-1.2.1.a Examine POI device configuration and deployment procedures to verify they include either:
Modified
p. 22 → 23
• Implementing configurations that prevent all non-SRED validated capture mechanisms from being used for P2PE transactions.
• Implementing configurations that prevent all non-SRED validated capture mechanisms from being used for P2PE transactions 1A-1.2.1.b Verify that the documented procedures include ensuring that all non- SRED-validated capture mechanisms are disabled or otherwise prevented from being used for P2PE transactions prior to devices being deployed to merchant encryption environments.
Modified
p. 22 → 23
• All non-validated capture mechanisms are either disabled or configured to prevent their use for P2PE transactions, prior to devices being deployed to merchant encryption environments.
• All non-validated capture mechanisms are either disabled or configured to prevent their use for P2PE transactions prior to devices being deployed to merchant encryption environments.
Modified
p. 22 → 23
• IP Services 1A-1.3 For all POI device types that implement open protocols, examine device configurations and review the list of approved PTS devices at www.pcisecuritystandards.org, to verify that all POI devices that implement open protocols used in this solution are listed. Confirm each such device has a valid SSC listing number on the PCI SSC website under “Approved PCI PTS Devices” with “OP” listed as a “function provided”.
• IP Services 1A-1.3 For all POI device types that implement open protocols, examine device configurations and review the list of approved PTS devices at www.pcisecuritystandards.org, to verify that all POI devices that implement open protocols used in this solution are listed. Confirm each such device has a valid SSC listing number on the PCI SSC website under “Approved PCI PTS Devices” with “OP” listed as a “function provided.” 1A-1.4 Clear-text account data must not be disclosed to any component …
Modified
p. 22 → 23
1A-1.4.a Examine documented transaction processes and data flows to verify that clear-text account data is not disclosed to any component or device outside of the PCI-approved POI device.
Modified
p. 22 → 23
1A-1.4.b Using forensic tools and/or other data tracing methods, inspect a sample of test transactions to verify that clear-text account data is not disclosed to any component or device outside of the PCI-approved POI device.
Modified
p. 23 → 24
Requirement 1A: Account data must be encrypted in equipment that is resistant to physical and logical compromise.
Requirement 1A: Account data must be encrypted in equipment that is resistant to physical and logical compromise Domain 1 Requirements Testing Procedures 1A-2 Applications on POI devices with access to clear-text account data are assessed per Domain 2 before being deployed into a P2PE solution.
Modified
p. 23 → 24
1A-2.1 All applications on POI devices with access to clear- text account data must be assessed according to Domain 2.
1A-2.1 All applications on POI devices with access to clear-text account data must be assessed according to Domain 2.
Modified
p. 23 → 24
• Version number 1A-2.2 All applications on POI devices with access to clear- text account data must only be deployed on POI device types that are:
• Version number 1A-2.2 All applications on POI devices with access to clear-text account data must only be deployed on POI device types that are:
Modified
p. 23 → 24
• Explicitly included in the Domain 2 assessment for that application.
• Explicitly included in the Domain 2 assessment for that application 1A-2.2.a.For applications on the PCI SSC list of Validated P2PE Applications, review the list and verify all POI device types the application is used on are:
Modified
p. 23 → 24
• Explicitly included in that P-ROV as assessed for that application.
• Explicitly included in that P-ROV as assessed for that application
Removed
p. 24
• Cannot enable disabled device interfaces or disabled data-capture mechanisms 1B-1.1.a Examine documented POI device configuration procedures and account privilege assignments to verify that merchant logical access to POI devices is restricted as follows:
• Only view transaction-related data
• Only view transaction-related data
Modified
p. 24 → 25
Domain 1 Requirements Testing Procedures 1B-1 Solution provider ensures that logical access to POI devices deployed at merchant encryption environment(s) is restricted to authorized personnel.
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-1 Solution provider ensures that logical access to POI devices deployed at merchant encryption environment(s) is restricted to authorized personnel.
Modified
p. 24 → 25
• Only view transaction-related data
• Only views transaction-related data.
Modified
p. 24 → 25
• Only view transaction-related data
• Only views transaction-related data.
Modified
p. 24 → 25
• Cannot view or access cryptographic keys
• Cannot view or access cryptographic keys.
Modified
p. 24 → 25
• Cannot view or access cryptographic keys
• Cannot view or access cryptographic keys.
Modified
p. 24 → 25
• Cannot view or access clear-text PAN
• Cannot view or access clear-text PAN.
Modified
p. 24 → 25
• Cannot view or access clear-text PAN
• Cannot view or access clear-text PAN.
Modified
p. 24 → 25
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD.
Modified
p. 24 → 25
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear- text PAN and/or SAD.
Modified
p. 24 → 25
• Cannot enable disabled device interfaces or disabled data-capture mechanisms 1B-1.1.b For a sample of all POI devices used in the solution, logon to the device using an authorized test merchant account. Verify that merchant-account logical access meets the following:
• Cannot enable disabled device interfaces or disabled data-capture mechanisms.
Modified
p. 24 → 25
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear- text PAN and/or SAD
Modified
p. 24 → 25
• Cannot enable disabled device interfaces or disabled data-capture mechanisms 1B-1.1.c Observe a sample of POI device configurations and interview responsible personnel to verify that the defined merchant-access requirements are configured for all devices used in the solution.
• Cannot enable disabled device interfaces or disabled data-capture mechanisms.
Modified
p. 25 → 26
Domain 1 Requirements Testing Procedures 1B-1.1.1 Where there is a legal or regulatory obligation in a region for merchants to print full PAN on merchant receipts, it is allowable for the merchant to have access to full PAN for this purpose but ONLY if the following are met:
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-1.1.1 Where there is a legal or regulatory obligation in a region for merchants to print full PAN on merchant receipts, it is allowable for the merchant to have access to full PAN for this purpose but ONLY if the following are met:
Modified
p. 25 → 26
Note: Domain 2 (at 2A-3.1.2) and Domain 3 (at 3A- 1.3) also include requirements that must be met for any P2PE application and P2PE solution provider, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.
Modified
p. 25 → 26
1B-1.1.1.a Review solution provider’s documentation about the legal/regulatory obligation that requires merchants to have access to full PANs for receipt printing purposes to verify that the documentation specifies which payment application(s) facilitates printing of PANs for merchants.
1B-1.1.1.a Review solution provider’s documentation about the legal/regulatory obligation that requires merchants to have access to full PANs for receipt printing purposes to verify that the documentation specifies the payment application(s) that facilitate printing of PANs for merchants.
Modified
p. 25 → 27
1B-1.2.1 Solution provider personnel with logical access to POI devices deployed in merchant encryption environments must be granted based on least privilege and need to know.
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-1.2.1 Solution provider personnel with logical access to POI devices deployed in merchant encryption environments must be granted based on least privilege and need to know.
Modified
p. 25 → 27
1B-1.2.1.a Examine documented access-control policies and procedures to verify that solution provider personnel with logical access to POI devices deployed at merchant encryption environments is assigned according to least privilege and need to know.
Removed
p. 26
Note: This includes remote access to POI devices via a terminal management system (TMS) or other similar systems.
1B-2.4.a Examine documented identification and authentication procedures to verify secure identification and authentication procedures are defined for remote access to POI devices deployed at merchant encryption environments.
1B-2.4.b Verify documented procedures include requirements specified at 1B-2.4.1 through 1B-2.4.3.
1B-2.4.a Examine documented identification and authentication procedures to verify secure identification and authentication procedures are defined for remote access to POI devices deployed at merchant encryption environments.
1B-2.4.b Verify documented procedures include requirements specified at 1B-2.4.1 through 1B-2.4.3.
Modified
p. 26 → 27
1B-2 Solution provider secures any remote access to POI devices deployed at merchant encryption environments.
Modified
p. 26 → 27
1B-2.1 Solution provider’s authorized personnel must use two-factor or cryptographic authentication for all remote access to merchant POI devices.
1B-2.1 Solution provider’s authorized personnel must use multi-factor or cryptographic authentication for all remote access to merchant POI devices.
Modified
p. 26 → 27
1B-2.1.a Examine documented procedures to verify that either two-factor or cryptographic authentication must be used for all remote access to POI devices.
1B-2.1.a Examine documented procedures to verify that either multi-factor or cryptographic authentication must be used for all remote access to POI devices.
Modified
p. 26 → 27
1B-2.1.b Observe remote-access mechanisms and controls to verify that either two-factor or cryptographic authentication is configured for all remote access to POI devices.
1B-2.1.b Observe remote-access mechanisms and controls to verify that either multi- factor or cryptographic authentication is configured for all remote access to POI devices.
Modified
p. 26 → 27
1B-2.1.c Interview personnel and observe actual remote connection attempts to verify that either two-factor or cryptographic authentication is used for all remote access to POI devices.
1B-2.1.c Interview personnel and observe actual remote connection attempts to verify that either multi-factor or cryptographic authentication is used for all remote access to POI devices.
Modified
p. 26 → 27
1B-2.2 POI devices must be configured to ensure that remote access is only permitted from the solution provider’s authorized systems.
1B-2.2 POI devices must be configured to ensure that remote access is only permitted from the solution provider’s authorized systems (which might include a terminal management system (TMS) or similar system).
Modified
p. 26 → 27
1B-2.3.b For all devices used in the solution, observe a sample of device configurations to verify that merchants do not have remote access to the POI devices.
1B-2.3.b For all device types used in the solution, observe a sample of device configurations to verify that merchants do not have remote access to the POI devices.
Modified
p. 26 → 28
1B-2.4 Solution provider must implement secure identification and authentication procedures for remote access to POI devices deployed at merchant encryption environments, including:
1B-2.4 Examine documentation to verify secure identification and authentication procedures are defined for remote access to POI devices deployed at merchant encryption environments.
Removed
p. 27
1B-2.4.3.a Observe authorized logical accesses and examine access records/logs to verify that an audit log of all logical access to devices is maintained.
Modified
p. 27 → 28
1B-2.5 Solution Provider must maintain individual authentication credentials for all authorized solution- provider personnel that are unique for each merchant, including:
Modified
p. 27 → 28
1B-2.5 Examine documentation to verify that all authorized solution-provider personnel are required to have individual authentication credentials that are unique for each merchant (or if applicable, per centralized TMS).
Modified
p. 27 → 28
1B-2.5.1 Tracing all logical access to POI devices by solution-provider personnel to an individual user.
Modified
p. 27 → 28
1B-2.5.1.a Examine POI device configurations and authentication mechanisms to verify that all logical access to POI devices by solution-provider personnel can be traced to an individual user.
Modified
p. 27 → 28
1B-2.5.1.b Observe a sample of authorized logical accesses and examine access records/logs to verify that all logical access is traced to an individual user.
Modified
p. 27 → 28
1B-2.5.2 Maintaining audit logs of all logical access to POI devices by solution-provider personnel and retaining access logs for at least one year.
Modified
p. 27 → 28
1B-2.5.2 Examine documentation to verify that access records/logs of all logical access to POI devices by solution-provider personnel are required to be retained for at least one year.
Modified
p. 27 → 29
1B-3 The solution provider implements procedures to protect POI devices and applications from known vulnerabilities and securely update devices.
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-3 The solution provider implements procedures to protect POI devices and applications from known vulnerabilities and securely update devices.
Modified
p. 27 → 29
• Authentication of origin of the update 1B-3.1.a Examine documented procedures to verify secure update processes are defined for all firmware and software updates, and include:
• Verification of the origin of the update 1B-3.1.a Examine documented procedures to verify secure update processes are defined for all firmware and software updates, and include:
Removed
p. 28
1B-3.2.c Observe results of vulnerability assessments and interview responsible personnel to verify vulnerability assessments are performed against all POI device system builds:
• At least annually and
• At least annually and
Modified
p. 28 → 29
• Verification of the origin of the update 1B-3.1.b Observe a sample of firmware and software updates, and interview personnel to verify:
Modified
p. 28 → 29
1B-3.2.a Examine documented procedures to verify they include:
• Non-payment Software 1B-3.2.a Examine documented procedures to verify they include:
Modified
p. 28 → 29
• Procedures for confirming all builds at least annually and upon any changes to the 1B-3.2.b Review documented inventory of devices, and examine the inventory of system builds to verify:
• Procedures for confirming all builds at least annually and upon any changes to the build 1B-3.2.b Review documented inventory of devices, and examine the inventory of system builds to verify:
Modified
p. 28 → 29
• The inventory of POI device system builds is up-to-date.
• The inventory of POI device system builds is up to date.
Modified
p. 28 → 30
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-3.3 Critical software security updates must be deployed to POI devices in the field within 30 days of receipt from device vendors or application vendors.
Modified
p. 28 → 30
1B-3.3.a Examine documented procedures to verify they include defined procedures for deploying critical software security updates to POI devices in the field within 30 days of receipt from device or application vendors.
Aligns with 2C-1.2 1B-3.3.a Examine documented procedures to verify they include defined procedures for deploying critical software security updates to POI devices in the field within 30 days of receipt from device or application vendors.
Removed
p. 29
1B-3.5 The integrity of patch and update code must be maintained during delivery and deployment, as defined by the vendor•e.g., in the POI device vendor's security guidance or in the P2PE application’s Implementation Guide.
1B-3.5.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor to maintain the integrity of all patch and update code during delivery and deployment.
1B-3.5.b Observe processes for delivering updates and interview responsible personnel to verify that the integrity of patch and update code is maintained during delivery and deployment, and according to guidance from the device or application vendor.
1B-3.5.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor to maintain the integrity of all patch and update code during delivery and deployment.
1B-3.5.b Observe processes for delivering updates and interview responsible personnel to verify that the integrity of patch and update code is maintained during delivery and deployment, and according to guidance from the device or application vendor.
Modified
p. 29 → 30
1B-3.3.b Examine security update deployment records and device logs, and interview responsible solution provider personnel and to verify that critical security updates are deployed to devices and applications in the field within 30 days of receipt from device and application vendors.
Modified
p. 29 → 30
1B-3.4 Updates must be delivered in a secure manner with a known chain-of-trust, as defined by the vendor•e.g., in the POI device vendor's security guidance or in the P2PE application’s Implementation Guide.
1B-3.4 The integrity of patch and update code must be maintained during delivery and deployment, as defined by the vendor•e.g., in the POI device vendor's security guidance or in the P2PE application’s Implementation Guide.
Modified
p. 29 → 30
1B-3.4.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor for delivering updates in a secure manner with a known chain-of-trust.
1B-3.4.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor to maintain the integrity of all patch and update code during delivery and deployment.
Modified
p. 29 → 30
1B-3.4.b Observe processes for delivering updates and interview responsible personnel to verify that updates are delivered in a secure manner with a known chain-of-trust, and following guidance from the device or application vendor.
1B-3.4.b Observe processes for delivering updates and interview responsible personnel to verify that the integrity of patch and update code is maintained during delivery and deployment, and according to guidance from the device or application vendor.
Modified
p. 29 → 30
1B-3.4.c Observe authorized personnel attempt to run the update process with arbitrary code to verify that the system will not allow the update to occur.
Modified
p. 29 → 31
1B-4 Solution provider implements procedures to secure account data when troubleshooting 1B-4.1 Any PAN and/or SAD used for debugging or troubleshooting purposes must be securely deleted. These data sources must be collected in limited amounts and collected only when necessary to resolve a problem, encrypted while stored, and deleted immediately after use.
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-4 Solution provider implements procedures to secure account data when troubleshooting 1B-4.1 Any PAN and/or SAD used for debugging or troubleshooting purposes must be securely deleted. These data sources must be collected in limited amounts and collected only when necessary to resolve a problem, encrypted while stored, and deleted immediately after use.
Modified
p. 30 → 31
1B-5 The P2PE solution provides auditable logs of any changes to critical functions of the POI device(s).
Modified
p. 30 → 31
1B-5.1 Any changes to critical functions of POI devices must be logged•either on the device or within the remote- management systems of the P2PE solution provider.
1B-5.1 Any changes to critical functions of POI devices must be logged•either on the device or within the remote-management systems of the P2PE solution provider.
Removed
p. 31
1C-1.1 Applications with access to account data must be installed and configured to only use external communication methods specified in the application’s Implementation Guide.
Aligns with 2A-3.3 1C-1.1.a Observe application and device configurations and interview personnel to verify that applications with access to account data are installed and configured to only use approved external communication methods, by following guidance in the application’s Implementation Guide.
1C-1.1.b For all devices on which the application will be used in the solution, observe application and device operations as implemented in the solution
•that is, the application and device should be tested together with all other applications intended to be installed on the device)
•and use an appropriate “test platform” (as necessary) provided by the application vendor to perform test transactions for all functions of the application that handle account data. Examine results of tests and verify that the application only uses approved external communication methods.
Aligns with 2A-3.3 1C-1.1.a Observe application and device configurations and interview personnel to verify that applications with access to account data are installed and configured to only use approved external communication methods, by following guidance in the application’s Implementation Guide.
1C-1.1.b For all devices on which the application will be used in the solution, observe application and device operations as implemented in the solution
•that is, the application and device should be tested together with all other applications intended to be installed on the device)
•and use an appropriate “test platform” (as necessary) provided by the application vendor to perform test transactions for all functions of the application that handle account data. Examine results of tests and verify that the application only uses approved external communication methods.
Modified
p. 31 → 32
Domain 1 Requirements Testing Procedures 1C-1 Applications are implemented securely, including when using shared resources and when updating applications and application functionality.
Requirement 1C: Use applications that protect PAN and SAD Domain 1 Requirements Testing Procedures 1C-1 Applications are implemented securely, including when using shared resources and when updating applications and application functionality.
Modified
p. 32
1C-1.1 Processes for any whitelisting functionality must include:
Modified
p. 32
• Implementing whitelisting functionality in accordance with the device vendor's security guidance or the application’s Implementation Guide.
• Implementing whitelisting functionality in accordance with the device vendor's security guidance or the application’s Implementation Guide
Modified
p. 32
• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
Modified
p. 32
• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
Modified
p. 32
• Cryptographic authentication by the POI device’s
• Cryptographic authentication by the POI device’s firmware
Modified
p. 32
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data
Modified
p. 32
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data
Modified
p. 32
− Description and justification for the functionality − The identity of the authorized person who approved the new installation or updated functionality prior to release − Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Aligns with 2A-3.4 1C-1.1 Review documented policies and procedures and interview personnel to verify that processes for implementing any whitelisting functionality include:
Modified
p. 32
• Following the device vendor's security guidance or the application’s Implementation
• Following the device vendor's security guidance or the application’s Implementation Guide
Modified
p. 32
• Cryptographic authentication of whitelisting functionality by the POI device’s
• Cryptographic authentication of whitelisting functionality by the POI device’s firmware
Modified
p. 32
− Description and justification for the functionality − The identity of the authorized person who approved the new installation or updated functionality prior to release − Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data
Modified
p. 32 → 33
1C-1.1.1.a Observe application and device configurations and interview personnel to verify that whitelisting functionality only allows for the output of non-PCI payment brand accounts/cards, by following guidance in either the device vendor's security guidance or the application’s Implementation Guide.
Modified
p. 32 → 33
1C-1.1.1.b For all device types with whitelisting functionality, perform test transactions to verify the output of clear-text account data is only enabled for non- PCI payment brand account/card data.
Removed
p. 33
1C-1.2.3 Any new installations of, or updates to, whitelisting functionality must follow change-control procedures that include:
1C-1.2.3 Review records of both new installations and updated whitelisting functionality, and confirm they include the following:
• Coverage for both new installations and updates to such functionality.
• Description and justification for the functionality.
• The identity of the person who approved the new installation or update prior to release.
• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
1C-1.2.3 Review records of both new installations and updated whitelisting functionality, and confirm they include the following:
• Coverage for both new installations and updates to such functionality.
• Description and justification for the functionality.
• The identity of the person who approved the new installation or update prior to release.
• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
Modified
p. 33
1C-1.1.2 Any new installations of, or updates, to whitelisting functionality must be:
Modified
p. 33
1C-1.1.2 Observe the process for new installations of, or updates to, whitelisting functionality and interview personnel to verify they are performed as follows:
Modified
p. 33
• Cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
• Cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control
Modified
p. 33
• Cryptographically authenticated by the POI device firmware, in accordance with the device vendor's security guidance or the application’s Implementation Guide.
• Cryptographically authenticated by the POI device firmware, in accordance with the device vendor's security guidance or the application’s Implementation Guide 1C-1.1.3 Any new installations of, or updates to, whitelisting functionality must follow change-control procedures that include:
Modified
p. 33
• Coverage for both new installations and updates to such functionality.
• Coverage for both new installations and updates to such functionality
Modified
p. 33
• The identity of the person who approved the new installation or update prior to release.
• The identity of the person who approved the new installation or update prior to release
Modified
p. 33
• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data
Removed
p. 34
Domain 1 Requirements Testing Procedures 1C-2 All applications/software without a business need do not have access to account data.
• Review of the application vendor’s documentation to determine all logical interfaces used by the application/software.
1C-2.1.1 The application/software does not have any logical interfaces
•e.g., application programming interfaces (APIs)
•that allow for storing, processing, or transmitting account data.
• Review of the application vendor’s documentation to determine all logical interfaces used by the application/software.
1C-2.1.1 The application/software does not have any logical interfaces
•e.g., application programming interfaces (APIs)
•that allow for storing, processing, or transmitting account data.
Modified
p. 34
Requirement 1C: Use applications that protect PAN and SAD.
Requirement 1C: Use applications that protect PAN and SAD Domain 1 Requirements Testing Procedures 1C-2 All applications/software without a business need do not have access to clear-text account data.
Modified
p. 34
Note: Requirements at 1C-2 are the only requirements applicable to applications or software on PCI-approved POI devices with no access to account data (e.g., a loyalty or advertising application).
Note: Requirements at 1C-2 are the only requirements applicable to applications/software (non-payment software) on PCI-approved POI devices with no access to clear-text account data (e.g., a loyalty or advertising application). However, requirements in Domain 5 apply to the SCD used for signing non-payment software as well as the associated cryptographic keys and key management.
Modified
p. 34
1C-2.1 Processes must be documented and implemented to ensure that, prior to new installations or updates, applications/software without a business need do not have access to account data, including that the software:
1C-2.1 Processes must be documented and implemented to ensure that, prior to new installations or updates, any non-payment software:
Modified
p. 34
• Does not have any logical interfaces (e.g., application programming interfaces (APIs)) that allow for the storing, processing, or transmitting of account data.
• Does not have any logical interfaces (e.g., application programming interfaces [APIs]) that allow for the storing, processing, or transmitting of clear-text account data.
Modified
p. 34
• Requires dual control for the application-signing process.
• Requires an SCD with dual control for the application-signing process.
Modified
p. 34
• Documenting how the solution provider confirmed that the application has no logical interfaces that allow for storing, processing, or transmitting account data
• Documenting how the solution provider confirmed that the non-payment software has no logical interfaces that allow for storing, processing, or transmitting clear-text account data
Modified
p. 34
• Authentication of the application by the POI device’s firmware
• Authentication of the non-payment software by the POI device’s firmware
Modified
p. 34
• Requiring dual control to authenticate the application
• Requiring an SCD with dual control to sign the non-payment software
Modified
p. 34
• Following this process both for new installations and for updates.
• Following this process both for new installations and for updates 1C-2.1.1 The non-payment software does not have any logical interfaces
•e.g., application programming interfaces (APIs)
•that allow for storing, processing, or transmitting clear-text account data.
•e.g., application programming interfaces (APIs)
•that allow for storing, processing, or transmitting clear-text account data.
Modified
p. 34
1C-2.1.1 For each POI device type and each application that does not have a business need to access account data, review the solution provider’s documentation to verify it confirms that the application has no logical interfaces that allows for storing, processing, or transmitting account data.
1C-2.1.1 For each POI device type and each non-payment software intended for that POI device type that does not have a business need to access clear-text account data, review the non-payment software vendor’s documentation to verify that the non-payment software has no logical interfaces that allows for storing, processing, or transmitting clear-text account data.
Modified
p. 34
1C-2.1.2 The application/software is authenticated within the POI device using an approved security mechanism of the POI device.
1C-2.1.2 The non-payment software is authenticated within the POI device using an approved security mechanism of the POI device.
Modified
p. 34
1C-2.1.2 Interview solution-provider personnel and observe the process for new application installations or application updates to verify that applications with no need to access clear-text account data are authenticated to the device using an approved security mechanism.
1C-2.1.2 Interview solution-provider personnel and observe the process for new installations or updates of non-payment software to verify that it is authenticated to the POI device using an approved security mechanism of the POI device.
Modified
p. 34
1C-2.1.3 Require dual control for the application-signing process.
1C-2.1.3 Requires an SCD with dual control for the application-signing process (i.e., signing non-payment software).
Modified
p. 34
1C-2.1.3 Interview solution-provider personnel and observe processes for new application installations or application updates to confirm that application signing is performed under dual control.
1C-2.1.3 Interview solution-provider personnel and observe processes for new installations or updates of non-payment software to confirm that application signing process is performed under dual control using an SCD.
Removed
p. 35
1D-1.2.1 All new installations and updates of applications must be cryptographically authenticated by the POI device’s firmware.
1D-1.2.1 Interview responsible personnel and observe installation and update processes to confirm that new application installations and updates are cryptographically authenticated by the POI device’s firmware.
1D-1.2.1 Interview responsible personnel and observe installation and update processes to confirm that new application installations and updates are cryptographically authenticated by the POI device’s firmware.
Modified
p. 35
Requirement 1D: Implement secure application-management processes.
Requirement 1D: Implement secure application-management processes Domain 1 Requirements Testing Procedures 1D-1 Integrity of applications is maintained during installation and updates.
Modified
p. 35
• Following vendor guidance in the application’s Implementation Guide.
• Following vendor guidance in the application’s Implementation Guide
Modified
p. 35
• Documented approval for all changes by appropriate personnel.
• Documented approval for all changes by appropriate personnel
Modified
p. 35
• Documented reason and impact for all changes.
• Documented reason and impact for all changes
Modified
p. 35
• Functionality testing of all changes on the intended device(s).
• Functionality testing of all changes on the intended device(s)
Modified
p. 35
• Documented back-out procedures for application installations/updates.
• Documented back-out procedures for application installations/updates
Modified
p. 35
Note: Modifications (e.g., adding an application or a POI device) to a PCI-listed P2PE Solution (or Component) requires an assessment per PCI’s “Delta Change” process. See the P2PE Program Guide for more information.
Modified
p. 35
1D-1.1.a Review the solution provider’s documented processes for implementing changes to applications, and interview solution-provider personnel, and confirm the following processes are in place:
Modified
p. 35 → 36
1D-1.2 All new installations and updates to applications must be authenticated as follows:
Requirement 1D: Implement secure application-management processes Domain 1 Requirements Testing Procedures 1D-1.2 All new installations and updates to applications must be authenticated as follows:
Removed
p. 36
Requirement 1D: Implement secure application-management processes.
1D-1.3 The application must be configured to securely integrate with any device resources that may be shared with other applications.
1D-1.4.b Interview solution-provider personnel to confirm that they follow key- management security guidance in accordance with the Implementation Guide.
1D-1.3 The application must be configured to securely integrate with any device resources that may be shared with other applications.
1D-1.4.b Interview solution-provider personnel to confirm that they follow key- management security guidance in accordance with the Implementation Guide.
Modified
p. 36
1D-1.2.1 All applications must be cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
Modified
p. 36
1D-1.2.1 Confirm the following through interviews with responsible solution provider personnel and by observing an installation/update:
Modified
p. 36
1D-1.3.b Interview solution-provider personnel to confirm that they follow key- management security guidance in accordance with the Implementation Guide.
Modified
p. 36
1D-1.3 Processes must be in place to implement application developer guidance on key and certificate usage from the application’s Implementation Guide.
Modified
p. 36
Aligns with 2B-3.1.1 1D-1.4.a Review the solution provider’s documentation and confirm their documented processes include application developer key-management security guidance.
Aligns with 2B-3.1.1 1D-1.3.a Review the solution provider’s documentation and confirm their documented processes include application developer key-management security guidance.
Removed
p. 37
1E-1 For component providers of encryption -management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated.
• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated.
Modified
p. 37
Requirement 1E: Component providers ONLY: report status to solution providers Domain 1 Requirements Testing Procedures
Requirement 1E: Component providers ONLY: report status to solution providers Domain 1 Requirements Testing Procedures 1E-1 For component providers of encryption-management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
Modified
p. 37
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the component provider’s device-management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include device-management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the component provider’s encryption management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include encryption management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).
Modified
p. 37
1E-1.1 Track status of the encryption-management services and provide reports to solution provider annually and upon significant changes, including at least the following:
1E-1.1 Track status of the encryption-management services and provide reports to solution provider annually and upon significant changes, including at least the following (per merchant location):
Modified
p. 37
• Number of devices deployed and any change in numbers since last report.
• Number of devices deployed and change since last report
Modified
p. 37
• Date of last inventory of POI device system builds.
• Date of last inventory of POI device system builds
Modified
p. 37
• Date of last inventory of POI device system builds.
• Date of last inventory of POI device system builds
Modified
p. 37
• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated.
• Date when list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated
Modified
p. 37
1E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel, and to confirm that the following processes are documented and implemented:
• Date when list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated 1E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component- provider personnel, and to confirm that the following processes are documented and implemented (per merchant location):
Modified
p. 37
• Number of devices deployed and change since last report.
• Number of POI devices deployed and any change in numbers since last report
Modified
p. 37
• Number of devices deployed and change since last report.
• Number of POI devices deployed and any change in numbers since last report
Modified
p. 37
• Date of last inventory of POI device system builds..
• Date of last inventory of POI device system builds
Modified
p. 37
• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated.
• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated 1E-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
Removed
p. 38
• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software.
Modified
p. 38
• Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change.
• Adding, changing, and/or removing P2PE applications on POI devices (i.e., software with access to clear-text account data), including description of change
Modified
p. 38
• Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change.
• Adding, changing, and/or removing P2PE non- payment software on POI devices (i.e., software without access to clear-text account data), including description of change
Modified
p. 38
• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software.
• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software
Modified
p. 38
• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software.
• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software
Modified
p. 38
Note: Adding, changing, or removing POI device types, P2PE applications, and/or P2PE non-payment software may require adherence to PCI SSC’s process for making changes. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.
Modified
p. 38
• Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change.
• Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change
Modified
p. 38
• Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change.
• Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change
Modified
p. 38
• Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change.
• Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change
Modified
p. 38
1E-1.2.b Observe reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence:
• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software 1E-1.2.b Observe reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence:
Modified
p. 38
• Adding, changing, and/or removing P2PE non-payment software (without access to clear-text account data), including description of change.
• Adding, changing, and/or removing P2PE non-payment software (without access to clear-text account data), including description of change
Removed
p. 39
Note that PA-DSS and P2PE are distinct PCI standards with separate requirements and programs, and validation against one of these standards does not imply or result in any validation against the other standard. The P2PE Standard does not require applications used in a P2PE solution to be validated to PA-DSS.
Modified
p. 39
The PTS evaluation of a PCI-approved POI device includes all firmware in the device. While it may be possible for a POI device to implement all the necessary functionality for use in a P2PE solution solely within its existing PTS-approved firmware, generally the POI device will contain additional software. When used in a P2PE solution, all software (excluding the PCI-approved POI firmware) implemented on the POI device that has the potential to access clear-text account data (P2PE applications) must be …
The PTS evaluation of a PCI-approved POI device includes all firmware in the device. While it may be possible for a POI device to implement all the necessary functionality for use in a P2PE solution solely within its existing PTS- approved firmware, generally the POI device will contain additional software. When used in a P2PE solution, all software (excluding the PCI-approved POI firmware) implemented on the POI device that has the potential to access clear-text account data (P2PE applications) must …
Modified
p. 39
See the “P2PE Solutions and Use of P2PE Applications and/or P2PE Non-payment Software” section for more information about P2PE applications and software, and about validating P2PE payment applications per this domain.
See “P2PE Solutions and use of Third Parties and/or P2PE Component Providers” for more information about P2PE applications and software, and about validating P2PE applications per this domain.
Removed
p. 41
• SRED listed as a function provided.
• SRED listed as a function provided.
• SRED listed as a function provided.
Modified
p. 41
Domain 2 Requirements Testing Procedures 2A-1 The application executes on a PCI-approved POI device with SRED enabled and active.
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-1 The application executes on a PCI-approved POI device with SRED enabled and active.
Modified
p. 41
2A-1.1 The application must be intended for use on a device approved per the PCI PTS program (e.g., a PCI-approved PED or SCR), with SRED (secure reading and exchange of data). The PTS approval listing must match the following characteristics:
2A-1.1 The application must be intended for use on a POI device approved per the PCI PTS program, with SRED (secure reading and exchange of data). The PTS approval listing must match the following characteristics:
Modified
p. 41
2A-1.1 For each POI device type used by the application, examine the POI device configurations and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
• SRED listed as a function provided 2A-1.1 For each POI device type used by the application, examine the POI device configurations and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
Modified
p. 41
2A-1.2 The application must only use the PTS SRED- validated account-data capture mechanisms of the underlying POI device for accepting and processing P2PE transactions.
• SRED listed as a function provided 2A-1.2 The application must only use the PTS SRED- validated account-data capture mechanisms of the underlying POI device for accepting and processing P2PE transactions.
Modified
p. 41
2A-2.1 The application vendor must document all flows and justify all uses of PAN and/or SAD input into, processed by, and output from the application.
2A-2.1 The application vendor must maintain current documentation for all flows and provide a business justification for all uses of PAN and/or SAD input into, processed by, and output from the application.
Modified
p. 41 → 42
2A-2.2 The application must not store PAN and/or SAD (even if encrypted) as follows:
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-2.2 The application must not store PAN and/or SAD (even if encrypted) as follows:
Modified
p. 41 → 42
• How it uses PAN and/or SAD for its application processing.
• How it uses PAN and/or SAD for its application processing
Modified
p. 41 → 42
• How it ensures the application does not store PAN after the payment transaction is complete.
• How it ensures the application does not store PAN after the payment transaction is complete
Modified
p. 41 → 42
• How it ensures the application does not store SAD after authorization is complete.
• How it ensures the application does not store SAD after authorization is complete 2A-2.2.b Perform a source-code review to verify that the application is designed such that:
Modified
p. 42
2A-2.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that:
Modified
p. 42 → 43
2A-2.3 The application must not retain PAN and/or SAD in working memory any longer than strictly necessary.
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-2.3 The application must not retain PAN and/or SAD in working memory any longer than strictly necessary.
Modified
p. 42 → 43
2A-2.4 The application must securely delete any PAN and/or SAD stored during application processing.
2A-2.4 The application must securely delete any PAN and/or SAD that was stored during application processing.
Modified
p. 42 → 43
2A-2.4.a Examine the application’s design documentation and verify it describes the process used by the application to securely delete any PAN and/or SAD stored during application processing.
2A-2.4.a Examine the application’s design documentation and verify it describes the process used by the application to securely delete any PAN and/or SAD that was stored during application processing.
Modified
p. 43
2A-2.4.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the process provided by the application renders all PAN and/or SAD data irrecoverable, in accordance with industry-accepted standards for secure deletion of data, once the business process of the application …
Modified
p. 43 → 44
2A-3 The application does not transmit clear-text PAN and/or SAD outside of the POI device, and only uses communication methods included in the scope of the PCI-approved POI device evaluation.
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-3 The application does not transmit clear-text PAN and/or SAD outside of the POI device, and only uses communication methods included in the scope of the PCI-approved POI device evaluation.
Modified
p. 43 → 44
2A-3.1.b Perform a source-code review and verify the application never outputs clear- text account data outside of the POI device.
2A-3.1.b Perform a source-code review and verify the application never outputs clear-text account data outside of the POI device.
Modified
p. 44
2A-3.1.1.c If the application outputs any truncated PANs, install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that any truncation of PANs adheres to the allowable number of digits as specified in PCI DSS and/or related FAQs.
Modified
p. 44 → 45
2A-3.1.2 If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, this is ONLY allowable if the application includes the following:
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-3.1.2 If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, this is ONLY allowable if the application includes the following:
Modified
p. 44 → 45
Note: Domain 1 (at 1B.1.1.1) and Domain 3 (at 3A-1.3) also include requirements that must be met for any POI device and for a P2PE solution provider, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.
Modified
p. 45 → 46
Domain 2 Requirements Testing Procedures 2A-3.2 The application must not facilitate, via its own logical interface(s), sharing of clear-text account data directly with other applications.
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-3.2 The application must not facilitate, via its own logical interface(s), sharing of clear-text account data directly with other applications (including non-payment software).
Modified
p. 45 → 46
Note: The application may be the only POI-resident application at the time of assessment, but other assessed applications may be added to a P2PE solution at a later date; or the application may be added to a solution that includes pre-approved applications. The assessor must test this requirement with this point in mind.
Modified
p. 45 → 46
2A-3.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the application cannot directly facilitate sharing of clear- text account data with other applications via its logical interfaces.
2A-3.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the application cannot directly facilitate sharing of clear-text account data with other applications via its logical interfaces.
Modified
p. 46 → 47
Domain 2 Requirements Testing Procedures 2A-3.3 The application must only use external communication methods included in the PCI-approved POI device evaluation.
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-3.3 The application must only use external communication methods included in the PCI-approved POI device evaluation.
Modified
p. 46 → 47
Note: Using any external communication methods not included the PCI-approved POI device evaluation will invalidate the PTS approval and such use is prohibited in P2PE solutions.
Note: Using any external communication methods not included in the PCI-approved POI device evaluation will invalidate the PTS approval and such use is prohibited in P2PE solutions.
Modified
p. 46 → 47
• A list of the external communication methods included in the POI device vendor’s security guidance.
• A list of the external communication methods included in the POI device vendor’s security guidance
Modified
p. 46 → 47
• A list of which approved external communication methods are used by the application.
• A list of which approved external communication methods are used by the application
Modified
p. 46 → 47
• A description of where external communications are used by the application.
• A description of where external communications are used by the application 2A-3.3.b Examine the application’s Implementation Guide required at 2C-3 of this document and verify it includes guidance that the use of any other method for external communication is not allowed.
Modified
p. 47 → 48
Domain 2 Requirements Testing Procedures 2A-3.4 Any whitelisting functionality implemented by the application must include guidance in the application’s Implementation Guide that includes the following:
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-3.4 Any whitelisting functionality implemented by the application must include guidance in the application’s Implementation Guide that includes the following:
Modified
p. 47 → 48
• How to configure the whitelisting functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data.
• How to configure the whitelisting functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data
Modified
p. 47 → 48
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
Modified
p. 47 → 48
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
Modified
p. 47 → 48
• How to perform cryptographic authentication by the POI device’s firmware.
• How to perform cryptographic authentication by the POI device’s firmware
Modified
p. 47 → 48
• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data.
• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data
Modified
p. 47 → 48
• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data.
• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data
Modified
p. 47 → 48
• That such functionality must be approved by authorized personnel prior to implementation.
• That such functionality must be approved by authorized personnel prior to implementation
Modified
p. 47 → 48
• That such functionality must be approved by authorized personnel prior to implementation.
• That such functionality must be approved by authorized personnel prior to implementation
Modified
p. 47 → 48
• That all new installations or updates to whitelist functionality must include the following: o Description and justification for the functionality. o Who approved the new installation or updated functionality prior to release. o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data.
• That all new installations or updates to whitelist functionality must include the following:
Modified
p. 47 → 48
− Description and justification for the functionality − Who approved the new installation or updated functionality prior to release − Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 2A-3.4 For any whitelisting functionality implemented by the application, examine the application’s Implementation Guide required at 2C-3 of this document and verify it contains details to describe any whitelisting functionality and that it provides instructions as follows:
Modified
p. 47 → 48
• How to establish cryptographically authentication by the POI device’s firmware.
• How to establish cryptographically authentication by the POI device’s firmware
Modified
p. 47 → 48
• That documentation for all new installations or updates to whitelist functionality includes the following: o Description and justification for the functionality. o Who approved the new installation or updated functionality prior to release. o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data.
• That documentation for all new installations or updates to whitelist functionality includes the following:
Removed
p. 48
• Implemented per the POI device vendor's security guidance.
2B-1.1.1 Live PANs are not used for testing or development.
2B-1.1.1 Live PANs are not used for testing or development.
Modified
p. 48 → 49
Domain 2 Requirements Testing Procedures 2B-1 The application is developed and tested according to industry-standard software development life cycle practices that incorporate information security.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1 The application is developed and tested according to industry-standard software development life cycle practices that incorporate information security.
Modified
p. 48 → 49
2B-1.1.a Examine the application vendor’s written software development processes to verify the following:
2B-1.1.a Examine the application vendor’s software development processes to verify the following:
Modified
p. 48 → 49
• Incorporated into the application developer’s written software development processes.
• Incorporated into the application developer’s written software development processes
Modified
p. 48 → 49
2B-1.1.c Examine the application’s Implementation Guide required at 2C-3 of this document and verify it provides information from the POI device vendor’s security guidance applicable to the solution provider (e.g., application configuration settings which are necessary for the application to function with the device).
• Implemented per the POI device vendor's security guidance 2B-1.1.c Examine the application’s Implementation Guide required at 2C-3 of this document and verify it provides information from the POI device vendor’s security guidance applicable to the solution provider (e.g., application configuration settings which are necessary for the application to function with the device).
Modified
p. 48 → 49
• Examine written software development processes and interview software developers.
• Examine software development processes and interview software developers.
Modified
p. 48 → 50
2B-1.1.2 Development, test, and/or custom application data/accounts, user IDs, and passwords must be removed before applications are released for production or released to customers.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.1.2 Development, test, and/or custom application data/accounts, user IDs, and passwords must be removed before applications are released for production or released to customers.
Modified
p. 48 → 50
2B-1.1.2 Examine written software-development procedures and interview responsible personnel to verify that development, test, and/or custom application data/accounts, user IDs, and passwords are removed before an application is released for production or released to customers.
2B-1.1.2 Examine the software-development procedures and interview responsible personnel to verify that development, test, and/or custom application data/accounts, user IDs, and passwords are removed before an application is released for production or released to customers.
Modified
p. 49 → 50
2B-1.2 Application code and any non-code configuration mechanisms must be reviewed prior to every release or update.
Modified
p. 49 → 50
• Changes to code that manages security-sensitive configuration options are reviewed to confirm that they will not result in the exposure of PCI payment-brand accounts/cards.
• Changes to code that manages security-sensitive configuration options are reviewed to confirm that they will not result in the exposure of PCI payment- brand accounts/cards.
Modified
p. 49 → 50
2B-1.2.3 Examine change control documentation for a sample of code changes to verify that appropriate corrections are implemented prior to release.
2B-1.2.3 Examine change-control documentation for a sample of code changes to verify that appropriate corrections are implemented prior to release.
Modified
p. 49 → 50
2B-1.2.4 Examine change control documentation for a sample of code changes to verify that review results are reviewed and approved by management prior to release.
2B-1.2.4 Examine change-control documentation for a sample of code changes to verify that review results are reviewed and approved by management prior to release.
Modified
p. 49 → 51
2B-1.3 All changes to the application must follow change- control procedures.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.3 All changes to the application must follow change- control procedures.
Removed
p. 50
Domain 2 Requirements Testing Procedures 2B-1.3.b Examine the application’s Implementation Guide required at 2C-3 of this document and verify it includes the following:
Modified
p. 50 → 51
• Instructions detailing back-out or de-installation procedures for the application 2B-1.3.c Examine recent application changes, and trace those changes back to related change-control documentation. Verify that, for each change examined, the following was documented according to the change-control procedures:
• Instructions detailing back-out or de-installation procedures for the application 2B-1.3.c Examine recent application changes and trace those changes back to related change-control documentation. Verify that, for each change examined, the following was documented according to the change-control procedures:
Modified
p. 50 → 51
2B-1.3.1 Documentation of impact 2B-1.3.1 Verify that documentation of customer impact is included in the change- control documentation for each change.
2B-1.3.1 Documentation of impact. 2B-1.3.1 Verify that documentation of customer impact is included in the change- control documentation for each change.
Modified
p. 50 → 51
2B-1.3.2 Verify that documented approval by appropriate authorized parties is present for each change.
Modified
p. 50 → 52
2B-1.4 Applications must be developed according to industry best practices for secure coding techniques, including (but not limited to):
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.4 Applications must be developed according to industry best practices for secure coding techniques, including (but not limited to):
Modified
p. 50 → 52
• Developing with least privilege.
• Developing with least privilege
Modified
p. 50 → 52
• Developing with fail-safe defaults.
• Developing with fail-safe defaults
Modified
p. 50 → 52
• Developing with defensive (protective) techniques regarding the logical input interfaces of the application.
• Developing with defensive (protective) techniques regarding the logical input interfaces of the application 2B-1.4.1 Application development processes must include prevention of common coding vulnerabilities.
Removed
p. 51
• Coverage of all functions of the application, including but not limited to, security- impacting features and features that cross trust boundaries.
• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
• A list of potential threats and vulnerabilities resulting from account-data flow analyses, and assigned risk ratings (e.g., high, medium, or low priority) to each.
• Implementation of appropriate corrections and countermeasures during the development process.
• Documentation of application risk-assessment results for management review and approval.
• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
• A list of potential threats and vulnerabilities resulting from account-data flow analyses, and assigned risk ratings (e.g., high, medium, or low priority) to each.
• Implementation of appropriate corrections and countermeasures during the development process.
• Documentation of application risk-assessment results for management review and approval.
Modified
p. 51 → 52
2B-1.4.1.b Verify that applications are not vulnerable to common coding vulnerabilities by performing manual or automated penetration testing that specifically attempts to exploit vulnerabilities relevant to the application (an example of such a vulnerability would include buffer overflows).
Modified
p. 51 → 53
2B-1.4.2 Application risk-assessment techniques (e.g., (application threat-modeling) must be used to identify potential application-security design flaws and vulnerabilities during the software-development process. Risk-assessment processes include the following:
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.4.2 Application risk-assessment techniques (e.g., (application threat-modeling) must be used to identify potential application-security design flaws and vulnerabilities during the software-development process. Risk-assessment processes include the following:
Modified
p. 51 → 53
• Identification of all areas within the application that interact with account data, as well as any process- oriented outcomes that could lead to the exposure of account data.
• Identification of all areas within applications that interact with account data, as well as any process-oriented outcomes that could lead to the exposure of account data.
Modified
p. 51 → 53
• A list of potential threats and vulnerabilities resulting from account-data flow analyses and assigned risk ratings (e.g., high, medium, or low priority) to each.
• A list of potential threats and vulnerabilities resulting from account-data-flow analyses, and assigned risk ratings (e.g., high, medium, or low priority) to each.
Modified
p. 52 → 54
Domain 2 Requirements Testing Procedures 2B-1.5 Application vendor must provide training in secure development practices to application developers, as applicable for the developer’s job function and technology used, e.g.:
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.5 Application vendor must provide training in secure development practices to application developers, as applicable for the developer’s job function and technology used, e.g.:
Modified
p. 52 → 54
• Secure coding techniques to avoid common coding vulnerabilities (e.g., vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.).
• Secure coding techniques to avoid common coding vulnerabilities (e.g., vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.)
Modified
p. 52 → 54
• Managing sensitive data in memory.
• Managing sensitive data in memory
Modified
p. 52 → 54
• Security testing (e.g., penetration testing techniques).
• Security testing (e.g., penetration testing techniques)
Modified
p. 52 → 54
• Risk-assessment techniques.
• Risk-assessment techniques
Modified
p. 52 → 54
Note: Training for application developers may be provided in-house or by third parties. Examples of how training may be delivered include on-the-job, instructor-led, and computer- based.
Note: Training for application developers may be provided in-house or by third parties. Examples of how training may be delivered include on-the-job, instructor-led, and computer-based.
Modified
p. 52 → 54
2B-1.6 Secure source-control practices must be implemented to verify integrity of source-code during the development process.
2B-1.6 Secure source-control practices must be implemented to verify the integrity of source-code during the development process.
Modified
p. 52 → 54
2B-1.6.a Examine written software-development procedures and interview responsible personnel to verify the vendor maintains secure source-code control practices to verify integrity of source-code during the development process.
2B-1.6.a Examine written software-development procedures and interview responsible personnel to verify the vendor maintains secure source-code control practices to verify the integrity of source-code during the development process.
Modified
p. 52 → 54
2B-1.6.b Examine mechanisms and observe procedures for securing source-code to verify integrity of source-code is maintained during the development process.
2B-1.6.b Examine mechanisms and observe procedures for securing source-code to verify the integrity of source-code is maintained during the development process.
Modified
p. 52 → 54
2B-1.7 Examine documented software-development processes to verify they include the application vendor’s versioning methodology, and that the versioning methodology must be in accordance with the P2PE Program Guide.
Modified
p. 53 → 55
Domain 2 Requirements Testing Procedures 2B-1.7.1 The vendor’s software versioning methodology must define the specific version elements used, including at least the following:
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.7.1 The vendor’s software versioning methodology must define the specific version elements used, including at least the following:
Modified
p. 53 → 55
• The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric characters).
• The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric characters)
Modified
p. 53 → 55
• Definition of what each element represents in the version scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.).
• Definition of what each element represents in the version scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.)
Modified
p. 53 → 55
• Definition of elements that indicate use of wildcards.
• Definition of elements that indicate use of wildcards
Modified
p. 53 → 55
2B-1.7.1.a Examine recent application changes, the version numbers assigned, and the change control documentation that specifies the type of application change and verify that the elements in the version number match the applicable change and the parameters defined in the documented versioning methodology.
2B-1.7.1.a Examine recent application changes, the version numbers assigned, and the change-control documentation that specifies the type of application change and verify that the elements in the version number match the applicable change and the parameters defined in the documented versioning methodology.
Removed
p. 54
• Specific identification and definition of changes that: o Have no impact on functionality of the application or its dependencies o Have impact on application functionality but no impact on security or P2PE requirements o Have impact to any security functionality or P2PE requirement.
Modified
p. 54 → 56
Domain 2 Requirements Testing Procedures 2B-1.8 The versioning methodology must indicate the type and impact of all application changes in accordance with the P2PE Program Guide, including:
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.8 The versioning methodology must indicate the type and impact of all application changes in accordance with the P2PE Program Guide, including:
Modified
p. 54 → 56
• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application).
• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application)
Modified
p. 54 → 56
• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application).
• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application)
Modified
p. 54 → 56
• How each type of change ties to a specific version number.
• How each type of change ties to a specific version number 2B-1.8.a Examine the software vendor’s documented versioning methodology to verify the version methodology includes:
Modified
p. 54 → 56
• Specific identification and definition of changes that: o Have no impact on functionality of the application or its dependencies o Have impact on application functionality but no impact on security or P2PE requirements o Have impact to any security functionality or P2PE requirement.
• Specific identification and definition of changes that: − Have no impact on functionality of the application or its dependencies − Have impact on application functionality but no impact on security or P2PE requirements − Have impact to any security functionality or P2PE requirement
• Specific identification and definition of changes that: − Have no impact on functionality of the application or its dependencies − Have impact on application functionality but no impact on security or P2PE requirements − Have impact …
• Specific identification and definition of changes that: − Have no impact on functionality of the application or its dependencies − Have impact on application functionality but no impact on security or P2PE requirements − Have impact …
Modified
p. 54 → 56
2B-1.8.d Select a sample of recent payment application changes and review the change control documentation that specifies the type of application change to verify that the version assigned to the change matches the type of change according to the documented methodology.
2B-1.8.d Select a sample of recent payment application changes and review the change-control documentation that specifies the type of application change to verify that the version assigned to the change matches the type of change according to the documented methodology.
Modified
p. 55 → 57
Domain 2 Requirements Testing Procedures 2B-1.9 The versioning methodology must specifically identify whether wildcards are used and, if so, how they are used. The following must be included:
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.9 The versioning methodology must specifically identify whether wildcards are used and, if so, how they are used. The following must be included:
Modified
p. 55 → 57
• Details of how wildcards are used in the versioning methodology.
• Details of how wildcards are used in the versioning methodology
Modified
p. 55 → 57
2B-1.9.d Select a sample of recent payment application changes and review the change control documentation that specifies the type of application change. Verify that:
2B-1.9.d Select a sample of recent payment application changes and review the change-control documentation that specifies the type of application change. Verify that:
Modified
p. 55 → 57
• Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are not used to represent a security impacting change.
• Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are not used to represent a security impacting change
Removed
p. 56
• Confirmation that secure development processes were followed by the vendor.
Modified
p. 56 → 58
Requirement 2B: Develop and maintain secure applications.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.10 The vendor’s published versioning methodology must be communicated to customers and integrators/ resellers.
Modified
p. 56 → 58
• Signature by an authorized party to formally approve release of the application or application update.
• Signature by an authorized party to formally approve release of the application or application update
Modified
p. 56 → 58
2B-1.13.a Examine documented processes to verify that final release of the application and any application updates are formally approved and documented, including a signature by an authorized party to formally approve the release and confirmation that all SDLC processes were followed.
• Confirmation that secure development processes were followed by the vendor 2B-1.13.a Examine software release processes to verify that final release of the application and any application updates are formally approved and documented, including a signature by an authorized party to formally approve the release and confirmation that all applicable secure development processes were followed by the vendor.
Modified
p. 56 → 58
• Formal approval and signature by an authorized party.
• Formal approval and signature by an authorized party
Modified
p. 56 → 58
• Confirmation that that all secure development processes were followed.
• Confirmation that that all secure development processes were followed
Modified
p. 57 → 59
Requirement 2B: Develop and maintain secure applications.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-2 The application is implemented securely, including the secure use of any resources shared between different applications.
Modified
p. 57 → 59
Note: POI device vendor security guidance is intended for application developers, system integrators, and end-users of the platform to meet requirements in the PCI PTS Open Protocols module as part of a PCI-approved POI device evaluation.
Note: POI device vendor security guidance is intended for application developers, system integrators, and end-users of the platform to meet the PCI PTS POI Open Protocol requirements as part of a PCI-approved POI device evaluation.
Modified
p. 57 → 59
Note: The PTS POI Open Protocols module ensures that open protocols and services in POI devices do not have vulnerabilities that can be remotely exploited and yield access to sensitive data or resources in the device. The POI device vendor defines what protocols and services are supported by the device and provides guidance to their use.
Note: The PCI PTS POI Open Protocol requirements ensures that open protocols and services in POI devices do not have vulnerabilities that can be remotely exploited and yield access to sensitive data or resources in the device. The POI device vendor defines what protocols and services are supported by the device and provides guidance to their use.
Modified
p. 57 → 59
Adding or enabling additional services or protocols, or failing to follow the issued POI device vendor’s security guidance will invalidate the approval status of that device for that implementation.
Adding or enabling additional services or protocols, or failing to follow the issued POI device vendor’s security guidance, will invalidate the approval status of that device for that implementation.
Modified
p. 57 → 59
2B-2.1.1 Perform a source-code review and verify that the application:
Modified
p. 57 → 59
• Was developed according to the POI device vendor’s security guidance with respect to the documented Open Protocols.
• Was developed according to the POI device vendor’s security guidance with respect to the documented Open Protocols
Modified
p. 58 → 60
Domain 2 Requirements Testing Procedures 2B-2.2 The application-development process must include secure integration with any resources shared with or between applications.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-2.2 The application-development process must include secure integration with any resources shared with or between applications.
Modified
p. 58 → 60
• A description of how the application connects to and/or uses shared resources.
• A description of how the application connects to and/or uses shared resources
Modified
p. 58 → 60
• Instructions for how the application should be configured to ensure secure integration with shared resources.
• Instructions for how the application should be configured to ensure secure integration with shared resources 2B-2.2.b Perform a source-code review and verify that any connection to, or use of, shared resources is done securely and in accordance with the POI device vendor’s security guidance.
Modified
p. 59 → 61
Domain 2 Requirements Testing Procedures 2B-2.6 If the application provides configuration/update functionality at-the-terminal (e.g., using an on-screen menu system), the application must not bypass or render ineffective any applicable controls contained within this standard.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-2.6 If the application provides configuration/update functionality at-the-terminal (e.g., using an on-screen menu system), the application must not bypass or render ineffective any applicable controls contained within this standard.
Modified
p. 59 → 61
2B-3.1.1 The application developer must provide key- management security guidance describing how cryptographic keys and certificates have to be used.
2B-3.1.1 The application developer must provide security guidance describing how cryptographic keys and/or certificates have to be used.
Modified
p. 59 → 61
2B-3.1.1 Review the application’s Implementation Guide required at 2C-3 of this document, and confirm it includes key-management security guidance for solution providers, describing how cryptographic keys and certificates have to be used and managed.
2B-3.1.1 Review the application’s Implementation Guide required at 2C-3 of this document, and confirm it includes security guidance for solution providers, describing how cryptographic keys and/or certificates have to be used and managed.
Modified
p. 60 → 62
Domain 2 Requirements Testing Procedures 2B-4 Applications do not implement any encryption functions in lieu of SRED encryption. All such functions are performed by the approved SRED firmware of the POI device.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-4 Applications do not implement any account-data encryption functions in lieu of SRED encryption. All such functions are performed by the approved SRED firmware of the POI device.
Modified
p. 60 → 62
Note: The application may provide additional encryption to existing SRED encryption, but cannot bypass or replace SRED encryption.
Note: The application may provide additional encryption on the SRED-encrypted account data; however it cannot bypass or replace the SRED encryption of the clear-text account data.
Modified
p. 60 → 62
2B-4.1 The application must not encrypt clear-text account data. This means the application must not implement any encryption functions that bypass or are intended to be used instead of the approved SRED functions of the POI device.
2B-4.1 The application must not directly encrypt clear-text account data. The application must not implement any account-data encryption functions that bypass or are intended to be used instead of the approved SRED encryption functions of the POI device’s firmware.
Modified
p. 60 → 62
• Confirmation that the application does not perform encryption of clear-text account- data, nor does it replace the POI device’s SRED encryption
• Confirmation that the application does not perform encryption of clear-text account-data, nor does it replace the POI device’s SRED encryption
Removed
p. 61
• All applications are tested for vulnerabilities.
Modified
p. 61 → 64
Requirement 2C: Implement secure application-management processes.
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-1 New vulnerabilities are discovered and applications are tested for those vulnerabilities on an ongoing basis.
Modified
p. 61 → 64
• Using outside sources for security vulnerability information.
• Using outside sources for security vulnerability information
Modified
p. 61 → 64
• Periodic testing of applications for new vulnerabilities.
• Periodic testing of applications for new vulnerabilities 2C-1.1.b Interview responsible software vendor personnel to confirm the following:
Modified
p. 61 → 64
• New vulnerabilities are identified using outside sources of security vulnerability information.
• New vulnerabilities are identified using outside sources of security vulnerability information
Modified
p. 61 → 64
2C-1.2 Software vendors must establish and implement a process to develop and deploy critical security updates to address discovered security vulnerabilities in a timely manner.
• All applications are tested for vulnerabilities 2C-1.2 Software vendors must establish and implement a process to develop and deploy critical security updates to address discovered security vulnerabilities in a timely manner.
Modified
p. 61 → 65
2C-2 Applications are installed and updates are implemented only via trusted and cryptographically authenticated processes using an approved security mechanism evaluated for the PCI-approved POI device.
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-2 Applications are installed and updates are implemented on the PCI-approved POI devices only via trusted and cryptographically authenticated processes using an approved security mechanism evaluated for the PCI-approved POI devices.
Modified
p. 61 → 65
2C-2.1.1 All application installations and updates are cryptographically authenticated using the approved security mechanisms of the POI device’s firmware.
2C-2.1.1 All application installations and updates on a POI device are cryptographically authenticated using the approved security mechanisms of the POI device’s firmware.
Modified
p. 61 → 65
• A description of how the application is cryptographically authenticated using the approved security mechanisms of the POI device’s firmware for any application installations and updates.
• A description of how the application is cryptographically authenticated using the approved security mechanisms of the POI device’s firmware for any application installations and updates
Modified
p. 61 → 65
• Instructions for how to use the approved security mechanisms to perform application installations and updates.
• Instructions for how to use the approved security mechanisms to perform application installations and updates
Modified
p. 61 → 65
• A statement that application installations and updates cannot occur except by using the approved security mechanisms of the POI device’s firmware.
• A statement that application installations and updates cannot occur except by using the approved security mechanisms of the POI device’s firmware 2C-2.1.1.b Perform a source-code review to verify that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware.
Removed
p. 62
Requirement 2C: Implement secure application-management processes.
Domain 2 Requirements Testing Procedures 2C-2.1.1.b Perform a source-code review to verify that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware.
Domain 2 Requirements Testing Procedures 2C-2.1.1.b Perform a source-code review to verify that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware.
Modified
p. 62 → 65
2C-2.1.1.d After the application is installed and configured in accordance with the Implementation Guide, attempt to perform an installation and an update using non- approved security mechanisms, and verify that the POI device will not allow the installation or update to occur.
2C-2.1.1.d After the application is installed and configured in accordance with the Implementation Guide, attempt to perform an installation and an update using non-approved security mechanisms, and verify that the POI device will not allow the installation or update to occur.
Modified
p. 62 → 66
2C-2.1.2 The application developer includes guidance for whoever signs the application, including requirements for dual control over the application-signing process.
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-2.1.2 The application developer includes guidance for whoever signs the application, including requirements for using an SCD with dual control for the application-signing process.
Modified
p. 62 → 66
• Instructions for how to sign the application.
• Instructions for how to sign the application
Modified
p. 62 → 66
• Instructions how to implement the dual control for the application-signing process.
• Instructions how to use an SCD with dual control for the application-signing process
Modified
p. 62 → 66
• A statement that all applications must be signed via the instructions provided in the Implementation Guide.
• A statement that all applications must be signed via the instructions provided in the Implementation Guide 2C-3 Maintain instructional documentation and training programs for the application’s installation, maintenance/upgrades, and use.
Removed
p. 63
Requirement 2C: Implement secure application-management processes.
• Any changes to the Implementation Guide requirements in this document.
• Any changes to the Implementation Guide requirements in this document.
Modified
p. 63 → 66
2C-3.1.2 Review of the Implementation Guide at least annually and upon changes to the application or the P2PE Domain 2 requirements, and update as needed to keep the documentation current with:
Modified
p. 63 → 66
• Any changes to the application (e.g., device changes/upgrades and major and minor software changes).
• Any changes to the application (e.g., device changes/upgrades and major and minor software changes)
Modified
p. 63 → 66
• Any changes to the application (e.g., device changes/upgrades and major and minor software changes).
• Any changes to the application (e.g., device changes/upgrades and major and minor software changes)
Modified
p. 63 → 66
• Any changes to the Implementation Guide requirements in this document.
• Any changes to the Implementation Guide requirements in this document 2C-3.1.2.a Verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements.
Modified
p. 63 → 66
2C-3.1.3 Distribution to all new and existing application installers (e.g., solution providers, integrator/resellers, etc.), and re-distribution to all existing application installers every time the guide is updated.
• Any changes to the Implementation Guide requirements in this document 2C-3.1.3 Distribution to all new and existing application installers (e.g., solution providers, integrator/resellers, etc.), and re-distribution to all existing application installers every time the guide is updated.
Modified
p. 63 → 67
2C-3.2 Develop and implement training and communication programs to ensure application installers (e.g., solution providers or integrators/resellers) know how to implement the application according to the Implementation Guide.
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-3.2 Develop and implement training and communication programs to ensure application installers (e.g., solution providers or integrators/resellers) know how to implement the application according to the Implementation Guide.
Modified
p. 64 → 68
Domain 2 Requirement Required Content for the Implementation Guide 2A-3.2 The application must not facilitate, via its own logical interface(s), sharing of clear-text account data directly with other applications.
Domain 2 Requirement Required Content for the Implementation Guide 2A-3.2 The application must not facilitate, via its own logical interface(s), sharing of clear-text account data directly with other applications (including non-payment software).
Modified
p. 64 → 68
• The logical interfaces not intended for sharing of clear-text account data (e.g., those for communication with other applications) 2A-3.3 The application only uses external communication methods included in the PCI- approved POI device evaluation and has not implemented its own external communication stack.
• The logical interfaces not intended for sharing of clear-text account data (e.g., those for communication with other applications) 2A-3.3 The application only uses external communication methods included in the PCI-approved POI device evaluation and has not implemented its own external communication stack.
Modified
p. 65 → 69
• How to configure the whitelisting functionality to ensure the output of clear- text account data is prohibited, except for non-PCI payment brand account/card data.
• How to configure the whitelisting functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data.
Modified
p. 65 → 69
• That documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that it was reviewed prior to release to only output non- PCI payment brand account/card data Details to describe any whitelisting functionality implemented by the application as follows:
• That documentation for all new installations or updates to whitelist functionality that includes the following:
Modified
p. 65 → 69
• How to configure the application functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data
• How to configure the application functionality to ensure the output of clear- text account data is prohibited, except for non-PCI payment brand account/card data
Removed
p. 66
• A description of how the device connects to and/or uses shared resources Instructions for how the application should be configured to ensure secure integration with shared resources 2B-3.1.1 The application developer must provide key- management security guidance describing how keys and certificates have to be used.
Modified
p. 66 → 71
Security guidance for solution providers, describing how cryptographic keys and/or certificates have to be used and managed.
Modified
p. 67 → 71
• Confirmation that the application does not perform encryption of clear-text account data, nor does it replace the POI device’s SRED encryption
• Confirmation that the application does not perform its own encryption of clear-text account data, nor does it replace the POI device’s SRED encryption.
Modified
p. 67 → 71
• A description of the purpose and encryption method for any encryption provided by the application in addition to SRED encryption 2C-2.1.1 All application installations and updates are cryptographically authenticated using the approved security mechanisms of the POI device’s firmware.
• A description of the purpose and encryption method for any encryption provided by the application in addition to SRED encryption.
Modified
p. 67 → 71
• A statement that application installations and updates cannot occur except by using the approved security protocol of the POI device’s firmware 2C-2.1.2 The application developer includes guidance for whoever signs the application, including requirements for dual control over the application-signing process.
• A statement that application installations and updates cannot occur except by using the approved security protocol of the POI device’s firmware The application developer includes guidance for whoever signs the application, including requirements for using an SCD with dual control for the application-signing process.
Modified
p. 68 → 72
For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 5, and 6 of this document refers to the merchant’s encryption environments, and represents requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 4, and 5 of this document refers to the merchant’s encryption environments and represents requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
Modified
p. 69 → 73
• Shows all account data flows across systems and networks from the point the card data is captured through to the point the card data exits the decryption environment.
• Shows all account-data flows across systems and networks from the point the card data is captured through to the point the card data exits the decryption environment.
Removed
p. 70
• Following up with the component provider to resolve any questions or changes in expected performance of the component provider.
Modified
p. 70 → 75
3A-2 The solution provider manages and monitors status reporting from P2PE component providers.
Requirement 3A: P2PE solution management Domain 3 Requirements Testing Procedures 3A-2 The solution provider manages and monitors status reporting from P2PE component providers.
Modified
p. 70 → 75
• Ensuring reports are received from all P2PE component providers as specified in the “Component providers ONLY: report status to solution providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider).
• Ensuring reports are received from all P2PE component providers as specified in the “Component providers ONLY: report status to solution providers” sections of this Standard (as applicable to the component provider)
Modified
p. 70 → 75
• Ensuring reports are received from all P2PE component providers as specified in the “Component providers ONLY: report status to solution providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider).
• Ensuring reports are received from all P2PE component providers as specified in the “Component providers ONLY: report status to solution providers” sections of this Standard (as applicable to the component provider)
Modified
p. 70 → 75
• Confirming reports include at least the details specified in the “Component providers ONLY: report status to solution providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider), and any additional details as agreed between a component provider and the solution provider.
• Confirming reports include at least the details specified in the “Component providers ONLY: report status to solution providers” sections of this Standard (as applicable to the component provider), and any additional details as agreed between a component provider and the solution provider
Modified
p. 70 → 75
• Confirming reports include at least the details specified in the “Component providers ONLY: report status to solution providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider), and any additional details as agreed between a component provider and the solution provider.
• Confirming reports include at least the details specified in the “Component providers ONLY: report status to solution providers” sections of this Standard (as applicable to the component provider), and any additional details as agreed between a component provider and the solution provider
Modified
p. 70 → 75
• Following up with the component provider to resolve any questions or changes in expected performance of the component provider.
• Following up with the component provider to resolve any questions or changes in expected performance of the component provider 3A-2.2 Processes must be implemented to ensure P2PE controls are maintained when changes to the P2PE solution occur including, but not limited to:
Modified
p. 70 → 75
3A-2.1 Where component providers are used, interview responsible personnel, review documentation, and observe processes to verify the solution provider has implemented a methodology for managing and monitoring status reporting from P2PE component providers, including processes for:
• Following up with the component provider to resolve any questions or changes in expected performance of the component provider 3A-2.1 Where component providers are used, interview responsible personnel, review documentation, and observe processes to verify the solution provider has implemented a methodology for managing and monitoring status reporting from P2PE component providers, including processes for:
Removed
p. 71
Requirement 3A: P2PE solution management Domain 3 Requirements Testing Procedures 3A-2.2 Processes must be implemented to ensure P2PE controls are maintained when changes to the P2PE solution occur including, but not limited to:
Modified
p. 71 → 76
3A-3 Solution provider implements processes to respond to notifications from merchants, component providers, and/or other third parties, and provide notifications about any suspicious activity involving the P2PE solution.
Requirement 3A: P2PE solution management Domain 3 Requirements Testing Procedures 3A-3 Solution provider implements processes to respond to notifications from merchants, component providers, and/or other third parties, and provide notifications about any suspicious activity involving the P2PE solution.
Modified
p. 71 → 76
• Encryption/decryption failures 3A-3.2 Upon detection of any suspicious activity defined at 3B-4.1, the POI device must be immediately removed, shut down, or taken offline until the integrity of the device is verified and the P2PE encryption mechanism is restored.
• Encryption/decryption failures 3A-3.2 Upon detection of any suspicious activity defined at 3A-3.1, the POI device must be immediately removed, shut down, or taken offline until the integrity of the device is verified and the P2PE encryption mechanism is restored.
Modified
p. 71 → 76
3A-3.2 Review documented procedures and interview responsible personnel to verify that upon detection of any suspicious activity defined at 3A-4.1, POI devices are immediately removed, shut down, or taken offline.
3A-3.2 Review documented procedures and interview responsible personnel to verify that upon detection of any suspicious activity defined at 3A-3.1, POI devices are immediately removed, shut down, or taken offline.
Modified
p. 72 → 76
3A-3.2.1 The POI device must not be re-enabled until it is confirmed that either:
Modified
p. 72 → 76
• The merchant has provided written notification (signed by a merchant executive officer) formally requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement 3B-5.1).
• The merchant has provided written notification (signed by a merchant executive officer) formally requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement 3A-4.1).
Modified
p. 72 → 76
• The merchant has provided written notification (signed by a merchant executive officer) requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement 3B-5.1).
• The merchant has provided written notification (signed by a merchant executive officer) requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement 3A-4.1).
Modified
p. 72 → 77
3A-3.3 The solution provider must maintain a record of all suspicious activity, to include the following:
Requirement 3A: P2PE solution management Domain 3 Requirements Testing Procedures 3A-3.3 The solution provider must maintain a record, at minimum of one year, of all suspicious activity, to include the following:
Modified
p. 72 → 77
• Details of whether any account data was transmitted from the POI device(s) during the time that encryption was malfunctioning or disabled.
• Details of whether any account data was transmitted from the POI device(s) during the time that encryption was malfunctioning or disabled 3A-3.4 Procedures must incorporate any applicable incident response procedures defined by the PCI payment brands, including timeframes for reporting incidents.
Modified
p. 72 → 77
3A-3.4.b Interview responsible personnel to verify that any response procedures defined by all applicable PCI payment brands, including timeframes for reporting incidents, are known and implemented.
Removed
p. 73
3A-4 If the solution allows a merchant to stop P2PE encryption of account data, the solution provider manages the related process for merchants.
3A-4.1 If the solution provides an option to allow merchants to stop P2PE encryption of account data, the solution provider must document and implement a process for merchants that includes the following:
3A-4.1 If the solution provides an option to allow merchants to stop P2PE encryption of account data, examine documented procedures to verify the solution provider has a documented process for merchants to follow that includes the requirements specified at 3A-4.1.1 and 3A-4.1.2.
3A-4.1.1 P2PE encryption of account data for a merchant is stopped only upon receipt by the solution provider of a formal request from the merchant (signed by a merchant executive officer).
3A-4.1.1 Interview responsible personnel and observe processes to verify that P2PE encryption of account data for a merchant is stopped only upon receipt by the solution …
3A-4.1 If the solution provides an option to allow merchants to stop P2PE encryption of account data, the solution provider must document and implement a process for merchants that includes the following:
3A-4.1 If the solution provides an option to allow merchants to stop P2PE encryption of account data, examine documented procedures to verify the solution provider has a documented process for merchants to follow that includes the requirements specified at 3A-4.1.1 and 3A-4.1.2.
3A-4.1.1 P2PE encryption of account data for a merchant is stopped only upon receipt by the solution provider of a formal request from the merchant (signed by a merchant executive officer).
3A-4.1.1 Interview responsible personnel and observe processes to verify that P2PE encryption of account data for a merchant is stopped only upon receipt by the solution …
Modified
p. 73 → 78
• Implementing controls to prevent cause from recurring 3A-3.6.b For a sample of P2PE control failures, interview personnel and review supporting document to verify that:
• Implementing controls to prevent cause from recurring 3A-3.5.b For a sample of P2PE control failures, interview personnel and review supporting document to verify that:
Removed
p. 74
3B-1.1.b If the solution provider utilizes any third parties, examine the business agreements and verify the elements delineated in 3C-1.1.a are present and adequately accounted for.
Modified
p. 74 → 79
• Maintaining compliance with applicable P2PE and/or
• Maintaining compliance with applicable P2PE and/or PCI DSS requirements as needed
Modified
p. 74 → 79
• Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE Domain.
• Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE Domain 3B-1.1.a Examine documented procedures to verify the solution provider has a formalized process in place to establish agreements with all third parties performing services or functions governed by any other domain within this standard. The formalized agreement must include:
Modified
p. 74 → 79
• Maintaining compliance with applicable P2PE and/or PCI DSS requirements as
• Maintaining compliance with applicable P2PE and/or PCI DSS requirements as needed
Modified
p. 74 → 79
• Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE Domain.
• Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE Domain 3B-1.1.b If the solution provider utilizes any third parties, examine the business agreements and verify the elements delineated in 3B-1.1.a are present and adequately accounted for.
Removed
p. 75
• Notification of any changes to POI devices, P2PE applications, P2PE non-payment software, and/or HSMs per PCI SSC’s process for P2PE Designated Changes to Solutions
• Notification of any changes to POI devices, P2PE applications, P2PE non-payment software, and/or HSMs per PCI SSC’s process for P2PE Designated Changes to Solutions
• Notification of any changes to POI devices, P2PE applications, P2PE non-payment software, and/or HSMs per PCI SSC’s process for P2PE Designated Changes to Solutions
Modified
p. 75 → 80
Requirement 3B: Third-party management Domain 3 Requirements Testing Procedures 3B-1.2 For all third parties that have been contracted by the solution provider to manage any of the SCD types used in the P2PE solution, the solution provider must establish formal agreements with the third parties to provide them with the following:
Requirement 3B: Third-party management Domain 3 Requirements Testing Procedures 3B-1.2 For all third parties that have been contracted by the solution provider to manage any of the SCD types used in the P2PE solution, the solution provider must establish formal agreements with the third parties to ensure those third parties provide the Solution Provider with the following:
Modified
p. 75 → 80
• Details of the change, including reason
• Details of the change, including the reason for the change
Modified
p. 75 → 80
• Details of the change, including reason
• Details of the change, including the reason for the change
Modified
p. 75 → 80
• Updated list of POI devices, P2PE applications, P2PE non-payment software, and/or HSMs used in the solution
• Updated list of any dependencies included in the Delta Change (e.g., POI devices, P2PE applications, and/or HSMs) used in the solution
Modified
p. 75 → 80
• Updated list of POI devices, P2PE applications, P2PE non-payment software, and/or HSMs used in the solution
• Updated list of any dependencies included in the Delta Change (e.g., POI devices, P2PE applications, and/or HSMs) used in the solution
Modified
p. 75 → 80
• Evidence of adherence to PCI’s process for P2PE Designated Changes to Solutions 3B-1.2 Verify formal agreements established for all third parties managing SCDs on behalf of the solution provider require:
• Evidence of adherence to PCI’s process for P2PE Delta Changes 3B-1.2 Verify formal agreements established for all third parties managing SCDs on behalf of the solution provider require:
Modified
p. 76 → 81
Requirement 3C: Creation and maintenance of the P2PE Instruction Manual for merchants.
Requirement 3C: Creation and maintenance of the P2PE Instruction Manual for merchants Domain 3 Requirements Testing Procedures 3C-1 Solution provider develops, maintains, and disseminates a P2PE Instruction Manual (PIM) to merchants.
Modified
p. 76 → 81
• All P2PE applications specified in the PIM are assessed for this solution (per Domain 1)
• All P2PE applications specified in the PIM are assessed for this solution (per Domain 1).
Modified
p. 76 → 81
• All P2PE applications specified in the PIM are either PCI-listed P2PE applications or assessed to Domain 2 as part of this P2PE solution assessment 3C-1.1.f Examine the PIM to verify that all P2PE non-payment software specified in the PIM were assessed as part of this P2PE solution assessment (per Requirement 1C-2).
• All P2PE applications specified in the PIM are either PCI-listed P2PE applications or assessed to Domain 2 as part of this P2PE solution assessment.
Modified
p. 76 → 81
• The PIM instructions result in a securely installed P2PE solution.
• The PIM instructions facilitate a securely installed P2PE solution.
Modified
p. 77 → 82
Requirement 3C: Creation and maintenance of the P2PE Instruction Manual for merchants.
Requirement 3C: Creation and maintenance of the P2PE Instruction Manual for merchants Domain 3 Requirements Testing Procedures 3C-1.2 Review P2PE Instruction Manual (PIM) at least annually and upon changes to the solution or the P2PE requirements. Update PIM as needed to keep the documentation current with:
Modified
p. 77 → 82
Any changes to the P2PE solution (including additions or removals of POI device types, P2PE applications, and/or P2PE non-payment software), and Any changes to the P2PE requirements.
Modified
p. 77 → 82
Any changes to the P2PE solution (including additions or removals of POI device types, P2PE applications, and/or P2PE non-payment software), and Any changes to the P2PE requirements.
Removed
p. 78
4A Restrict access between the merchant decryption environment and all other networks/systems.
Target Audience: This Domain applies only to merchants that manage their own P2PE solutions Some merchants may choose to manage their own P2PE solution on behalf of their own merchant encryption environments rather than fully outsourcing the solution to a third-party solution provider. This type of P2PE solution is defined as a “merchant-managed solution” since the merchant is acting as its own P2PE solution provider. Domain 4 specifies the requirements that must be met for a merchant-managed solution with the objective of reducing the presence of clear-text account data within their encryption environments.
Applicability This domain (Domain 4) is only applicable to merchants acting as their own P2PE solution providers, as defined in this document. This domain is not applicable to third-party solution providers who manage P2PE solutions on behalf of merchants. Merchants acting as their own P2PE solution providers …
Target Audience: This Domain applies only to merchants that manage their own P2PE solutions Some merchants may choose to manage their own P2PE solution on behalf of their own merchant encryption environments rather than fully outsourcing the solution to a third-party solution provider. This type of P2PE solution is defined as a “merchant-managed solution” since the merchant is acting as its own P2PE solution provider. Domain 4 specifies the requirements that must be met for a merchant-managed solution with the objective of reducing the presence of clear-text account data within their encryption environments.
Applicability This domain (Domain 4) is only applicable to merchants acting as their own P2PE solution providers, as defined in this document. This domain is not applicable to third-party solution providers who manage P2PE solutions on behalf of merchants. Merchants acting as their own P2PE solution providers …
Modified
p. 78 → 83
4B Restrict traffic between the encryption environment and any other CDE.
4B Secure the decryption environment.
Modified
p. 78 → 83
4C Restrict personnel access between the encryption environment and the merchant decryption environment.
4C Monitor the decryption environment and respond to incidents.
Removed
p. 79
See the “P2PE Solutions and use of Third Parties, and/or P2PE Component Providers” section for more information about solution providers, component providers, and merchant as a solution provider.
Note: If a merchant outsources the decryption environment to a PCI-listed P2PE decryption-management component provider, Domain 4 would not apply for the merchant-managed solution, and use of a PCI-listed component provider would be noted in the merchant-as-a-solution-provider’s P2PE Report on Validation (P-ROV). If a merchant outsources the decryption environment to a non-listed decryption service provider, Domain 4 would also not apply and Domain 5 (covering the outsourced decryption services) would be assessed as part of the merchant-as-solution- provider’s P2PE assessment and included in the merchant’s P-ROV.
Satisfy all P2PE domain requirements (Domains 1, 2, 3, 5, and 6) in this standard, including this domain (Domain 4).
Note: If a merchant outsources the decryption environment to a PCI-listed P2PE decryption-management component provider, Domain 4 would not apply for the merchant-managed solution, and use of a PCI-listed component provider would be noted in the merchant-as-a-solution-provider’s P2PE Report on Validation (P-ROV). If a merchant outsources the decryption environment to a non-listed decryption service provider, Domain 4 would also not apply and Domain 5 (covering the outsourced decryption services) would be assessed as part of the merchant-as-solution- provider’s P2PE assessment and included in the merchant’s P-ROV.
Satisfy all P2PE domain requirements (Domains 1, 2, 3, 5, and 6) in this standard, including this domain (Domain 4).
Removed
p. 81
Requirement 4A: Restrict access between the merchant decryption environment and all other networks/systems Domain 4 Requirements Testing Procedures 4A-1 The merchant decryption environment must be dedicated to decryption operations.
4A-1.1 Current documentation must be maintained that describes, or illustrates, the architecture of the merchant- managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
4A-1.1.a Interview responsible personnel and review documentation to verify that procedures exist for maintaining documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
4A-1.1.b Interview responsible personnel and review merchant documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all …
4A-1.1 Current documentation must be maintained that describes, or illustrates, the architecture of the merchant- managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
4A-1.1.a Interview responsible personnel and review documentation to verify that procedures exist for maintaining documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
4A-1.1.b Interview responsible personnel and review merchant documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all …
Modified
p. 86 → 83
4A Use approved decryption devices.
Modified
p. 86 → 83
4D Implement secure, hybrid decryption processes.
Modified
p. 86 → 83
4E Component providers ONLY: report status to solution providers Target Audience: P2PE solution providers, or those who, on behalf of P2PE solution providers, manage the P2PE decryption environment.
Removed
p. 87
A Host System is defined as a combination of software and hardware components used for the purpose of decrypting account data, may also be used for transaction processing, and is not considered an SCD.
Modified
p. 87 → 83
See the “P2PE Solutions and use of Third Parties and/or P2PE Component Providers” section for more information about validating this Domain as a solution provider, a decryption-environment component provider, or as a merchant as a solution provider.
See “P2PE Solutions and use of Third Parties and/or P2PE Component Providers” for more information about validating this Domain as a solution provider, a decryption- environment component provider, or as a merchant as a solution provider.
Modified
p. 87 → 83
Hybrid decryption environments require HSMs for cryptographic key-management functions but allow for non-SCD Host Systems to be used for account data decryption. Unlike a P2PE solution with a hardware decryption environment (in which cryptographic key management and account-data decryption are performed entirely within a hardware security module, or HSM), a hybrid decryption environment (which requires HSMs for cryptographic key-management functions) allows for the decryption of account data outside of an HSM in non-SCDs on a Host System. These environments must …
Hybrid decryption environments require HSMs for cryptographic key-management functions but allow for non-SCD Host Systems to be used for account-data decryption. Unlike a P2PE solution with a hardware decryption environment (in which cryptographic key management and account-data decryption are performed entirely within a hardware security module, or HSM), a hybrid decryption environment (which requires HSMs for cryptographic key-management functions) allows for the decryption of account data outside of an HSM in non-SCDs on a Host System. These environments must meet …
Modified
p. 87 → 83
Note: All decryption devices, including HSMs and related key-management SCDs, must additionally meet all requirements specified in Domain 6.
Note: All decryption devices, including HSMs and related key-management SCDs, must additionally meet all requirements specified in Domain 5.
Modified
p. 87 → 83
Note: For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 5, and 6 of this document refers to merchant personnel in the encryption environments, and represents requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
Note: For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 4, and 5 of this document refers to merchant personnel in the encryption environments, and represents requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
Modified
p. 88 → 84
Requirement 5A: Use approved decryption devices Domain 5 Requirements Testing Procedures 5A-1 Use approved decryption devices 5A-1.1 All hardware security modules (HSMs) must be either:
Requirement 4A: Use approved decryption devices Domain 4 Requirements Testing Procedures 4A-1 Use approved decryption devices 4A-1.1 All hardware security modules (HSMs) must be either:
Modified
p. 88 → 84
• FIPS140-2 Level 3 (overall) or higher certified, or
• FIPS 140-2 or 140-3 Level 3 (overall) or higher certified, or
Modified
p. 88 → 84
• PCI PTS HSM approved.
• PCI PTS HSM approved
Modified
p. 88 → 84
4A-1.1.a For all HSMs used in the decryption environment, examine approval documentation (e.g., FIPS certification or PTS approval) and review the list of approved devices to verify that all HSMs used in the solution are either:
Modified
p. 88 → 84
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 Level 3 (overall), or higher. Refer to http://csrc.nist.gov.
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 or 140-3 Level 3 (overall), or higher. Refer to http://csrc.nist.gov.
Modified
p. 88 → 84
PCI PTS Devices under the approval class “HSM.” 5A-1.1.b Examine documented procedures and interview personnel to verify that all account-data decryption operations are performed only by the FIPS-approved and/or PTS-approved HSMs identified in 5A-1.1.a.
• Listed on the PCI SSC website, with a valid PCI SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” 4A-1.1.b Examine documented procedures and interview personnel to verify that all account-data decryption operations are performed only by the FIPS-approved and/or PTS-approved HSMs identified in 4A-1.1.a.
Modified
p. 88 → 84
4A-1.1.1 The approval listing must match the deployed devices in the following characteristics:
Modified
p. 88 → 84
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment (continued on next page) 5A-1.1.1.a For all PCI-approved HSMs used in the solution, examine HSM devices and review the PCI SSC list of Approved PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment (continued on next page) 4A-1.1.1.a For all PCI-approved HSMs used in the solution, examine HSM devices and review the PCI SSC list of Approved PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
Modified
p. 89 → 85
Requirement 5A: Use approved decryption devices Domain 5 Requirements Testing Procedures 5A-1.1.1 (continued)
Requirement 4A: Use approved decryption devices Domain 4 Requirements Testing Procedures 4A-1.1.1 (continued)
Modified
p. 89 → 85
4A-1.1.1.b For all FIPS-approved HSMs used in the solution, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS 140-2 or 140-3 Level 3 (or higher) approval listing for each HSM:
Modified
p. 89 → 85
• Firmware version number 5A-1.1.1.c If the solution provider has applied a vendor security patch that resulted in an updated HSM firmware version, and the PCI SSC or NIST validation of that updated firmware version has not yet been completed, obtain the vendor documentation and verify it includes confirmation that the update has been submitted for evaluation per the process specified by PCI SSC or NIST (as applicable to the HSM).
• Firmware version number 4A-1.1.1.c If the solution provider has applied a vendor security patch that resulted in an updated HSM firmware version, and the PCI SSC or NIST validation of that updated firmware version has not yet been completed, obtain the vendor documentation and verify it includes confirmation that the update has been submitted for evaluation per the process specified by PCI SSC or NIST (as applicable to the HSM).
Modified
p. 89 → 85
4A-1.1.2 If FIPS-approved HSMs are used, the HSM must use the FIPS-approved cryptographic primitives, data- protection mechanisms, and key-management processes for account-data decryption and related processes.
Modified
p. 89 → 85
• A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements Note that adding any software may invalidate the FIPS approval.
• Purpose and description of any non-FIPS validated software added to the HSM
• A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements • Note that adding any software may invalidate the FIPS approval.
• A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements • Note that adding any software may invalidate the FIPS approval.
Modified
p. 89 → 85
4A-1.1.2.a Examine FIPS approval documentation (security policy) and HSM operational procedures to verify that the FIPS approval covers the cryptographic primitives, data-protection mechanisms, and key-management used for account- data decryption and related processes.
Modified
p. 89 → 85
4A-1.1.2.b If the HSM is operated in non-FIPS mode or non-FIPS validated software has been added to the HSM, review the solution provider’s written confirmation and confirm that it includes the following:
Modified
p. 89 → 85
• A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements.
• A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements
Modified
p. 90 → 86
Requirement 5A: Use approved decryption devices Domain 5 Requirements Testing Procedures 5A-1.1.3 If PCI PTS-approved HSMs are used, the HSM must be configured to operate in accordance with the security policy that was included in the PTS HSM approval, for all P2PE operations (including algorithms, data protection, key management, etc.).
Requirement 4A: Use approved decryption devices Domain 4 Requirements Testing Procedures 4A-1.1.3 If PCI PTS-approved HSMs are used, the HSM must be configured to operate in accordance with the security policy that was included in the PTS HSM approval, for all P2PE operations (including algorithms, data protection, key management, etc.).
Modified
p. 90 → 86
4A-1.1.3 Examine HSM configurations for all P2PE solution functions to verify that HSMs are configured to operate according to the security policy that was included as part of the PTS approval. In addition, review the PCI approval listing(s) for any implementation-specific notes and if present, verify they are accounted for.
Removed
p. 91
5B-1.1.c Review the solution-provider documentation that describes/illustrates the configuration of the of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.
Modified
p. 91 → 87
Domain 5 Requirements Testing Procedures 5B-1 Maintain processes for securely managing the decryption environment.
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1 Maintain processes for securely managing the decryption environment.
Modified
p. 91 → 87
4B-1.1 Current documentation must be maintained that describes or illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.
Modified
p. 91 → 87
4B-1.1.a Review documentation to verify that a procedure exists to maintain a document that describes/illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.
Modified
p. 91 → 87
4B-1.1.b Interview responsible personnel and review solution-provider documentation to verify that it describes/illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.
Modified
p. 91 → 87
4B-1.2 Procedures must be implemented to provide secure administration of decryption devices by authorized personnel, including but not limited to:
Modified
p. 91 → 87
• Use of HSM commands 5B-1.2.a Examine documented procedures to verify secure administration by authorized personnel is defined for decryption devices including:
• Use of HSM commands (continued on next page) 4B-1.2.a Examine documented procedures to verify secure administration by authorized personnel is defined for decryption devices including:
Modified
p. 91 → 87
• Assigning administrative roles and responsibilities only to specific, authorized
• Assigning administrative roles and responsibilities only to specific, authorized personnel
Modified
p. 91 → 87
• Use of HSM commands 5B-1.2.b Observe authorized personnel performing device-administration operations to verify secure administration procedures are implemented for the following:
• Use of HSM commands 4B-1.2.b Observe authorized personnel performing device-administration operations to verify secure administration procedures are implemented for the following:
Modified
p. 92 → 88
Domain 5 Requirements Testing Procedures 5B-1.2.c Observe personnel performing decryption-device administration and examine files/records that assign administrative roles and responsibilities to verify that only authorized and assigned personnel perform decryption-device administration operations.
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.2 (continued) 4B-1.2.c Observe personnel performing decryption-device administration and examine files/records that assign administrative roles and responsibilities to verify that only authorized and assigned personnel perform decryption-device administration operations.
Modified
p. 92 → 88
4B-1.3 Only authorized users/processes have the ability to make function calls to the HSM•e.g., via the HSM’s application program interfaces (APIs).
Modified
p. 92 → 88
4B-1.3.a Examine documented procedures and processes to verify that only authorized users/processes have the ability to make functions calls to the HSM• e.g., via the HSM’s application program interfaces (APIs).
Modified
p. 92 → 88
4B-1.3.b Interview responsible personnel and observe HSM system configurations and processes to verify that only authorized users/processes have the ability to make function calls to the HSM (e.g., via the HSM’s application program interfaces [APIs]).
Modified
p. 92 → 88
4B-1.4 POI devices must be authenticated by the decryption environment and upon request by the solution provider.
Modified
p. 92 → 88
This authentication may occur via use of cryptographic keys or certificates, uniquely associated with each POI device and decryption system.
Modified
p. 92 → 88
4B-1.4.a Examine documented policies and procedures to verify they require POI devices be authenticated upon connection to the decryption environment and upon request by the solution provider.
Modified
p. 92 → 88
4B-1.4.b Verify documented procedures are defined for the following:
Modified
p. 92 → 88
• Procedures and/or mechanisms for authenticating POI devices upon connection to the decryption environment
• Procedures and/or mechanisms for authenticating POI devices by the decryption environment
Modified
p. 92 → 88
• Procedures and/or mechanisms for authenticating POI devices upon request by the solution provider 5B-1.4.c Interview responsible personnel and observe a sample of device authentications to verify the following:
• Procedures and/or mechanisms for authenticating POI devices upon request by the solution provider 4B-1.4.c Interview responsible personnel and observe a sample of device authentications to verify the following:
Modified
p. 92 → 88
• POI devices are authenticated upon connection to the decryption environment.
• POI devices are authenticated by the decryption environment.
Removed
p. 93
Domain 5 Requirements Testing Procedures 5B-1.5 Physical inspections of decryption devices by authorized personnel must be performed at least quarterly to detect tampering or modification of devices. Inspections to include:
Modified
p. 93 → 89
• Physically connected devices 5B-1.5.a Examine documented procedure to verify that physical inspection of devices is required at least quarterly to detect signs of tampering or modification, and that inspection procedures include:
• Physically connected devices 4B-1.5.a Examine documented procedure to verify that inspection of devices is required at least quarterly to detect signs of tampering or modification, and that inspection procedures include:
Modified
p. 93 → 89
• Physically connected devices 5B-1.5.b Interview personnel performing physical inspections and observe inspection processes to verify that inspections include:
• Physically connected devices 4B-1.5.b Interview personnel performing inspections and observe inspection processes to verify that inspections include:
Modified
p. 93 → 89
• Physically connected devices 5B-1.5.c Interview personnel performing inspections and review supporting documentation to verify that physical inspections are performed at least quarterly.
• Physically connected devices 4B-1.5.c Interview personnel performing inspections and review supporting documentation to verify that inspections are performed at least quarterly.
Modified
p. 93 → 89
4B-1.6 Decryption environment must be secured according to PCI DSS.
Modified
p. 93 → 89
4B-1.6.a Review the “Description of Scope of Work and Approach Taken” section of the solution provider’s current PCI DSS Report on Compliance (ROC) to verify the PCI DSS assessment scope fully covers the P2PE decryption environment.
Modified
p. 93 → 89
4B-1.6.b Review PCI DSS ROC and/or Attestation of Compliance (AOC) to verify that all applicable PCI DSS requirements are “in place” for the P2PE decryption environment.
Modified
p. 93 → 89
4B-1.6.c Review PCI DSS ROC and/or Attestation of Compliance (AOC) to verify that the PCI DSS assessment of the P2PE decryption environment was:
Modified
p. 93 → 90
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.7 Processes are implemented to ensure that clear- text account data is never sent back to the encryption environment.
Modified
p. 93 → 90
Note: Output of clear-text data that is verified as being unrelated to any of the PCI payment brands is acceptable. The security of this process when it occurs from the decryption environment is assessed at Requirement 5B-1.9 5B-1.7.a Review documented processes and interview personnel to confirm that clear- text account data is never sent back to the encryption environment.
Note: Output of clear-text data that is verified as being unrelated to any of the PCI payment brands is acceptable. The security of this process when it occurs from the decryption environment is assessed at Requirement 4B-1.9 4B-1.7.a Review documented processes and interview personnel to confirm that clear-text account data is never sent back to the encryption environment.
Modified
p. 93 → 90
4B-1.7.b Observe process flows and data flows to verify that there is no process, application, or other mechanism that sends clear-text account data back into the encryption environment.
Removed
p. 94
• Documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 5B-1.9 Review documented policies and procedures to verify that that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment ensures the that the ONLY allowed output of clear-text account data is for non-PCI payment brand account/card data, and includes the following:
• Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
• Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 94 → 90
4B-1.8 Any truncated PANs sent back to the encryption environment must adhere to the allowable number of digits as specified in PCI DSS and/or related FAQs that specify allowable digits.
Modified
p. 94 → 90
4B-1.8.a Review documented processes and interview personnel to confirm that any truncated PANs sent back to the encryption environment adhere to the allowable number of digits as specified in PCI DSS and/or related FAQs 4B-1.8.b Observe process flows and data flows to verify that there is no process, application, or other mechanism that sends more digits of truncated PANs back to the encryption environment than is specified in PCI DSS and/or related FAQs.
Modified
p. 94 → 91
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.9 Any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must ensure that the ONLY allowed output of clear-text account data is for non-PCI payment brand account/card data, and includes the following:
Removed
p. 95
5B-1.9.1.b Perform test transactions to verify that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows output clear-text account for non-PCI payment brand account/card data.
Modified
p. 95 → 91
4B-1.9.1.b Perform test transactions to verify that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows output clear-text account for non-PCI payment brand account/card data.
Modified
p. 95 → 91
4B-1.9.1.a Observe application and system configurations and interview personnel to verify that whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows the output of clear- text account data for non-PCI payment brand account/card data.
Modified
p. 95 → 92
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.9.2 Any new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must be:
Modified
p. 95 → 92
• Cryptographically authenticated by the HSM 5B-1.9.2 Observe the process for new installations or updates to whitelisting functionality and interview personnel to verify that additions or updates to whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment are performed as follows:
• Cryptographically authenticated by the HSM 4B-1.9.2 Observe the process for new installations or updates to whitelisting functionality and interview personnel to verify that additions or updates to whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment are performed as follows:
Modified
p. 95 → 92
• Cryptographically authenticated by the HSM 5B-1.9.3 Any new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must follow change-control procedures that include:
• Cryptographically authenticated by the HSM 4B-1.9.3 Any new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must follow change-control procedures that include:
Modified
p. 95 → 92
4B-1.9.3 Review records of both new and updated whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment, and confirm the following:
Modified
p. 96 → 93
Domain 5 Requirements Testing Procedures 5C-1 Perform logging and monitor the decryption environment for suspicious activity, and implement notification processes.
Requirement 4C: Monitor the decryption environment and respond to incidents Domain 4 Requirements Testing Procedures 4C-1 Perform logging and monitor the decryption environment for suspicious activity and implement notification processes.
Modified
p. 96 → 93
4C-1.1 Changes to the critical functions of the decryption devices must be logged. Logs must be kept for one year, at a minimum.
Modified
p. 96 → 93
4C-1.1 Examine system configurations and correlating log files to verify that any changes to the critical functions of decryption devices are logged, including:
Modified
p. 96 → 93
• Changes to any security-sensitive configurations 5C-1.2 Mechanisms must be implemented to detect and respond to suspicious activity, including but not limited to:
• Changes to any security-sensitive configurations 4C-1.2 Mechanisms must be implemented to detect and respond to suspicious activity, including but not limited to:
Modified
p. 96 → 93
• Unauthorized use of the HSM API 5C-1.2.a Examine documented procedures to verify mechanisms are defined to detect and respond to potential security incidents, including:
• Unauthorized use of the HSM API 4C-1.2.a Examine documented procedures to verify mechanisms are defined to detect and respond to potential security incidents, including:
Modified
p. 96 → 93
• Unauthorized use of the HSM API 5C-1.2.b Interview personnel and observe implemented mechanisms to verify mechanisms are implemented to detect and respond to suspicious activity, including:
• Unauthorized use of the HSM API 4C-1.2.b Interview personnel and observe implemented mechanisms to verify mechanisms are implemented to detect and respond to suspicious activity, including:
Modified
p. 96 → 93
• Unauthorized use of sensitive functions (e.g., key management functions)
• Unauthorized use of sensitive functions (e.g., key-management functions)
Removed
p. 97
5C-1.3.3 Detecting and reviewing any unexpected transaction data received.
Modified
p. 97 → 94
Domain 5 Requirements Testing Procedures 5C-1.3 Mechanisms must be implemented to detect encryption failures, including at least the following:
Requirement 4C: Monitor the decryption environment and respond to incidents Domain 4 Requirements Testing Procedures 4C-1.3 Mechanisms must be implemented to detect encryption failures, including at least the following:
Modified
p. 97 → 94
Note: Although Domain 5 is concerned with the decryption environment, not the encryption environment, all traffic received into the decryption environment must be actively monitored to confirm that the POI devices in the merchant’s encryption environment is not outputting clear-text account data through some error or misconfiguration.
Note: Although Domain 4 is concerned with the decryption environment, not the encryption environment, all traffic received into the decryption environment must be actively monitored to confirm that the POI devices in the merchant’s encryption environment is not outputting clear-text account data through some error or misconfiguration.
Modified
p. 97 → 94
4C-1.3 Examine documented procedures to verify controls are defined for the following:
Modified
p. 97 → 94
• Procedures are defined to detect encryption failures, and include 5C-1.3.1 through 5C-1.3.4 below.
• Procedures are defined to detect encryption failures, and include 4C-1.3.1 through 4C-1.3.4 below.
Modified
p. 97 → 94
• Procedures include immediate notification upon detection of a cryptographic failure, for each 5C-1.3.1 through 5C-1.3.4 below.
• Procedures include immediate notification upon detection of a cryptographic failure, for each 4C-1.3.1 through 4C-1.3.4 below.
Modified
p. 97 → 94
4C-1.3.1.a Observe implemented processes to verify controls are in place to check for incoming clear-text account data.
Modified
p. 97 → 94
4C-1.3.1.b Observe implemented controls and notification mechanisms to verify mechanisms detect and provide immediate notification upon detection of incoming clear-text account data.
Modified
p. 97 → 94
4C-1.3.1.c Interview personnel to verify that designated personnel are immediately notified upon detection of incoming clear-text account data.
Modified
p. 97 → 94
4C-1.3.2 Detecting and reviewing any cryptographic errors reported by the HSM 4C-1.3.2.a Observe implemented processes to verify controls are in place to detect and review any cryptographic errors reported by the HSM.
Modified
p. 97 → 94
4C-1.3.2.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification of cryptographic errors reported by the HSM.
Modified
p. 97 → 94
4C-1.3.2.c Interview personnel to verify that designated personnel are immediately notified upon detection of cryptographic errors reported by the HSM.
Modified
p. 97 → 95
Requirement 5C: Monitor the decryption environment and respond to incidents.
Requirement 4C: Monitor the decryption environment and respond to incidents Domain 4 Requirements Testing Procedures 4C-1.3.3 Detecting and reviewing any unexpected transaction data received.
Modified
p. 97 → 95
4C-1.3.3.a Observe implemented processes to verify controls are in place to detect and review any unexpected transaction data received.
Modified
p. 97 → 95
4C-1.3.3.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification for any unexpected transaction data received.
Modified
p. 97 → 95
4C-1.3.3.c Interview personnel to verify that designated personnel are immediately notified upon detection of any unexpected transaction data received.
Modified
p. 98 → 95
4C-1.3.4 Reviewing data sent by any POI devices that are causing an unusually high rate of transaction authorization rejections.
Modified
p. 98 → 95
4C-1.3.4.a Observe implemented processes to verify controls are in place to review data sent by any POI devices that are causing an unusually high rate of transaction authorization rejections.
Modified
p. 98 → 95
4C-1.3.4.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.
Modified
p. 98 → 95
4C-1.3.4.c Interview personnel to verify that designated personnel are immediately notified upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.
Modified
p. 98 → 96
Requirement 4C: Monitor the decryption environment and respond to incidents Domain 4 Requirements Testing Procedures 4C-1.4 All suspicious activity must be identified and a record maintained for one year, at a minimum, to include at least the following:
Modified
p. 98 → 96
• Details of whether any account data was transmitted from the POI device during any identified time that encryption was malfunctioning or disabled 5C-1.4.a Examine documented procedures to verify they include procedures for identifying the source and maintaining a record, of all suspicious activity, to include at least the following:
• Details of whether any account data was transmitted from the POI device during any identified time that encryption was malfunctioning or disabled 4C-1.4.a Examine documented procedures to verify they include procedures for identifying the source and maintaining a record, of all suspicious activity, to include at least the following:
Modified
p. 98 → 96
• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled 5C-1.4.b Observe implemented controls and interview responsible personnel to verify that the source of any suspicious activity is identified, and records are maintained to include the following:
• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled 4C-1.4.b Observe implemented controls and interview responsible personnel to verify that the source of any suspicious activity is identified, and records are maintained to include the following:
Modified
p. 98 → 96
• Identification of affected merchant, including specific sites/locations if applicable
• Identification of affected merchant and specific sites/locations if applicable
Removed
p. 99
5C-1.5.b Interview personnel and observe implemented mechanisms to verify that immediate notification of suspicious activity is provided to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers).
Modified
p. 99 → 96
4C-1.5.a Examine documented procedures to verify mechanisms are defined to provide immediate notification of suspicious activity to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers).
Modified
p. 99 → 96
4C-1.5.b Interview personnel and observe implemented mechanisms to verify that immediate notification of suspicious activity is provided to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers).
Removed
p. 101
Domain 5 Requirements Testing Procedures 5D-1 Configure the Host System securely.
Modified
p. 101 → 98
Requirement 5D: Implement secure hybrid decryption process
•Not applicable for merchant-managed solutions.
•
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1 Configure the Host System securely.
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1 Configure the Host System securely.
Modified
p. 101 → 98
4D-1.1 The solution provider must maintain current documentation that describes, or illustrates, the configuration of the Host System, including the flow of data and interconnectivity between all systems within the decryption environment.
Modified
p. 101 → 98
4D-1.1.a Interview responsible personnel and review documentation to verify that a procedure exists to maintain a document that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems within the decryption environment.
Modified
p. 101 → 98
4D-1.1.b Interview responsible personnel and review solution provider documentation that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems within that environment, to verify that the document is current.
Modified
p. 101 → 98
4D-1.1.c Review the solution provider documentation that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems, to verify that it accurately represents the decryption environment.
Modified
p. 101 → 98
4D-1.2 The Host System must be isolated, or dedicated, to processing payment transactions with only necessary services, protocols, daemons etc. enabled:
Modified
p. 101 → 98
• Functions not related to transaction processing must be disabled, or isolated (e.g., using logical partitions), from transaction processing.
• Functions not related to transaction processing must be disabled, or isolated (e.g., using logical partitions), from transaction processing
Modified
p. 101 → 98
4D-1.2.a Inspect network and system configuration settings to verify the host processing system is isolated, or dedicated, to processing payment transactions, with only necessary services, protocols, daemons etc. enabled.
Modified
p. 101 → 98
4D-1.2.b Review the documented record of services, protocols, daemons etc. that are required by the Host System and verify that each service includes justification and a description of the enabled security feature.
Modified
p. 101 → 99
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.3 The Host System and HSM must reside on a network that is dedicated to decryption operations and transaction processing and must be segmented from any other network, or system, that is not performing or supporting decryption operations or transaction processing.
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.3 The Host System and HSM must reside on a network that is dedicated to decryption operations and transaction processing and must be segmented from any other network, or system, that is not performing or supporting decryption operations or transaction processing.
Modified
p. 101 → 99
4D-1.3.a Examine network diagrams to verify the Host System(s) and HSM(s) are located on a network that is segmented from other networks that are not required for decryption operations or transaction processing.
Modified
p. 101 → 99
4D-1.3.b Inspect network and system configurations to verify the Host System(s) and HSM(s) are located on a network that is segmented from other networks not required for decryption operations or transaction processing.
Removed
p. 102
5D-1.6.b Review logs/audit trails from when the Host System has previously been powered-up and interview personnel, to verify that the Host System performs a self-test to ensure its integrity before use. Verify the self-tests included the tests described in 5D- 1.6.a.
Modified
p. 102 → 99
4D-1.4 All application software installed on the Host System must be authorized and have a business justification.
Modified
p. 102 → 99
4D-1.4.a Examine documented policies and procedures to verify that all application software installed on the Host System must have a business justification and be duly authorized.
Modified
p. 102 → 99
4D-1.4.b Examine change-control and system-configuration records to verify that all application software installed on the Host System is authorized.
Modified
p. 102 → 99
4D-1.4.c Inspect Host System and compare with system configuration standards to verify that all software installed on the Host System has a defined business justification.
Modified
p. 102 → 99
4D-1.5 A process, either automated or manual, must be in place to prevent and/or detect and alert, any unauthorized changes to applications/software on the Host System.
Modified
p. 102 → 99
4D-1.5.a Examine documented policies and procedures to verify that a process is defined to prevent and/or detect and alert, any unauthorized changes to applications/software.
Modified
p. 102 → 99
4D-1.5.b Interview personnel and observe system configurations to verify that controls are implemented to prevent and/or detect and alert personnel, upon any unauthorized changes to applications/software.
Modified
p. 102 → 99
4D-1.5.c Examine output from the implemented process to verify that any unauthorized changes to applications/software are either prevented or detected with an alert generated that is immediately investigated.
Modified
p. 102 → 100
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.6 The Host System must perform a self-test when it is powered up to ensure its integrity before use. The self-test must include:
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.6 The Host System must perform a self-test when it is powered up to ensure its integrity before use. The self-test must include:
Modified
p. 102 → 100
• Testing integrity of cryptographic functions.
• Testing integrity of cryptographic functions
Modified
p. 102 → 100
• Testing integrity of cryptographic functions.
• Testing integrity of cryptographic functions
Modified
p. 102 → 100
• Testing integrity of firmware.
• Testing integrity of firmware
Modified
p. 102 → 100
• Testing integrity of any security functions critical to the secure operation of the Host System.
• Testing integrity of any security functions critical to the secure operation of the Host System 4D-1.6.a Inspect Host System configuration settings, and examine vendor/solution provider documentation to verify that the Host System performs a self-test when it is powered up to ensure its integrity before use. Verify the self-test includes the following:
Modified
p. 102 → 100
4D-1.7.a Inspect Host System configuration settings and examine vendor/solution provider documentation to verify that the Host System performs a self-test when a security-impacting function or operation is modified.
Modified
p. 102 → 100
• Testing integrity of software/firmware.
• Testing integrity of software/firmware
Modified
p. 102 → 100
• Testing integrity of any security functions critical to the secure operation of the Host System.
• Testing integrity of any security functions critical to the secure operation of the Host System 4D-1.6.b Review logs/audit trails from when the Host System has previously been powered-up and interview personnel, to verify that the Host System performs a self- test to ensure its integrity before use. Verify the self-tests included the tests described in 4D-1.6.a.
Removed
p. 103
5D-1.7.a Inspect Host System configuration settings and examine vendor/solution provider documentation to verify that the Host system performs a self-test when a security- impacting function or operation is modified.
5D-1.9.a Review documented procedures to verify alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.
5D-1.9.a Review documented procedures to verify alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.
Modified
p. 103 → 100
4D-1.7 The Host System must perform a self-test when a security-impacting function or operation is modified (e.g., an integrity check of the software/firmware must be performed upon loading of a software/firmware update).
Modified
p. 103 → 100
4D-1.7.b Interview personnel and examine logs/records for when a security-impacting function, or operation, has been modified to verify that the Host System performs a self-test.
Modified
p. 103 → 100
4D-1.8 The Host System must enter an error state and generate an alert upon any of the following events:
Modified
p. 103 → 100
4D-1.8.a Inspect Host System configuration settings and examine vendor/solution provider documentation to verify that the host enters an error state and generates an alert in the event of the following:
Modified
p. 103 → 100
• Failure of a security function or mechanism 5D-1.8.b Interview personnel and examine logs/records of actual or test alerts to verify that alerts are generated and received when the Host System enters an error state under one of the following conditions:
• Failure of a security function or mechanism 4D-1.8.b Interview personnel and examine logs/records of actual or test alerts to verify that alerts are generated and received when the Host System enters an error state under one of the following conditions:
Modified
p. 103 → 101
4D-1.9.a Review documented procedures to verify alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.
Modified
p. 103 → 101
4D-1.9.b Examine system configurations and records of documented alert events to verify alerts generated from the Host System are documented.
Modified
p. 103 → 101
4D-1.9.c Examine a sample of documented alert events and interview personnel assigned with security-response duties to verify alerts initiate a response procedure.
Modified
p. 104 → 101
4D-1.10 The Host System must not perform any cryptographic operations under any of the following conditions:
Modified
p. 104 → 101
• While in an error state, as described in Requirement
• While in an error state, as described in Requirement 4D-1.8
Modified
p. 104 → 101
• During self-tests, as described in Requirements 5D- 1.6 and 5D-1.7
• During self-tests, as described in Requirements 4D-1.6 and 4D-1.7
Modified
p. 104 → 101
• During diagnostics of cryptographic operations 4D-1.10.a Examine documented procedures to verify that controls/processes are in place to ensure that the Host System does not perform any cryptographic operations:
Modified
p. 104 → 101
• While in an error state, as described in Requirement 5D-1.8
• While in an error state, as described in Requirement 4D-1.8
Modified
p. 104 → 101
• While in an error state, as described in Requirement 5D-1.8
• While in an error state, as described in Requirement 4D-1.8
Modified
p. 104 → 101
• During self-tests, as described in Requirements 5D-1.6 and 5D-1.7.
• During self-tests, as described in Requirements 4D-1.6 and 4D-1.7
Modified
p. 104 → 101
• During self-tests, as described in Requirements 5D-1.6 and 5D-1.7.
• During self-tests, as described in Requirements 4D-1.6 and 4D-1.7
Modified
p. 104 → 101
• During diagnostics of cryptographic operations 4D-1.10.b Inspect Host System configuration settings and interview personnel to verify that controls and/or procedures are in place to ensure that the Host System does not perform any cryptographic operations:
Modified
p. 104 → 101
• During diagnostics of cryptographic operations 4D-1.11 All source code and executable code for cryptographic software and firmware on the Host System must be protected from unauthorized disclosure and unauthorized modification.
Modified
p. 104 → 101
4D-1.11.a Inspect configuration documentation to verify that access controls are defined to ensure all source code and executable code for cryptographic software and firmware is protected from unauthorized disclosure and unauthorized modification.
Modified
p. 104 → 101
4D-1.11.b Observe access controls for cryptographic software and firmware to verify that all source code and executable code is protected from unauthorized disclosure and unauthorized modification.
Modified
p. 104 → 101
4D-1.12 The clear-text data-decryption keys must not be accessible to any processes or functions not directly required for decryption operations.
Modified
p. 104 → 101
4D-1.12.a Review solution provider documentation, including data-flow diagrams, to verify that clear-text decryption keys are not accessible to any processes or functions not directly required for decryption operations.
Modified
p. 104 → 102
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.12.b Inspect Host System configurations and access controls and to verify that clear-text decryption keys are not accessible to any processes or functions not directly required for decryption operations.
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.12.b Inspect Host System configurations and access controls and to verify that clear-text decryption keys are not accessible to any processes or functions not directly required for decryption operations.
Modified
p. 104 → 102
4D-1.13 The clear-text data-decryption keys must only be accessible to authorized personnel with a defined job- related need to access the keys 4D-1.13.a Examine documented key-management policies and procedures to verify clear-text data-decryption keys must only be accessible to authorized personnel with a defined job-related need to access the keys.
Modified
p. 104 → 102
4D-1.13.b Inspect Host System configuration settings and verify that clear-text data- decryption keys are only accessible to authorized personnel with a defined job-related need to access the keys.
Removed
p. 105
• Core dumps’ of memory required for trouble-shooting.
• ‘Core dumps’ of memory required for trouble-shooting.
5D-1.14.3 The swap/page files and/or core dumps must never be backed up or copied.
• ‘Core dumps’ of memory required for trouble-shooting.
5D-1.14.3 The swap/page files and/or core dumps must never be backed up or copied.
Modified
p. 105 → 102
4D-1.14 The Host System must not write clear-text cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:
Modified
p. 105 → 102
• Memory ‘swap/page’ file purposes.
• Memory swap/page file purposes
Modified
p. 105 → 102
• Memory ‘swap/page’ file purposes.
• Memory swap/page file purposes
Modified
p. 105 → 102
• ‘Core dumps’ of memory required for troubleshooting.
• “Core dumps” of memory required for troubleshooting In the above circumstances, the following conditions apply:
Modified
p. 105 → 102
4D-1.14.a Examine documented configuration procedures to verify that the Host System must not write clear-text cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:
Modified
p. 105 → 102
• Core dumps of memory required for trouble-shooting 4D-1.14.b Examine Host System configuration settings and interview personnel to verify that clear-text cryptographic keys are not written to persistent storage except in the following circumstances:
Modified
p. 105 → 102
• Memory ‘swap/page’ file purposes.
• Memory “swap/page” file purposes
Modified
p. 105 → 102
• Core dumps of memory required for trouble-shooting 4D-1.14.c Verify documented procedures include Requirements 4D-1.14.1 through 4D- 1.14.5 below.
Modified
p. 105 → 102
4D-1.14.1 The locations must be predefined and documented.
Modified
p. 105 → 102
4D-1.14.1.a Review Host System configuration standards to verify that storage locations of any swap/page files and core dumps are defined.
Modified
p. 105 → 102
4D-1.14.1.b Examine Host System configuration settings to verify that the Host System only outputs swap/page files and core dumps to the documented storage locations.
Modified
p. 105 → 102
4D-1.14.2 Storage can only be made to a dedicated hard drive (on its own bus) within the host.
Modified
p. 105 → 102
4D-1.14.2 Examine Host System configuration settings and storage locations to verify that swap/page files and core dumps are written to a dedicated hard drive on its own bus on the Host System.
Modified
p. 105 → 103
4D-1.14.3.a Examine backup configuration settings for the Host System and storage locations to verify that swap/page files and core dumps are not backed up.
Modified
p. 105 → 103
4D-1.14.3.b Examine the configurations of storage locations to verify that swap/page files and core dumps cannot be copied off the storage locations.
Modified
p. 105 → 103
4D-1.14.4 Access to, and the use of, any tools used for trouble-shooting or forensics must be controlled and authorized by management.
Modified
p. 105 → 103
4D-1.14.4.a Examine documented procedures to verify that controls are defined to ensure that the access to, and use of, any tools used for trouble-shooting or forensics, are controlled and authorized by management.
Modified
p. 105 → 103
4D-1.14.4.b Observe the process for accessing the tools used for trouble-shooting or forensics, and verify that they are controlled and authorized by management in accordance with the documented procedure.
Removed
p. 106
5D-2 Access controls for the Host System are configured securely.
Modified
p. 106 → 103
4D-1.14.4.c Observe the process for using the tools used for trouble-shooting or forensics, and verify that they are controlled and authorized by management in accordance with the documented procedure.
Modified
p. 106 → 103
4D-1.14.5 All files must be securely deleted in accordance with industry-accepted standards for secure deletion of data:
Modified
p. 106 → 103
• Memory ‘swap/page’ files must be securely deleted upon system shut down or reset.
• Memory swap/page files must be securely deleted upon system shut down or reset.
Modified
p. 106 → 103
• Memory ‘swap/page’ files must be securely deleted upon system shut down or reset.
• Memory swap/page files must be securely deleted upon system shut down or reset.
Modified
p. 106 → 103
4D-1.14.5.a Review documented procedures to verify that it defines a process for securely deleting swap/page files and core dumps at the required times:
Modified
p. 106 → 103
4D-1.14.5.b Verify, through the use of forensic tools and/or methods, that the secure procedure removes swap/page files and core dumps, in accordance with industry- accepted standards for secure deletion of data.
Modified
p. 106 → 104
4D-2.1 Host user passwords must be changed at least every 30 days.
Modified
p. 106 → 104
4D-2.1.a Examine documented policies and procedures to verify that the Host System (s) user passwords must be changed at least every 30 days.
Modified
p. 106 → 104
4D-2.1.b Inspect Host System configuration settings to verify that user password parameters are set to require users to change passwords at least every 30 days.
Modified
p. 106 → 104
4D-2.2 User passwords must meet the following:
Modified
p. 106 → 104
4D-2.2.a Examine documented policies and procedures to verify that user passwords must:
Modified
p. 106 → 104
4D-2.2.b Inspect Host System (s) configuration settings to verify that user passwords:
Removed
p. 107
• auditing of host functions.
Modified
p. 107 → 104
4D-2.3 Where log-on security tokens (e.g., smart cards) are used to access the Host System, the security tokens must have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage. The PIN or password/passphrase must be at least ten alphanumeric characters in length, or equivalent.
Modified
p. 107 → 104
4D-2.3.a If log-on security tokens are used, observe the security tokens in use to verify that they have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage.
Modified
p. 107 → 104
4D-2.3.b Examine token-configuration settings to verify parameters are set to require that PINs or password/passphrases be at least ten alphanumeric characters in length, or equivalent.
Modified
p. 107 → 104
4D-2.4 User accounts must be locked out of the Host System after not more than five failed attempts.
Modified
p. 107 → 104
4D-2.4.a Examine documented policies and procedures to verify that authentication parameters on the Host System must be set to require that a user’s account be locked out after not more than five invalid logon attempts.
Modified
p. 107 → 104
4D-2.4.b Inspect Host System configuration settings to verify that authentication parameters are set to require that a user’s account be locked out after not more than five invalid logon attempts.
Modified
p. 107 → 105
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-2.5 The Host System must enforce role-based access control to include, at a minimum, the following roles:
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-2.5 The Host System must enforce role-based access control to include, at a minimum, the following roles:
Modified
p. 107 → 105
• for day-to-day non- sensitive operations of the Host System.
• for day-to-day non- sensitive operations of the Host System
Modified
p. 107 → 105
• auditing of host functions 5D-2.5.a Examine documented access-control procedures to verify they define, as a minimum, the following roles:
• auditing of host functions 4D-2.5.a Examine documented access-control procedures to verify they define, as a minimum, the following roles:
Modified
p. 107 → 105
• configuration of cryptographic management
• configuration of cryptographic management functions
Modified
p. 107 → 105
• configuration of cryptographic management
• configuration of cryptographic management functions
Modified
p. 107 → 105
• auditing of host functions 5D-2.5.b Inspect the Host System configuration settings to verify that role-based access control is enforced and, at a minimum, the following roles are defined:
• auditing of host functions 4D-2.5.b Inspect the Host System configuration settings to verify that role-based access control is enforced and the following roles, at a minimum, are defined:
Modified
p. 107 → 105
• for day-to-day non-sensitive operations of the Host System.
• for day-to-day non-sensitive operations of the Host System
Removed
p. 108
5D-2.6.2.b Interview and observe a Host System administrator to verify they use their operator-level account when performing non-administrative functions.
5D-2.7.a Examine documented policies and procedures to verify that changes to a user’s access privileges are managed:
5D-2.7.a Examine documented policies and procedures to verify that changes to a user’s access privileges are managed:
Modified
p. 108 → 105
• auditing of host functions 4D-2.5.c Interview a sample of users for each role to verify the assigned role is appropriate for their job function.
Modified
p. 108 → 105
4D-2.6 The segregation of duties must be enforced between roles, through automated or manual processes, to ensure that no one person is able to control end-to- end processes; or be in a position to compromise the security of the Host System.
Modified
p. 108 → 105
4D-2.6.1 A Host System user must not be permitted to audit their own activity on the Host System.
Modified
p. 108 → 105
4D-2.6.1.a Examine documented procedures to verify that a Host System user is not permitted to audit their own activity on the Host System.
Modified
p. 108 → 105
4D-2.6.1.b Interview audit personnel to verify that a Host System user is not permitted to audit their own activity on the Host System.
Modified
p. 108 → 106
4D-2.6.2.b Interview and observe a Host System administrator to verify they use their operator-level account when performing non-administrative functions.
Modified
p. 108 → 106
4D-2.6.2.a Review documented policies and procedures to verify a Host System administrator is not permitted to use their administrative-level account when performing non-administrative functions.
Modified
p. 108 → 106
4D-2.7 Changes to a Host System user’s account access privileges must be managed:
Modified
p. 108 → 106
4D-2.7.a Examine documented policies and procedures to verify that changes to a user’s access privileges are managed:
Modified
p. 109 → 106
4D-2.7.c Inspect the Host System configuration settings and, for a sample of user accounts, verify that any changes to their access privileges have been formally documented in the audit log.
Modified
p. 109 → 106
4D-2.8 All physical and logical access privileges must be reviewed at least quarterly to ensure that personnel with access to the decryption environment, the Host System and Host System software require that access for their position and job function.
Modified
p. 109 → 106
4D-2.8.a Examine documented policies and procedures to verify that access privileges are reviewed, as a minimum, on a quarterly basis to ensure that the access privileges for personnel authorized to access the decryption environment, the Host System and Host System software required by their position and job function, are correctly assigned.
Modified
p. 109 → 106
4D-2.8.b Examine records and interview personnel to verify that access privileges are reviewed, as a minimum, on a quarterly basis.
Modified
p. 109 → 107
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-2.9 Tamper detection mechanisms must be implemented on the host, to include an alert generation upon opening of the Host System case, covers and/or doors.
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-2.9 Tamper detection mechanisms must be implemented on the host, to include an alert generation upon opening of the Host System case, covers and/or doors.
Modified
p. 109 → 107
4D-2.9.a Review Host System documentation to verify that tamper detection mechanisms are defined for the Host System, including the generation of an alert upon opening of the Host System case, covers and/or doors.
Modified
p. 109 → 107
4D-2.9.b Observe tamper-detection mechanisms on the Host System to verify that a tamper detection mechanism is implemented and includes the generation of an alert upon opening of the Host System case, covers and/or doors.
Modified
p. 109 → 107
4D-2.9.c Review records of alerts and interview personnel to verify an alert is generated upon opening of the Host System, covers and/or doors.
Modified
p. 109 → 107
4D-3 Non-console access to the Host System is configured securely.
Modified
p. 109 → 107
4D-3.1 All non-console access to the Host System must use strong cryptography and security protocols 4D-3.1.a For a sample of systems that are authorized to connect to the Host System via a non-console connection, inspect configuration settings to verify that access to the Host System is provided through the use of strong cryptography and security protocols 4D-3.1.b Inspect the configuration settings of system components to verify that all traffic transmitted over the secure channel uses strong cryptography.
Modified
p. 109 → 107
4D-3.2 Non-console access to the Host System must not provide access to any other service, or channel, outside of that used to connect to the Host, e.g., “split tunneling.” 4D-3.2.a Inspect the configuration settings of the secure channel, to verify that split tunneling is prohibited.
Modified
p. 109 → 107
4D-3.2.b Observe a Host System administrator log on to the device which provides non-console access to the Host System to verify that split tunneling is prohibited.
Removed
p. 110
5D-3.5 Non-console access to the Host System must only be permitted from a PCI DSS compliant environment.
5D-3.5.2. Review solution provider documentation, including PCI DSS ROC and/or Attestation of Compliance (AOC), data flow diagrams, policies and, system configuration standards, to verify that the network/system that facilitates non-console access to the Host System must:
• Originate from and be managed by the solution provider.
• Meet all applicable PCI DSS requirements.
5D-3.5.2. Review solution provider documentation, including PCI DSS ROC and/or Attestation of Compliance (AOC), data flow diagrams, policies and, system configuration standards, to verify that the network/system that facilitates non-console access to the Host System must:
• Originate from and be managed by the solution provider.
• Meet all applicable PCI DSS requirements.
Modified
p. 110 → 107
4D-3.3 All non-console access to the Host System must use multi-factor authentication.
Modified
p. 110 → 107
4D-3.3.a Inspect the configuration settings of the Host System and/or the device permitted to connect to the Host System, to verify that multi-factor authentication is required for non-console access to the Host System.
Modified
p. 110 → 107
4D-3.3.b Observe a Host System administrator log on to the device that provides non- console access to the Host System to verify that multi-factor authentication is required.
Modified
p. 110 → 108
4D-3.5 Non-console access to the Host System must only be permitted directly from within a PCI DSS compliant environment.
Modified
p. 110 → 108
4D-3.4.a Examine documented policies and procedures to verify that a process is defined to authorize systems for non-console access, and not permit access until such times that authorization has been granted.
Modified
p. 110 → 108
4D-3.4.b For a sample of systems, examine device configurations to verify that non- console access is permitted only from the authorized systems.
Modified
p. 110 → 108
4D-3.5 Verify that non-console access to the Host System is only permitted from a PCI DSS compliant environment, including 4D-3.5.1 through 4D-3.5.2 Review solution provider documentation, including data-flow diagrams, and perform the following:
Modified
p. 110 → 108
4D-3.5.1 The authorized system (e.g., workstation) from which non-console access originates must meet all applicable PCI DSS requirements. For example, system hardening, patching, anti-virus protection, a local firewall etc.
Modified
p. 110 → 108
4D-3.5.1 Review solution provider documentation, including PCI DSS ROC and/or Attestation of Compliance (AOC), data-flow diagrams, policies and, system configuration standards, to verify that the system authorized for non-console access meets all applicable PCI DSS requirements.
Modified
p. 110 → 108
4D-3.5.2 The network/system that facilitates non- console access to the Host System must:
Modified
p. 110 → 108
4D-3.6 Users with access to non-console connections to the Host System must be authorized to use non-console connections.
Modified
p. 110 → 108
4D-3.6.a Examine documented policies and procedures to verify that non-console access to the Host System must only be provided to authorized users.
Modified
p. 110 → 108
4D-3.6.b Examine a sample of access-control records and compare them to Host System settings to verify that non-console access to the Host System is only provided to authorized users.
Removed
p. 111
5D-4 The physical environment of the Host System is secured.
Note: When Host Systems are located within a secure rack in a shared data center, where “secure room” is referred to in this section, these controls can be met at room level, rack level, or a combination of both. Whichever way the requirements are applied, they should ensure that access the Host System is appropriately secured, whether in a secure room or a secure rack. For example, access to systems in a rack should be limited to those with a direct need to access that rack.
Note: When Host Systems are located within a secure rack in a shared data center, where “secure room” is referred to in this section, these controls can be met at room level, rack level, or a combination of both. Whichever way the requirements are applied, they should ensure that access the Host System is appropriately secured, whether in a secure room or a secure rack. For example, access to systems in a rack should be limited to those with a direct need to access that rack.
Modified
p. 111 → 108
4D-3.7 Non-console sessions to the Host System must be terminated by the Host after 15 minutes of inactivity.
Modified
p. 111 → 108
4D-3.7.a Review documented policies and procedures to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.
Modified
p. 111 → 108
4D-3.7.b Inspect the system configuration settings to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.
Modified
p. 111 → 109
4D-4.1 The Host System must be located within a physically secure room that is dedicated to decryption operations and transaction processing.
Modified
p. 111 → 109
4D-4.1 Observe the physically secure room where the Host System is located and interview personnel to verify that all systems therein are designated to decryption operations and transaction processing.
Modified
p. 111 → 109
4D-4.2 All individuals must be identified and authenticated before being granted access to the secure room•e.g., badge-control system, biometrics.
Modified
p. 111 → 109
4D-4.2.a Examine documented policies and procedures to verify that all individuals must be identified and authenticated before being granted access to the secure room.
Modified
p. 111 → 109
4D-4.2.b Examine physical access controls to verify that all individuals are identified and authenticated before being granted access to the secure room.
Modified
p. 111 → 109
4D-4.2.c Observe authorized personnel entering the secure room to verify that all individuals are identified and authenticated before being granted access.
Modified
p. 112 → 109
4D-4.3 All physical access to the secure room must be monitored and logs must be maintained as follows:
Modified
p. 112 → 109
− Logs of access to the room from a badge access system − Logs of access to the room from a manual sign-in sheet (continued on next page) 4D-4.3.a Examine documented policies and procedures to verify all physical access to the secure room must be monitored and logs must be maintained. Policies and procedures must require the following:
Modified
p. 112 → 109
− Access to the room from a badge access system − Access to the room from a manual sign-in sheet
Modified
p. 112 → 110
− Access to the room from a badge access system − Access to the room from a manual sign-in sheet 4D-4.3.c Interview personnel responsible for reviewing logs used to record physical access to the secure room, to verify the following:
Modified
p. 112 → 110
4D-4.4 Dual access must be required for the secure room housing the Host System.
Modified
p. 112 → 110
4D-4.4.a Inspect physical access controls to verify that dual access is enforced.
Modified
p. 112 → 110
4D-4.4.b Observe authorized personnel entering the secure room to verify that dual access is enforced.
Modified
p. 112 → 110
4D-4.5 Physical access must be only permitted to designated personnel with defined business needs and duties.
Modified
p. 112 → 110
4D-4.5.a Examine documented policies and procedures to verify that physical access to the secure room is only permitted to designated personnel with defined business needs and duties.
Modified
p. 113 → 110
4D-4.5.b Examine the list of designated personnel and interview responsible personnel to verify that only personnel with defined business needs and duties are permitted access to the secure room.
Modified
p. 113 → 110
4D-4.5.c Examine physical access controls to verify that physical access to the secure room is only permitted to pre-designated personnel with defined business needs and duties.
Modified
p. 113 → 111
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.6 The secure room must be monitored via CCTV on a 24-hour basis. This must include, as a minimum, the following areas:
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.6 The secure room must be monitored via CCTV on a 24-hour basis. This must include, as a minimum, the following areas:
Modified
p. 113 → 111
4D-4.6.a Inspect CCTV configuration and review a sample of recordings to verify that CCTV monitoring is in place on a 24-hour basis, and covers, as a minimum, the following areas:
Modified
p. 113 → 111
• Access to the Host System and HSM(s) 5D-4.6.b If CCTV is motion-activated, observe system configurations for the motion- activated systems to verify they are separate from the intrusion-detection system.
• Access to the Host System and HSM(s) 4D-4.6.b If CCTV is motion-activated, observe system configurations for the motion- activated systems to verify they are separate from the intrusion-detection system.
Modified
p. 113 → 111
4D-4.7 Surveillance cameras must not be configured to allow the monitoring of computer screens, keyboards, PIN pads, or other systems which may expose sensitive data.
Modified
p. 113 → 111
4D-4.7 Observe CCTV camera positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any computer screens, PIN pads, keyboards, or other systems which may expose sensitive data.
Modified
p. 113 → 111
4D-4.8 CCTV recorded images must be securely archived for at least 45 days.
Modified
p. 113 → 111
4D-4.8.a Examine a sample of recordings to verify that at least the most recent 45 days of images are securely archived.
Modified
p. 113 → 111
4D-4.8.b If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
Modified
p. 113 → 111
4D-4.9 Personnel with access to the secure room must not have access to the media (e.g., VCR tapes, digital recording systems, etc.) with the recorded surveillance data.
Modified
p. 113 → 111
4D-4.9.a Examine documented access policies and procedures to verify that personnel with access to the secure room are not permitted to have access to the media containing recorded surveillance data for that environment.
Removed
p. 114
Domain 5 Requirements Testing Procedures 5D-4.10 Continuous or motion-activated, appropriate lighting must be provided for the cameras.
Modified
p. 114 → 111
4D-4.10.a Observe the secure room to verify that continuous or motion-activated lighting is provided for the cameras monitoring the secure room.
Modified
p. 114 → 111
4D-4.10.b Examine a sample of recorded CCTV images to verify that appropriate lighting is provided when persons are present in the secure room.
Modified
p. 114 → 112
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.11 A 24/7 physical intrusion-detection system must be in place for the secure room (e.g., motion detectors when unoccupied). This must be connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.11 A 24/7 physical intrusion-detection system must be in place for the secure room (e.g., motion detectors when unoccupied). This must be connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
Modified
p. 114 → 112
4D-4.11.a Examine security policies and procedures to verify they require:
Modified
p. 114 → 112
• Continuous (24/7) physical intrusion-detection monitoring of the secure room.
• Continuous (24/7) physical intrusion-detection monitoring of the secure room
Modified
p. 114 → 112
4D-4.11.b Observe the physical intrusion-detection system to verify that it:
Modified
p. 114 → 112
• Provides continuous (24/7) monitoring of the secure room.
• Provides continuous (24/7) monitoring of the secure room
Modified
p. 114 → 112
4D-4.12 Any windows in the secure room must be locked, protected by alarmed sensors, or otherwise similarly secured.
Modified
p. 114 → 112
4D-4.12.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors.
Modified
p. 114 → 112
4D-4.12.b Examine the configuration of window sensors to verify that the alarm mechanism is active.
Modified
p. 114 → 112
4D-4.13 Any windows must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
Modified
p. 114 → 112
4D-4.13 Observe all windows in the secure areas to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
Modified
p. 114 → 112
4D-4.14 Access-control and monitoring systems must be connected to an uninterruptible power source (UPS) to prevent outages.
Modified
p. 114 → 112
4D-4.14 Inspect uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems are powered through the UPS.
Modified
p. 114 → 112
4D-4.15 All alarm events must be logged. 4D-4.15.a Examine security policies and procedures to verify they require that all alarm events are logged.
Modified
p. 114 → 112
4D-4.15.b Examine security-system configurations and documented alarm events to verify that all alarm events are logged.
Removed
p. 115
5D-4.17 Use of an emergency entry or exit mechanism must cause an alarm event.
Modified
p. 115 → 112
4D-4.16 Documented alarm events must be signed off by an authorized person who was not involved in the event.
Modified
p. 115 → 112
4D-4.16.a Examine security policies and procedures to verify alarm events must be signed off by an authorized person other than the individual who was involved in the event.
Modified
p. 115 → 112
4D-4.16.b For a sample of documented alarm events, interview personnel who signed off on the event to verify that person was not involved in the event.
Modified
p. 115 → 113
4D-4.17 Examine security system configurations to verify that an alarm event is generated upon use of any emergency entry or exit mechanism.
Modified
p. 115 → 113
4D-4.18 Authorized personnel must respond to all physical intrusion alarms within 30 minutes.
Modified
p. 115 → 113
4D-4.18.a Examine documented policies and procedures to verify they define that all alarm events are responded to by authorized personnel within 30 minutes.
Modified
p. 115 → 113
4D-4.18.b Examine documented alarm events and interview personnel to verify alarm events were responded by authorized personnel within 30 minutes.
Modified
p. 115 → 113
4D-4.19 A process for synchronizing the time and date stamps of the access-control, intrusion-detection and monitoring (camera) systems must be implemented.
Modified
p. 115 → 113
4D-4.19.a Examine documented procedures to verify that mechanisms are defined for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems.
Modified
p. 115 → 113
4D-4.19.b Examine system configurations for access, intrusion-detection, and monitoring (camera) systems to verify that time and date stamps are synchronized.
Modified
p. 115 → 113
4D-4.19.c Examine a sample of logs from the access, intrusion-detection, and monitoring (camera) systems to verify log time and date stamps are synchronized.
Modified
p. 115 → 113
4D-4.19.1 If a manual synchronization process is used, synchronization must occur at least quarterly, and documentation of the synchronization must be retained for at least a one-year period.
Modified
p. 115 → 113
4D-4.19.1.a If a manual synchronization process is implemented, interview responsible personnel and examine records of synchronization to verify the mechanism is performed at least quarterly.
Modified
p. 115 → 113
4D-4.19.1.b Examine records of the synchronization process to verify that documentation is retained for at least one year.
Modified
p. 115 → 113
4D-4.20 The entrance to the secure room must include a mechanism to ensure the door is not left open.
Modified
p. 115 → 113
4D-4.20 Observe authorized personnel entering the secure room to verify that a mechanism is in place to ensure the door is not left open.
Modified
p. 116 → 114
Domain 5 Requirements Testing Procedures 5D-4.21 An audible alarm must sound if the entrance to the secure room remains open for more than 30 seconds.
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.21 An audible alarm must sound if the entrance to the secure room remains open for more than 30 seconds.
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.21 An audible alarm must sound if the entrance to the secure room remains open for more than 30 seconds.
Modified
p. 116 → 114
4D-4.21.a Examine secure room entry mechanisms to verify that an audible alarm is configured to sound if the entrance remains open for more than 30 seconds.
Modified
p. 116 → 114
4D-4.21.b Observe authorized personnel entering the secure room and request the door is held open. Verify that an audible alarm sounds if the entrance remains open for more than 30 seconds.
Removed
p. 117
5E-1 For component providers of decryption-management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
Modified
p. 117 → 115
Requirement 5E: Component providers ONLY: report status to solution providers Domain 5 Requirements Testing Procedures
Requirement 4E: Component providers ONLY: report status to solution providers Domain 4 Requirements Testing Procedures 4E-1 For component providers of decryption-management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
Modified
p. 117 → 115
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the component provider’s decryption-management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include decryption-management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment for subsequent PCI listing of the component provider’s decryption-management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include decryption-management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).
Modified
p. 117 → 115
4E-1.1 Track status of the decryption-management service and provide reports to solution provider annually and upon significant changes, including at least the following:
Modified
p. 117 → 115
• Number of HSMs deployed and any change in numbers since last report
• Number of HSMs deployed and any change in numbers since the last report
Modified
p. 117 → 115
• Details of any suspicious activity that occurred, per 5C- 5E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel, and to confirm that the following processes are documented and implemented:
• Details of any suspicious activity that occurred, per 4C-1.2 4E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component- provider personnel, and to confirm that the following processes are documented and implemented:
Modified
p. 117 → 115
• Details of any suspicious activity that occurred, per 5C-1.2 5E-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
• Details of any suspicious activity that occurred, per 4C-1.2 4E-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
Modified
p. 118 → 116
Requirement 5E: Component providers ONLY: report status to solution providers Domain 5 Requirements Testing Procedures 5E-1.2 Manage and monitor changes to decryption- management services and notify the solution provider upon occurrence of any of the following:
Requirement 4E: Component providers ONLY: report status to solution providers Domain 4 Requirements Testing Procedures 4E-1.2 Manage and monitor changes to decryption- management services and notify the solution provider upon occurrence of any of the following:
Modified
p. 118 → 116
Note: Adding or removing HSM types may require adherence to PCI SSC’s process for P2PE Delta Changes. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.
Modified
p. 118 → 116
4E-1.2.a Review component provider’s documented procedures and interview responsible component-provider personnel, and confirm that processes include notifying the solution provider upon occurrence of the following:
Modified
p. 118 → 116
• Additions and/or removal of HSM types 5E-1.2.b Observe reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence:
• Additions and/or removal of HSM types 4E-1.2.b Observe reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence:
Modified
p. 119 → 117
5A Account data is processed using algorithms and methodologies that ensure they are kept secure.
Modified
p. 119 → 117
Control Objective 2 Account-data keys and key-management methodologies are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
Modified
p. 119 → 117
Control Objective 3 Keys are conveyed or transmitted in a secure manner.
Modified
p. 119 → 117
Control Objective 4 Key loading is handled in a secure manner.
Modified
p. 119 → 117
Control Objective 5 Keys are used in a manner that prevents or detects their unauthorized usage.
Modified
p. 119 → 117
Control Objective 6 Keys are administered in a secure manner.
Modified
p. 119 → 117
Control Objective 7 Equipment used to process account data and keys is managed in a secure manner.
Modified
p. 119 → 117
5H For hybrid decryption solutions: Implement secure hybrid-key management.
Modified
p. 119 → 117
5I Component providers ONLY: report status to solution providers.
Removed
p. 120
Domain 6 requirements address secure cryptographic key-management operations for the encryption environment (Domain 1) and the decryption environment (Domain 5), as well as environments performing symmetric-key distribution using asymmetric keys (remote key distribution), certification authority/registration authority (Domain 6 Parts A1 and A2 respectively) and key-injection (Domain 6 Annex B).
Modified
p. 120 → 121
Hybrid decryption environments require HSMs for cryptographic key-management functions but allow for non-SCD Host Systems to be used for account data decryption. Unlike a P2PE solution with a hardware decryption environment (in which cryptographic key management and account-data decryption are performed entirely within a hardware security module, or HSM), a hybrid decryption environment (which requires HSMs for cryptographic key-management functions) allows for the decryption of account data outside of an HSM in non-SCDs on a Host System. These environments must …
Hybrid decryption environments require HSMs for cryptographic key-management functions but allow for non-SCD Host Systems to be used for account-data decryption. Unlike a P2PE solution with a hardware decryption environment (in which cryptographic key management and account-data decryption are performed entirely within a hardware security module, or HSM), a hybrid decryption environment (which requires HSMs for cryptographic key-management functions) allows for the decryption of account data outside of an HSM in non-SCDs on a Host System. These environments must meet …
Modified
p. 120 → 121
For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 5, and 6 of this document refers to merchant personnel in the encryption environments, and represents requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 4, and 5 of this document refers to merchant personnel in the encryption environments, and represents requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
Removed
p. 121
Domain 6 Normative Annex A
• Symmetric-Key Distribution using Asymmetric Techniques For specific requirements pertaining to entities involved in the implementation of symmetric-key distribution using asymmetric keys (remote key distribution) or those entities involved in the operation of Certification Authorities for such purposes, see Domain 6 Normative Annex A. Entities involved in remote key distribution or the operation of CA/RAs are subject to both the requirements stipulated in the main body of the Domain 6 section of this document and the additional criteria stipulated in Annex A1 or A2, respectively.
• Symmetric-Key Distribution using Asymmetric Techniques For specific requirements pertaining to entities involved in the implementation of symmetric-key distribution using asymmetric keys (remote key distribution) or those entities involved in the operation of Certification Authorities for such purposes, see Domain 6 Normative Annex A. Entities involved in remote key distribution or the operation of CA/RAs are subject to both the requirements stipulated in the main body of the Domain 6 section of this document and the additional criteria stipulated in Annex A1 or A2, respectively.
Modified
p. 121
Definitions and Annexes For the purposes of this document:
Definitions and Annex For the purposes of this document:
Modified
p. 121
• Private Key = Asymmetric key used only for decryption operations or for creating digital signatures. No one private key should be used for both purposes (except for transaction-originating SCDs).
Modified
p. 121
Public Key = asymmetric key used only for encryption operations or for verifying digital signatures. No one public key should be used for both purposes (except for transaction-originating SCDs).
• Public Key = Asymmetric key used only for encryption operations or for verifying digital signatures. No one public key should be used for both purposes (except for transaction-originating SCDs). This annex provides the minimum and equivalent key sizes and strengths for the encryption of data and other cryptographic keys.
Removed
p. 122
Domain 6 Normative Annex C
• This annex provides the minimum and equivalent key sizes and strengths for the encryption of data and other cryptographic keys.
• This annex provides the minimum and equivalent key sizes and strengths for the encryption of data and other cryptographic keys.
Removed
p. 123
Domain 6 Requirements Testing Procedures 6A-1 Account data is protected with appropriate cryptographic algorithms, key sizes and strengths, and key-management processes.
6A.1.1 Only approved encryption algorithms and key sizes must be used to protect account data and cryptographic keys, as listed in Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
6A-1.1.a Examine documented key-management policies and procedures to verify that all cryptographic keys use algorithms and key sizes that are in accordance with Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
6A-1.1.b Observe key-management operations and devices to verify that all cryptographic algorithms and key sizes are in accordance with Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
6A-1.2 Cryptographic-key changes must be implemented for keys that have reached the end of their crypto-period (e.g., after a defined period of time and/or after a certain amount of cipher-text has …
6A.1.1 Only approved encryption algorithms and key sizes must be used to protect account data and cryptographic keys, as listed in Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
6A-1.1.a Examine documented key-management policies and procedures to verify that all cryptographic keys use algorithms and key sizes that are in accordance with Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
6A-1.1.b Observe key-management operations and devices to verify that all cryptographic algorithms and key sizes are in accordance with Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
6A-1.2 Cryptographic-key changes must be implemented for keys that have reached the end of their crypto-period (e.g., after a defined period of time and/or after a certain amount of cipher-text has …
Modified
p. 123 → 126
6-1.1.a Examine documented procedures to verify the following.
Removed
p. 124
Domain 6 Requirements Testing Procedures 6A-1.3 Documentation describing the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key-management solution must exist and must be demonstrably in use for all key-management processes.
6A-1.3.a Verify documentation exists describing the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key- management solution.
6A-1.3.b Observe architecture and key-management operations to verify that the documentation reviewed in 6A-1.1.4.a is demonstrably in use for all key-management processes.
6A-1.3.1 Maintain documentation of all cryptographic keys managed as part of the P2PE solution, including:
• Key-destruction method 6A-1.3.1.a Examine key management policies and procedures and verify documentation of all cryptographic keys managed as part of the P2PE solution is required, and includes:
• Key-destruction method 6A-1.3.1.b Observe documentation and interview personnel and confirm that documentation of all cryptographic keys managed as part of the P2PE solution exists, and includes:
6A-1.3.a Verify documentation exists describing the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key- management solution.
6A-1.3.b Observe architecture and key-management operations to verify that the documentation reviewed in 6A-1.1.4.a is demonstrably in use for all key-management processes.
6A-1.3.1 Maintain documentation of all cryptographic keys managed as part of the P2PE solution, including:
• Key-destruction method 6A-1.3.1.a Examine key management policies and procedures and verify documentation of all cryptographic keys managed as part of the P2PE solution is required, and includes:
• Key-destruction method 6A-1.3.1.b Observe documentation and interview personnel and confirm that documentation of all cryptographic keys managed as part of the P2PE solution exists, and includes:
Removed
p. 125
Domain 6 Requirements Testing Procedures 6A-1.3.2 Maintain a list of all devices used to generate keys or key components managed as part of the P2PE solution, including:
Removed
p. 125
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) 6A-1.3.2.a Examine key management policies and procedures and verify a list of all devices used to generate keys managed as part of the P2PE solution is required, and includes:
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) 6A-1.3.2.b Observe documentation and interview personnel and confirm that a list of all devices used to generate keys managed as part of the P2PE solution exists, and includes:
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) 6A-1.3.2.b Observe documentation and interview personnel and confirm that a list of all devices used to generate keys managed as part of the P2PE solution exists, and includes:
Removed
p. 126
6B-1.1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Cryptographic keys or key components must be generated by one of the following:
6B-2.1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component.
• There is no unauthorized mechanism that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
6B-2.1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component.
• There is no unauthorized mechanism that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Modified
p. 126 → 125
Requirement 5: All keys, key components, and key shares are generated using an approved random or pseudo-random function.
Modified
p. 126 → 125
• An approved key-generation function of a PCI approved HSM or POI device;
• An approved key-generation function of a PCI- approved HSM or POI device
Modified
p. 126 → 125
Note: Random number generation is critical to the security and integrity of all cryptographic systems. All cryptographic key generation relies upon good quality, randomly generated values.
Modified
p. 126 → 125
5-1.a Examine key-management policy documentation to verify that it requires that all devices used to generate cryptographic keys meet one of the following:
Modified
p. 126 → 125
• An approved key-generation function of a PCI
•approved HSM or POI device;
•approved
• An approved key-generation function of a PCI-approved HSM or POI device
Modified
p. 126 → 125
• An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.
• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.
Modified
p. 126 → 125
5-1.b Examine certification letters or technical documentation to verify that all devices used to generate cryptographic keys or key components meet one of the following:
Modified
p. 126 → 125
• An approved key-generation function of a PCI
•approved HSM or POIdevice;
•approved HSM or POI
• An approved key-generation function of a PCI
•approved HSM or POI device
•approved HSM or POI device
Modified
p. 126 → 125
• An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 6B-1.1.c Observe devices performing key-generation functions, including validation of firmware used.
• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 5-1.c Examine procedures to be used for future generations and logs of past key generation to verify devices used for key-generation are those as noted above, including validation of firmware used.
Modified
p. 126
Requirement 6: Compromise of the key-generation process must not be possible without collusion between at least two trusted individuals.
Modified
p. 126
6-1 Implement security controls, including dual control and tamper detection, to prevent the unauthorized disclosure of keys or key components.
Modified
p. 126
6-1 Perform the following:
Modified
p. 126
• The documented procedures were followed, and
Modified
p. 126
• Any clear-text output of the key-generation process is overseen by only the assigned key custodian(s) for that component/share and is limited to those individual components and not the entire key.
• Any output of a clear-text component or share is overseen by only the assigned key custodian(s) for that component/share
Removed
p. 127
• There is no mechanism (including connectivity) that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Note: Full-length key components or key shares derived using a recognized key-splitting algorithm are not considered key parts and do not provide any information regarding the actual cryptographic key.
6B-2.1.3 Devices used for the generation of clear-text key components that are output in the clear must be powered off when not in use.
6B-2.1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., unnecessary cables).
6B-2.1.4.a Review documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering, prior to use.
Note: Full-length key components or key shares derived using a recognized key-splitting algorithm are not considered key parts and do not provide any information regarding the actual cryptographic key.
6B-2.1.3 Devices used for the generation of clear-text key components that are output in the clear must be powered off when not in use.
6B-2.1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., unnecessary cables).
6B-2.1.4.a Review documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering, prior to use.
Modified
p. 127 → 126
6-1.1.b Observe key-generation process demonstration and interview responsible personnel to verify:
Modified
p. 127 → 126
• Any clear-text output of the key-generation process is overseen by only the assigned key custodian(s) for that component/share and is limited to those individual components and not the entire key..
• Any output of clear-text component or share is overseen by only the assigned key custodian(s) for the component/share.
Modified
p. 127 → 126
6-1.2 There must be no point in the key-generation process where a single individual has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
Modified
p. 127 → 126
6-1.2.a Examine documented procedures for all key-generation methods and observe demonstrations of the key-generation process from end-to-end to verify there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
Modified
p. 127 → 126
• At least two individuals performed the key-generation processes.
Modified
p. 127
6-1.3 Examine documented procedures for all key-generation methods. Verify procedures require that:
Modified
p. 127
• Key-generation devices that generate clear-text key components are powered off when not in use; or
• Key-generation devices that generate clear-text key components are powered off when not in use or require re-authentication whenever key generation is invoked; or
Modified
p. 127
• If logically partitioned for concurrent use in other processes, the key-generation capabilities are disabled when not in use and other activities are continuing.
• If the device used for key generation is logically partitioned for concurrent use in other processes, the key-generation capabilities are enabled for execution of the procedure and disabled when the procedure is complete.
Modified
p. 127
6-1.4.b Observe key-generation set-up processes for all key types to verify that key- generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
Removed
p. 128
Domain 6 Requirements Testing Procedures 6B-2.1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the key- generation area It must not be feasible to observe the key-component/key-generation process whereby clear- text keying material is observable either directly or via camera monitoring 6B-2.1.5.a Examine documentation to verify that physical security controls are defined to ensure the key component/key-generation process cannot be observed or accessed by unauthorized personnel.
6B-2.1.5.b Observe the physical security controls to verify that key-component/key- generation process cannot be observed or accessed by unauthorized personnel.
6B-2.2 Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret key or private key, or key component thereof, appears in unprotected memory.
6B-2.2.b Observe the generation process and review vendor documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof …
6B-2.1.5.b Observe the physical security controls to verify that key-component/key- generation process cannot be observed or accessed by unauthorized personnel.
6B-2.2 Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret key or private key, or key component thereof, appears in unprotected memory.
6B-2.2.b Observe the generation process and review vendor documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof …
Modified
p. 128
For example, it is not permitted for the cryptographic key to be passed through the memory of a computer unless it has been specifically tasked for the sole purpose of key generation/loading. Computers that have been specifically purposed and used solely for key generation/loading are permitted for use if all other requirements can be met, including those of Requirement 6B-1 and the controls defined in Requirements at 6D-2 of Annex B.
For example, it is not permitted for the cryptographic key to be passed through the memory of a computer unless it has been specifically tasked for the sole purpose of key generation/loading. Computers that have been specifically purposed and used solely for key generation/loading are permitted for use if all other requirements can be met, including those of Requirement 5 and the controls defined in Requirement 13.
Modified
p. 128
Additionally, this requirement excludes from its scope computers used only for administration of SCDs, or key- generation devices where they have no ability to access clear-text cryptographic keys or components.
Additionally, this requirement excludes from its scope computers used only for administration of SCDs, or key- generation devices that do not have the ability to access clear-text cryptographic keys or components.
Modified
p. 128
Single-purpose computers with an installed SCD where clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) meet this requirement. Where the components pass through unprotected memory of the PC, it must meet Requirement 6D-2 of Annex B.
Single-purpose computers with an installed SCD or a modified PED where clear keying material is injected directly from a secure port on the key-generating SCD to the target (e.g., a POI device) meet this requirement. Where the components pass through memory of the PC, Requirement 13 must be met.
Modified
p. 128
Note: See Requirement 5 and Requirement 13 6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
Removed
p. 129
Domain 6 Requirements Testing Procedures 6B-2.3 Printed key components must be printed within blind mailers or sealed immediately after printing to ensure that:
6B-2.3.b Observe processes for printing key components to verify that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output.
6B-2.4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted
6B-2.3.b Observe processes for printing key components to verify that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output.
6B-2.4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted
Modified
p. 129
• Only approved key custodians can observe their own key component.
• Only approved key custodians can observe the key component.
Modified
p. 129
• Only approved key custodians can observe their own key component.
• Only approved key custodians can observe the key component.
Modified
p. 129
Printers used for this purpose must not be used for other purposes.
Printers used for this purpose must not be used for other purposes, must not be networked (i.e., locally connected), and must be managed under dual control, including use of a secure room that meets the requirements of 32-9.
Modified
p. 129
6-3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed in tamper- evident and authenticable packaging immediately after printing such that:
Modified
p. 129
6-3.c Observe blind mailers, tamper-evident and authenticable, or other sealed containers used for key components to verify that components cannot be read from within and that tampering can be visually detected.
Modified
p. 129 → 130
6-4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures ensure the following:
Modified
p. 129 → 130
• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device that will use the key.
• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key.
Modified
p. 129 → 130
• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device that will use the key.
• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key.
Modified
p. 129 → 130
6-4.b Observe the destruction process of each identified type of key residue and verify the following:
Removed
p. 130
Domain 6 Requirements Testing Procedures 6B-2.5 Asymmetric-key pairs must either be:
6B-2.6 Policy and procedures must exist to ensure that clear-text private or secret keys or their components are prohibited from being transmitted across insecure channels. These include but are not limited to:
6B-2.6 Policy and procedures must exist to ensure that clear-text private or secret keys or their components are prohibited from being transmitted across insecure channels. These include but are not limited to:
Modified
p. 130 → 131
• If generated externally, the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair 6B-2.5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:
• If generated externally, the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair.
Modified
p. 130 → 131
6-5.b Observe key-generation processes to verify that asymmetric-key pairs are either:
Modified
p. 130 → 132
• Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components
• Faxing, e-mailing, or otherwise electronically conveying clear-text private or secret keys or components
Modified
p. 130 → 132
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
• Conveying clear-text private key shares or secret key components/shares without containing them within tamper-evident and authenticable packaging
Modified
p. 130 → 132
• Writing key or component values into startup 6B-2.6.a Examine documented policy and procedures to verify that clear-text private or secret keys or their components are prohibited from being transmitted across insecure channels, including but not limited to:
• Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that they include language that prohibits transmitting clear-text private or secret keys or their components/shares across insecure channels, including but not limited to:
Modified
p. 130 → 132
• Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components
• Faxing, e-mailing, or otherwise electronically conveying clear-text keys or components
Modified
p. 130 → 132
• Affixing (e.g., taping) key or component values to or inside devices
• Affixing key or component values to or inside devices
Removed
p. 131
Domain 6 Requirements Testing Procedures instructions
• Writing key or component values in procedure manuals 6B-2.6.b From observation of key-management processes verify that key components are not transmitted across insecure channels, including but not limited to:
• Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components
• Writing key or component values in procedure manuals 6B-2.6.b From observation of key-management processes verify that key components are not transmitted across insecure channels, including but not limited to:
• Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components
Removed
p. 131
6B-3.2.b Observe demonstrations for the generation of higher-level keys to verify that all key-generation events are logged.
Modified
p. 131 → 132
• Affixing (e.g., taping) key or component values to or inside devices
• Writing key or component values in procedure manual
Modified
p. 131 → 133
Requirement 7: Documented procedures must exist and must be demonstrably in use for all key-generation processes.
Modified
p. 131 → 133
7-1 Written key-generation policies and procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of these procedures. Procedures for creating all keys must be documented.
Modified
p. 131 → 133
7-1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations and address all keys in scope.
Modified
p. 131 → 133
7-1.b Interview those responsible for the key-generation processes (including key custodians, supervisory staff, technical management, etc.) to verify that the documented procedures are known and understood by all affected parties.
Modified
p. 131 → 133
7-1.c Observe key-generation ceremonies, whether actual or for demonstration purposes, and verify that the documented procedures are demonstrably in use.
Modified
p. 131 → 133
7-2.b Observe demonstrations for the generation of higher-level keys to verify that all key-generation events are logged.
Modified
p. 131 → 133
7-2.a Examine documented key-generation procedures to verify that key-generation events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components and MFKs and BDKs) are logged.
Modified
p. 131 → 133
7-2.c Examine logs of key generation to verify that exchanges of higher-level keys with other organizations have been recorded and that all required elements were captured.
Removed
p. 132
6C-1.1 Keys must be transferred either encrypted or within an SCD. If clear-text outside of an SCD as two or more components using different communication channels.
Clear-text key components may be transferred in SCDs or using tamper-evident, authenticable packaging.
• Where key components are transmitted in clear-text using pre-numbered, tamper-evident, authenticable mailers: o Components/shares must be conveyed using at least two separate communication channels, such as different courier services. Components/shares sufficient to form the key must not be conveyed using the same communication channel. o Ensure that details of the serial number of the package are conveyed separately from the package itself. o Ensure that that documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material.
(continued on next page) 6C-1.1.a Determine whether keys are transmitted encrypted as clear-text components, or within an SCD.
6C-1.1.b If key components are ever transmitted in …
Clear-text key components may be transferred in SCDs or using tamper-evident, authenticable packaging.
• Where key components are transmitted in clear-text using pre-numbered, tamper-evident, authenticable mailers: o Components/shares must be conveyed using at least two separate communication channels, such as different courier services. Components/shares sufficient to form the key must not be conveyed using the same communication channel. o Ensure that details of the serial number of the package are conveyed separately from the package itself. o Ensure that that documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material.
(continued on next page) 6C-1.1.a Determine whether keys are transmitted encrypted as clear-text components, or within an SCD.
6C-1.1.b If key components are ever transmitted in …
Modified
p. 132 → 134
Requirement 8: Secret or private keys must be transferred by:
Removed
p. 133
Domain 6 Requirements Testing Procedures 6C-1.1 (continued)
• Where an SCD is used for components, the mechanisms or data (e.g., PIN) to obtain the key component from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
• Where an SCD (HSM or KLD) is conveyed with pre- loaded secret and/or private keys, the SCD must require dual control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
Components of encryption keys must be transferred using different communication channels, such as different courier services. It is not sufficient to send key components for a specific key on different days using the same communication channel.
6C-1.1.b Where an SCD is used, perform the following:
• …
• Where an SCD is used for components, the mechanisms or data (e.g., PIN) to obtain the key component from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
• Where an SCD (HSM or KLD) is conveyed with pre- loaded secret and/or private keys, the SCD must require dual control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
Components of encryption keys must be transferred using different communication channels, such as different courier services. It is not sufficient to send key components for a specific key on different days using the same communication channel.
6C-1.1.b Where an SCD is used, perform the following:
• …
Removed
p. 136
Note: No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key.
6C-2.1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear-text secret or private key component/share must at all times be either:
6C-2.1.b Observe key-management processes and interview responsible personnel to verify processes are implemented to ensure that any single clear-text secret or private key component/share is at all times either:
• Locked in a security container (including pre-numbered tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or
6C-2.2 Packaging or mailers (i.e., pre-numbered, tamper- evident packaging) containing clear-text key components are examined for evidence of tampering before being opened. Any sign of package tampering must result in …
6C-2.1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear-text secret or private key component/share must at all times be either:
6C-2.1.b Observe key-management processes and interview responsible personnel to verify processes are implemented to ensure that any single clear-text secret or private key component/share is at all times either:
• Locked in a security container (including pre-numbered tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or
6C-2.2 Packaging or mailers (i.e., pre-numbered, tamper- evident packaging) containing clear-text key components are examined for evidence of tampering before being opened. Any sign of package tampering must result in …
Removed
p. 140
Domain 6 Requirements Testing Procedures 6D-1 Secret and private keys must be input into hardware (host) security modules (HSMs) and Point of Interaction (POI) devices in a secure manner.
a) Unencrypted secret or private keys must be entered into cryptographic devices using the principles of dual control and split knowledge.
b) Key-establishment techniques using public-key cryptography must be implemented securely.
6D-1.1 The loading of secret or private keys, when from the individual key components or shares, must be performed using the principles of dual control and split knowledge.
Note: Manual key loading may involve the use of media such as paper, smart cards, or other physical tokens.
6D-1.1.a Review documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required.
6D-1.1.b Interview appropriate personnel to determine the number of key components for each manually loaded key, the length of the key components, and the methodology …
a) Unencrypted secret or private keys must be entered into cryptographic devices using the principles of dual control and split knowledge.
b) Key-establishment techniques using public-key cryptography must be implemented securely.
6D-1.1 The loading of secret or private keys, when from the individual key components or shares, must be performed using the principles of dual control and split knowledge.
Note: Manual key loading may involve the use of media such as paper, smart cards, or other physical tokens.
6D-1.1.a Review documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required.
6D-1.1.b Interview appropriate personnel to determine the number of key components for each manually loaded key, the length of the key components, and the methodology …
Removed
p. 149
Domain 6 Requirements Testing Procedures 6E-1 Unique, secret cryptographic keys must be in use for each identifiable link between host computer systems of two organizations or logically separate systems within the same organization.
6E-1.1 Where two organizations or logically separate systems share a key to encrypt account data (including a key-encipherment key used to encrypt a data-encryption key) communicated between them, that key must:
• Be unique to those two entities or logically separate systems and
6E-1.1.a Examine the documented key matrix and operational procedures and interview personnel to determine whether any keys are shared between organizations or logically separate systems.
6E-1.1.b Generate or otherwise obtain key check values for any key-encipherment keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than 10 zone connections are in use. This is not intended to be based on values retained on paper or otherwise sent as part …
6E-1.1 Where two organizations or logically separate systems share a key to encrypt account data (including a key-encipherment key used to encrypt a data-encryption key) communicated between them, that key must:
• Be unique to those two entities or logically separate systems and
6E-1.1.a Examine the documented key matrix and operational procedures and interview personnel to determine whether any keys are shared between organizations or logically separate systems.
6E-1.1.b Generate or otherwise obtain key check values for any key-encipherment keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than 10 zone connections are in use. This is not intended to be based on values retained on paper or otherwise sent as part …
Removed
p. 154
Domain 6 Requirements Testing Procedures 6F-1 Secret keys used for enciphering account-data-encryption keys or for account-data encryption, or private keys used in connection with remote key-distribution implementations, must never exist outside of SCDs, except when encrypted or securely stored and managed using the principles of dual control and split knowledge.
Note for hybrid decryption solutions: Requirements specific to hybrid decryption solutions are shown in italics throughout 6F.
6F-1.1 Secret or private keys must only exist in one or more of the following forms:
• At least two separate key shares or full-length components
• Encrypted with a key of equal or greater strength as delineated in Annex C
• Contained within a secure cryptographic device Note for hybrid decryption solutions: Clear-text Data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data.
6F-1.1.a Examine documented procedures for key storage and usage and observe key stores …
Note for hybrid decryption solutions: Requirements specific to hybrid decryption solutions are shown in italics throughout 6F.
6F-1.1 Secret or private keys must only exist in one or more of the following forms:
• At least two separate key shares or full-length components
• Encrypted with a key of equal or greater strength as delineated in Annex C
• Contained within a secure cryptographic device Note for hybrid decryption solutions: Clear-text Data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data.
6F-1.1.a Examine documented procedures for key storage and usage and observe key stores …
Removed
p. 159
Domain 6 Requirements Testing Procedures 6F-2.2 If attempts to load a secret key or key component into an KLD or POI device (or a Host System, for hybrid decryption solutions) fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI device (or Host System).
6F-2.2 Interview responsible personnel and observe implemented processes to verify that if attempts to load a secret key or key component into an KLD or POI device (or a Host System, for hybrid decryption solutions) fail, the same key or component is not loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI device (or Host …
6F-2.2 Interview responsible personnel and observe implemented processes to verify that if attempts to load a secret key or key component into an KLD or POI device (or a Host System, for hybrid decryption solutions) fail, the same key or component is not loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI device (or Host …
Removed
p. 165
Domain 6 Requirements Testing Procedures 6F-7 Backups of secret and private keys must exist only for the purpose of reinstating keys that are accidentally destroyed or are otherwise inaccessible. The backups must exist only in one of the allowed storage forms for that key.
Note: It is not a requirement to have backup copies of key components or keys.
Note for hybrid decryption solutions: Clear-text cryptographic keys used on the Host System must not be included in any system back-up (refer to Requirement 5D-1.13) 6F-7.1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as are followed for the primary keys.
6F-7.1 Interview responsible personnel and examine documented procedures and backup records to determine whether any backup copies of keys or their components exist. Perform the following:
6F-7.1.a Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance …
Note: It is not a requirement to have backup copies of key components or keys.
Note for hybrid decryption solutions: Clear-text cryptographic keys used on the Host System must not be included in any system back-up (refer to Requirement 5D-1.13) 6F-7.1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as are followed for the primary keys.
6F-7.1 Interview responsible personnel and examine documented procedures and backup records to determine whether any backup copies of keys or their components exist. Perform the following:
6F-7.1.a Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance …
Removed
p. 166
• Role definition
•nominated individual with overall responsibility
• Role definition
•nominated individual with overall responsibility
• Management of personnel changes, including revocation of access control and other privileges when personnel move 6F-8.1.a Examine documented procedures for key-administration operations to verify they cover all activities related to key administration, and include:
• Management of personnel changes, including revocation of access control and other privileges when personnel move 6F-8.1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
6F-8.1.c Interview personnel to verify that security-awareness training is provided for the appropriate personnel.
6F-8.1.d Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws).
•nominated individual with overall responsibility
• Role definition
•nominated individual with overall responsibility
• Management of personnel changes, including revocation of access control and other privileges when personnel move 6F-8.1.a Examine documented procedures for key-administration operations to verify they cover all activities related to key administration, and include:
• Management of personnel changes, including revocation of access control and other privileges when personnel move 6F-8.1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
6F-8.1.c Interview personnel to verify that security-awareness training is provided for the appropriate personnel.
6F-8.1.d Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws).
Removed
p. 167
Domain 6 Requirements Testing Procedures 6G-1. Equipment used to protect account data (e.g., POI devices and HSMs) must be placed into service only if there is assurance that the equipment has not been substituted or subjected to unauthorized modifications or tampering prior to the deployment of the device
•both prior to and subsequent to the loading of cryptographic keys
•and that precautions are taken to minimize the threat of compromise once deployed.
Note: Where POI is mentioned in Requirement 6G-1, the requirements apply to the solution provider managing POI devices prior to deployment to distribution channels or to the merchants that will process payments with the POI device. Merchant protection and use of POI devices once deployed are not the subjects of these P2PE requirements and are instead covered by guidance provided to merchants by the solution provider in the P2PE Instruction Manual (PIM). See PIM Template for more information about guidance required …
•both prior to and subsequent to the loading of cryptographic keys
•and that precautions are taken to minimize the threat of compromise once deployed.
Note: Where POI is mentioned in Requirement 6G-1, the requirements apply to the solution provider managing POI devices prior to deployment to distribution channels or to the merchants that will process payments with the POI device. Merchant protection and use of POI devices once deployed are not the subjects of these P2PE requirements and are instead covered by guidance provided to merchants by the solution provider in the P2PE Instruction Manual (PIM). See PIM Template for more information about guidance required …
Removed
p. 169
Domain 6 Requirements Testing Procedures 6G-1.3 Implement physical protection of devices from the manufacturer’s facility up to the point of key-insertion or inspection, through one or more of the following.
Use of physically secure and trackable packaging (e.g., pre- serialized, counterfeit-resistant, tamper-evident packaging). The devices are then stored in such packaging, or in secure storage, until key-insertion occurs.
Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been subject to any unauthorized modifications. (Note: Unauthorized access includes that by customs officials.) Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised. (Note: this control must be used in conjunction with one of the other methods.) Controls exist and are in use …
Use of physically secure and trackable packaging (e.g., pre- serialized, counterfeit-resistant, tamper-evident packaging). The devices are then stored in such packaging, or in secure storage, until key-insertion occurs.
Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been subject to any unauthorized modifications. (Note: Unauthorized access includes that by customs officials.) Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised. (Note: this control must be used in conjunction with one of the other methods.) Controls exist and are in use …
Removed
p. 172
Domain 6 Requirements Testing Procedures 6G-3 Procedures must be in place and implemented to protect any SCDs
•and ensure the destruction of any cryptographic keys or key material within such devices
•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.
Note: The requirements in 6G-3 apply to the solution provider managing POI devices when removed from service, retired at the end of the deployment lifecycle, or returned for repair. Merchant protection and use of POI devices once deployed are not the subjects of these P2PE requirements and are instead covered by guidance provided to merchants by the solution provider in the P2PE Instruction Manual (PIM). See PIM Template for more information about guidance required to be included in the PIM.
6G-3.1 Procedures are in place to ensure that any SCDs to be removed from service
•e.g., retired or returned for repair
•are not intercepted or used in an unauthorized …
•and ensure the destruction of any cryptographic keys or key material within such devices
•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.
Note: The requirements in 6G-3 apply to the solution provider managing POI devices when removed from service, retired at the end of the deployment lifecycle, or returned for repair. Merchant protection and use of POI devices once deployed are not the subjects of these P2PE requirements and are instead covered by guidance provided to merchants by the solution provider in the P2PE Instruction Manual (PIM). See PIM Template for more information about guidance required to be included in the PIM.
6G-3.1 Procedures are in place to ensure that any SCDs to be removed from service
•e.g., retired or returned for repair
•are not intercepted or used in an unauthorized …
Removed
p. 179
Requirement 6I: Component providers ONLY: report status to solution providers Domain 6 Requirements Testing Procedures
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain (in conjunction with Domains 1 or 5 as applicable to the solution provider’s services) for subsequent PCI listing of the component provider’s device-management or decryption-management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include device management or decryption management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).
6I-1 For component providers performing key management in conjunction with device-management or decryption-management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
6I-1.1 Track status of the deployed key-management services for POIs and HSMs, and provide reports to …
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain (in conjunction with Domains 1 or 5 as applicable to the solution provider’s services) for subsequent PCI listing of the component provider’s device-management or decryption-management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include device management or decryption management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).
6I-1 For component providers performing key management in conjunction with device-management or decryption-management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
6I-1.1 Track status of the deployed key-management services for POIs and HSMs, and provide reports to …
Removed
p. 180
These requirements pertain to two distinct areas covered separately in the two parts of this Annex.
A1
• Remote Key-Distribution Using Asymmetric Techniques Operations: Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account data encryption.
A2
• Certification and Registration Authority Operations: Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
• Certification Authority requirements apply to all entities (P2PE solution providers, P2PE component providers, and entities performing these functions on behalf of solution providers or component providers) signing public keys to be used for remote distribution of cryptographic keys, whether in X.509 certificate-based schemes or other designs, to allow for the required authentication of these signed public keys. For purposes of these requirements, …
A1
• Remote Key-Distribution Using Asymmetric Techniques Operations: Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account data encryption.
A2
• Certification and Registration Authority Operations: Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
• Certification Authority requirements apply to all entities (P2PE solution providers, P2PE component providers, and entities performing these functions on behalf of solution providers or component providers) signing public keys to be used for remote distribution of cryptographic keys, whether in X.509 certificate-based schemes or other designs, to allow for the required authentication of these signed public keys. For purposes of these requirements, …
Removed
p. 181
No additional security requirements added for “Symmetric Key Distribution using Asymmetric Techniques.”
No additional security requirements added for “Symmetric Key Distribution using Asymmetric Techniques.”
Requirement 6B: Account-data keys and key management methodologies are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
Domain 6 A1 Requirements Testing Procedures 6C-3 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed.
6C-3.2 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed except as noted in the main body of Domain 6 at Requirement 6C-3.1.
6C-3.2 Examine documented procedures to verify that all asymmetric keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed except …
No additional security requirements added for “Symmetric Key Distribution using Asymmetric Techniques.”
Requirement 6B: Account-data keys and key management methodologies are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
Domain 6 A1 Requirements Testing Procedures 6C-3 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed.
6C-3.2 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed except as noted in the main body of Domain 6 at Requirement 6C-3.1.
6C-3.2 Examine documented procedures to verify that all asymmetric keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed except …
Removed
p. 182
Domain 6 A1 Requirements Testing Procedures 6D-4 The loading of keys or key components must incorporate a validation mechanism such that the authenticity of the keys is ensured and it can be ascertained that they have not been tampered with, substituted, or compromised.
6D-4.3 Mechanisms must exist to prevent a non-authorized KDH from performing key transport, key exchange, or key establishment with POIs. POIs and key-distribution hosts (KDHs) using public-key schemes must validate authentication credentials of other such devices involved in the communication immediately prior to any key transport, exchange, or establishment.
Note: Examples of this kind of validation include checking current certificate revocation lists or embedding valid authorized KDH certificates in devices and disallowing communication with unauthorized KDHs, as delineated by techniques defined in the Technical FAQs for PCI PTS POI Security Requirements.
6D-4.3.a Examine documented procedures to confirm they define procedures for mutual authentication of the sending and receiving devices, as …
6D-4.3 Mechanisms must exist to prevent a non-authorized KDH from performing key transport, key exchange, or key establishment with POIs. POIs and key-distribution hosts (KDHs) using public-key schemes must validate authentication credentials of other such devices involved in the communication immediately prior to any key transport, exchange, or establishment.
Note: Examples of this kind of validation include checking current certificate revocation lists or embedding valid authorized KDH certificates in devices and disallowing communication with unauthorized KDHs, as delineated by techniques defined in the Technical FAQs for PCI PTS POI Security Requirements.
6D-4.3.a Examine documented procedures to confirm they define procedures for mutual authentication of the sending and receiving devices, as …
Removed
p. 186
Domain 6 A2 Requirements Testing Procedures 6C-3 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed.
6C-3.2 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed, except as noted in the main body of Domain 6 at Requirement 6C-3.1.
6C-3.3 Key sizes and algorithms must be in accordance with Annex C.
6C-3.3 Observe key-generation processes to verify that all asymmetric keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed.
Domain 6 A2 Requirements Testing Procedures 6D-4 The loading of keys or key components must incorporate a validation mechanism such that the authenticity of the keys is ensured and it can be ascertained that they have not been tampered with, substituted, or compromised.
6E-3.5 If a business …
6C-3.2 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed, except as noted in the main body of Domain 6 at Requirement 6C-3.1.
6C-3.3 Key sizes and algorithms must be in accordance with Annex C.
6C-3.3 Observe key-generation processes to verify that all asymmetric keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed.
Domain 6 A2 Requirements Testing Procedures 6D-4 The loading of keys or key components must incorporate a validation mechanism such that the authenticity of the keys is ensured and it can be ascertained that they have not been tampered with, substituted, or compromised.
6E-3.5 If a business …
Removed
p. 191
Domain 6 A2 Requirements Testing Procedures 6F-2.7.4 The compromised CA must notify any superior or subordinate CAs of the compromise. The compromise damage analysis must include a determination of whether subordinate CAs and KDHs must have their certificates reissued and distributed to them or be notified to apply for new certificates.
6F-2.7.4.a Examine documented procedures to verify that the following procedures are required in the event of a compromise:
• The CA will perform a damage assessment to determine the need to either: o Reissue and distribute certificates to affected parties, or o Notify the affected parties to apply for new certificates.
6F-2.7.4.b Interview responsible personnel to verify that the following procedures are performed in the event a compromise:
• The CA performs a damage assessment to determine the need to either: o Reissues and distributes certificates to affected parties, or o Notifies the affected parties to apply for new certificates.
6F-2.8 Minimum cryptographic strength …
6F-2.7.4.a Examine documented procedures to verify that the following procedures are required in the event of a compromise:
• The CA will perform a damage assessment to determine the need to either: o Reissue and distribute certificates to affected parties, or o Notify the affected parties to apply for new certificates.
6F-2.7.4.b Interview responsible personnel to verify that the following procedures are performed in the event a compromise:
• The CA performs a damage assessment to determine the need to either: o Reissues and distributes certificates to affected parties, or o Notifies the affected parties to apply for new certificates.
6F-2.8 Minimum cryptographic strength …
Removed
p. 194
Domain 6 A2 Requirements Testing Procedures 6F-5.5 All CA systems that are not operated strictly offline must be hardened to prevent insecure network access, to include:
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, telnet, ftp, etc.) must be removed or disabled.
6F-5.5.a Examine system documentation to verify the following is required:
6F-5.5.b For a sample of systems, examine documentation supporting the enablement of active services and ports, and observe system configurations to verify:
6F-5.5.1 All vendor-default IDs must be changed, removed, or disabled unless necessary for a documented and specific business reason.
Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades must only be enabled when required and otherwise must be disabled from login.
6F-5.5.1.a Examine documented procedures to verify that:
6F-5.5.1.b Examine system configurations and interview responsible personnel to verify that:
Domain 6 A2 Requirements Testing Procedures 6F-5.5.2 Vendor defaults, …
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, telnet, ftp, etc.) must be removed or disabled.
6F-5.5.a Examine system documentation to verify the following is required:
6F-5.5.b For a sample of systems, examine documentation supporting the enablement of active services and ports, and observe system configurations to verify:
6F-5.5.1 All vendor-default IDs must be changed, removed, or disabled unless necessary for a documented and specific business reason.
Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades must only be enabled when required and otherwise must be disabled from login.
6F-5.5.1.a Examine documented procedures to verify that:
6F-5.5.1.b Examine system configurations and interview responsible personnel to verify that:
Domain 6 A2 Requirements Testing Procedures 6F-5.5.2 Vendor defaults, …
Removed
p. 196
6F-5.6.3.a Examine audit trails to verify that logical events are divided into operating- system and CA application events.
6F-6.3.b Examine a sample of operating-system logs to verify they contain the following information:
6F-5.6.3.c Examine a sample of application logs to verify they contain the following information:
6F-5.7 CA application logs must use a digital signature or a symmetric MAC (based on one of the methods stated in ISO 16609
6F-5.7.a Examine log security controls to verify that CA application logs use a digital signature or a symmetric MAC (based on one of the methods stated in ISO 16609
6F-5.7.b Review documentation and interview personnel and observe to verify that signing/MACing key(s) used for this are protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
Domain 6 A2 Requirements Testing Procedures 6F-5.7.1 Certificate-processing system components operated online must be protected by a firewall(s) from all unauthorized access, including casual browsing …
6F-6.3.b Examine a sample of operating-system logs to verify they contain the following information:
6F-5.6.3.c Examine a sample of application logs to verify they contain the following information:
6F-5.7 CA application logs must use a digital signature or a symmetric MAC (based on one of the methods stated in ISO 16609
6F-5.7.a Examine log security controls to verify that CA application logs use a digital signature or a symmetric MAC (based on one of the methods stated in ISO 16609
6F-5.7.b Review documentation and interview personnel and observe to verify that signing/MACing key(s) used for this are protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
Domain 6 A2 Requirements Testing Procedures 6F-5.7.1 Certificate-processing system components operated online must be protected by a firewall(s) from all unauthorized access, including casual browsing …
Removed
p. 204
a) Dual access controls required to enable the key-encryption function
b) Physical protection of the equipment (e.g., locked access to it) under dual control
Domain 6 A2 Requirements Testing Procedures 6G-3 Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key, or signing applications to be loaded onto a POI device, must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following:
c) Restriction of logical access to the equipment 6G-3.2.1 The certificate-processing operations center must implement a three-tier physical security boundary, as follows:
6G-3.2.1.a Examine physical security policies to verify three tiers of physical security are defined as follows:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices 6G-3.2.1.b Observe the physical facility to verify three tiers of physical …
b) Physical protection of the equipment (e.g., locked access to it) under dual control
Domain 6 A2 Requirements Testing Procedures 6G-3 Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key, or signing applications to be loaded onto a POI device, must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following:
c) Restriction of logical access to the equipment 6G-3.2.1 The certificate-processing operations center must implement a three-tier physical security boundary, as follows:
6G-3.2.1.a Examine physical security policies to verify three tiers of physical security are defined as follows:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices 6G-3.2.1.b Observe the physical facility to verify three tiers of physical …
Removed
p. 207
Domain 6 A2 Requirements Testing Procedures 6G-3.2.6.1 All authorized personnel with access through the Level 3 barrier must:
• Be assigned resources (staff, dedicated personnel) of the CA operator with defined business needs and duties.
6G-3.2.6.1.a Examine documented policies and procedures to verify they require personnel authorized as having access through the Level 3 barrier to:
6G-4.2.6.1.b Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws) on CA personnel prior such personnel being authorized for access through the Level 3 barrier.
6G-3.2.6.1.c Interview a sample of personnel authorized for access through the Level 3 barrier to verify that they are assigned resources of the CA with defined business needs and duties.
6G-3.2.6.2 Other personnel requiring entry to this level must be accompanied by two (2) authorized and assigned resources at all times.
6G-3.2.6.2.a Examine documented policies and procedures to verify that personnel requiring entry to this level must …
• Be assigned resources (staff, dedicated personnel) of the CA operator with defined business needs and duties.
6G-3.2.6.1.a Examine documented policies and procedures to verify they require personnel authorized as having access through the Level 3 barrier to:
6G-4.2.6.1.b Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws) on CA personnel prior such personnel being authorized for access through the Level 3 barrier.
6G-3.2.6.1.c Interview a sample of personnel authorized for access through the Level 3 barrier to verify that they are assigned resources of the CA with defined business needs and duties.
6G-3.2.6.2 Other personnel requiring entry to this level must be accompanied by two (2) authorized and assigned resources at all times.
6G-3.2.6.2.a Examine documented policies and procedures to verify that personnel requiring entry to this level must …
Removed
p. 214
Key-injection systems that allow clear-text secret and/or private keys and/or their components to appear in unprotected memory (e.g., within a computer and outside of the secure boundary of a secure cryptographic device) are inherently less secure. Any such systems are subject to additional controls as delineated in the criteria in this annex. The payment brands may establish dates by which all key-injection facilities providing key-injection services to multiple entities shall have to use secure cryptographic hardware for key-injection.
Key-injection facilities that are engaged in either or both of the following must also meet the criteria delineated in Annex A:
1. Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
2. Remote distribution of symmetric keys using asymmetric techniques to transaction originating devices. These criteria pertain to the characteristics of the actual key-distribution methodology implemented.
Key-injection facilities that are engaged in either or both of the following must also meet the criteria delineated in Annex A:
1. Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
2. Remote distribution of symmetric keys using asymmetric techniques to transaction originating devices. These criteria pertain to the characteristics of the actual key-distribution methodology implemented.
Removed
p. 215
Domain 6 Annex B Requirements Testing Procedures 6A-1 Account data is processed in equipment that conforms to requirements for secure cryptographic devices (SCDs). Account data never appears in the clear outside of an SCD.
6A-1.2 Key-injection facilities must only inject keys into equipment that conforms to the requirements for SCDs.
Key-injection platforms and systems shall include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs.
6A-1.2.a Examine documented procedures and system documentation to verify that key- injection platforms and systems used for managing cryptographic keys are required to conform to the requirements for SCDs.
6A-1.2.b Examine key-injection platforms and systems used for managing cryptographic keys to verify they conform to the requirements for SCDs.
6A-1.3 Ensure that all hardware security modules (HSMs) are either:
• FIPS140-2 Level 3 or higher certified, or
6A-1.3.a For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and review …
6A-1.2 Key-injection facilities must only inject keys into equipment that conforms to the requirements for SCDs.
Key-injection platforms and systems shall include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs.
6A-1.2.a Examine documented procedures and system documentation to verify that key- injection platforms and systems used for managing cryptographic keys are required to conform to the requirements for SCDs.
6A-1.2.b Examine key-injection platforms and systems used for managing cryptographic keys to verify they conform to the requirements for SCDs.
6A-1.3 Ensure that all hardware security modules (HSMs) are either:
• FIPS140-2 Level 3 or higher certified, or
6A-1.3.a For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and review …
Removed
p. 216
• The PCI PTS or FIPS 140 Approval Number
• The PCI PTS or FIPS 140 Approval Number
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 6A-1.4.a For all PCI-approved HSMs used, examine HSM devices and review the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
• Any applications, including application version number, resident within the device which were included in the PTS assessment 6A-1.4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS140-2 Level 3 (or higher) approval listing for each HSM:
• The PCI PTS or FIPS 140 Approval Number
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 6A-1.4.a For all PCI-approved HSMs used, examine HSM devices and review the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
• Any applications, including application version number, resident within the device which were included in the PTS assessment 6A-1.4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS140-2 Level 3 (or higher) approval listing for each HSM:
Removed
p. 217
Domain 6 Annex B Requirements Testing Procedures 6A-1.5 The KIF platform provider maintains documentation detailing the distributed KIF architecture and key- management flows. The platform provider must:
• Maintain current documentation that describes or illustrates the architecture of the KIF, including all distributed KIF functionality.
• Maintain documentation detailing the flow of keys from the key generation, through the distributed functionality to the destination device. The documentation should indicate how personnel interaction and inventory management is integrated into the flow.
6A-1.5.a Interview relevant personnel and review documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
6A-1.5.b Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the KIF to verify that all KIF components, key-management flows, and personnel interaction with key-management flows are identified and documented.
6A-1.5.c Examine the key-management flows and interview personnel to verify:
• Maintain current documentation that describes or illustrates the architecture of the KIF, including all distributed KIF functionality.
• Maintain documentation detailing the flow of keys from the key generation, through the distributed functionality to the destination device. The documentation should indicate how personnel interaction and inventory management is integrated into the flow.
6A-1.5.a Interview relevant personnel and review documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
6A-1.5.b Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the KIF to verify that all KIF components, key-management flows, and personnel interaction with key-management flows are identified and documented.
6A-1.5.c Examine the key-management flows and interview personnel to verify:
Removed
p. 218
6B-1.1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Cryptographic keys or key components must be generated by one of the following:
6B-2.1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component.
• There is no unauthorized mechanism that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Domain 6 Annex B Requirements Testing Procedures 6B-1 All keys and key components are generated using an approved random or pseudo-random process.
• An approved key-generation function of a FIPS …
6B-2.1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component.
• There is no unauthorized mechanism that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Domain 6 Annex B Requirements Testing Procedures 6B-1 All keys and key components are generated using an approved random or pseudo-random process.
• An approved key-generation function of a FIPS …
Removed
p. 223
• Faxing, e-mailing, or otherwise conveying clear-text keys or components
Domain 6 Annex B Requirements Testing Procedures 6B-2.6.b From observation of key-management processes verify that key components are not transmitted across insecure channels, including but not limited to:
• Writing key or component values in procedure manual 6B-3 Documented procedures must exist and must be demonstrably in use for all key-generation processing.
6B-3.1 Written key-creation procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. All key-creation events performed by a key-injection facility must be documented. Procedures for creating all keys must be documented.
6B-3.1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations.
6B-3.1.b Interview those responsible for the key-generation processes (including key custodians, supervisory staff, technical management, etc.) to verify that the documented procedures are known and understood by all affected parties.
6B-3.1.c Observe key-generation ceremonies whether actual or …
Domain 6 Annex B Requirements Testing Procedures 6B-2.6.b From observation of key-management processes verify that key components are not transmitted across insecure channels, including but not limited to:
• Writing key or component values in procedure manual 6B-3 Documented procedures must exist and must be demonstrably in use for all key-generation processing.
6B-3.1 Written key-creation procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. All key-creation events performed by a key-injection facility must be documented. Procedures for creating all keys must be documented.
6B-3.1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations.
6B-3.1.b Interview those responsible for the key-generation processes (including key custodians, supervisory staff, technical management, etc.) to verify that the documented procedures are known and understood by all affected parties.
6B-3.1.c Observe key-generation ceremonies whether actual or …
Modified
p. 224 → 134
Keys conveyed to a key-injection facility must be conveyed in compliance with these requirements. Such keys can include, but are not limited to:
Keys conveyed to a key-injection facility (or applicable entity providing key-management services) must be conveyed in compliance with these requirements. Such keys can include, but are not limited to:
Removed
p. 225
• Examine records of key conveyances and interview responsible personnel to verify that cryptographic key components are transferred using different communications channels.
• Examine documented procedures to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
• Examine documented procedures to verify that the SCD is inspected to ensure that there are not any signs of tampering.
• Examine records of key transfers and interview responsible personnel to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
Domain 6 Annex B Requirements Testing Procedures 6C-1.1 Keys must be transferred either encrypted or within an SCD. If clear text outside of an SCD, keys must be transferred as two or more key shares or full-length components using different communication channels, or within an SCD.
• Where key components are transmitted in clear-text using pre-numbered tamper-evident, authenticable mailers: o Components/shares must be conveyed using at …
• Examine documented procedures to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
• Examine documented procedures to verify that the SCD is inspected to ensure that there are not any signs of tampering.
• Examine records of key transfers and interview responsible personnel to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
Domain 6 Annex B Requirements Testing Procedures 6C-1.1 Keys must be transferred either encrypted or within an SCD. If clear text outside of an SCD, keys must be transferred as two or more key shares or full-length components using different communication channels, or within an SCD.
• Where key components are transmitted in clear-text using pre-numbered tamper-evident, authenticable mailers: o Components/shares must be conveyed using at …
Modified
p. 225 → 135
Clear-text key components may be transferred in SCDs or using tamper-evident, authenticable packaging.
Clear-text key components/shares must be conveyed in SCDs or using tamper-evident, authenticable packaging.
Modified
p. 225 → 135
(continued on next page) 6C-1.1.a Determine whether keys are transmitted encrypted, or as clear-text components, or within an SCD.
(continued on next page) 8-1.a Determine whether keys are transmitted encrypted, as clear-text components/shares, or within an SCD.
Modified
p. 225 → 135
8-1.b If key components are transmitted in clear-text using pre-numbered, tamper-evident, authenticable packaging, perform the following:
Modified
p. 225 → 135
The package serial number was transmitted as prescribed The details of the serial number of the package were transmitted separately from the package itself.
Modified
p. 225 → 135
Documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material.
Modified
p. 225 → 136
• Where SCDs are used to convey components, the mechanisms or data (e.g., PIN) to obtain the key component from the SCD must be conveyed using a separate communication channel from the SCD, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
• Where SCDs are used for conveying components/shares, the mechanisms or data (e.g., PIN) to obtain the key component/share from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
Modified
p. 225 → 136
• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package itself.
• Examine documented procedures to verify that the mechanism to obtain the keying material (e.g., PIN) is conveyed using a separate communication channel from the associated SCD.
Modified
p. 225 → 136
• Examine documented procedures to verify that cryptographic-key components are transferred using different communications channels.
• Examine documented procedures to verify that each SCD is inspected to ensure that there are not any signs of tampering.
Modified
p. 225 → 136
8-1.c Where SCDs are used to convey components/shares:
Removed
p. 226
Domain 6 Annex B Requirements Testing Procedures 6C-1.1 (continued)
Where an SCD (HSM or KLD) is conveyed with pre-loaded secret and/or private keys, the SCD must require dual-control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
6C-1.2.a Examine documented procedures to verify they include controls to ensure that no single person can ever have access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. . Verify procedures include:
Where an SCD (HSM or KLD) is conveyed with pre-loaded secret and/or private keys, the SCD must require dual-control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
6C-1.2.a Examine documented procedures to verify they include controls to ensure that no single person can ever have access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. . Verify procedures include:
Modified
p. 226 → 136
• Where an SCD (HSM or KLD) is conveyed with pre- loaded secret and/or private keys, the SCD must require dual-control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
• Where an SCD (i.e., HSM or KLD) is conveyed with pre-loaded secret and/or private keys, the SCD must require dual control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
Modified
p. 226 → 136
Note: Components of encryption keys must be transferred using different communication channels, such as different courier services. It is not sufficient to send key components for a specific key on different days using the same communication channel.
Note: Components/shares of encryption keys must be conveyed using different communication channels, such as different courier services. It is not sufficient to send key components/shares for a specific key on different days using the same communication channel.
Modified
p. 226 → 136
8-1.d Where an SCD is conveyed with pre-loaded secret and/or private keys, perform the following:
Modified
p. 226 → 136
• Examine documented procedures to verify that the SCD is inspected to ensure that there are not any signs of tampering.
• Examine documented procedures to verify that the SCD is inspected to ensure there are no signs of tampering.
Modified
p. 226 → 136
• Examine records of key transfers and interview responsible personnel to verify that the mechanisms make the SCD operational are conveyed using separate communication channels.
• Examine records of key transfers and interview responsible personnel to verify the mechanisms that make the SCD operational are conveyed using separate communication channels.
Modified
p. 226 → 137
E.g., in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such that any three key components or shares (i.e., m = 3) can be used to derive the key, no single individual can have access to more than two components/shares.
Note: An m-of-n scheme is a component- or share- allocation scheme where m is the number of shares or components necessary to form the key, and n is the number of the total set of shares or components related to the key. Management of the shares or components must be sufficient to ensure that no one person can gain access to enough of the item to form the key alone E.g., in an m-of-n scheme (which must use a recognized …
Modified
p. 226 → 137
• Any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other components or shares sufficient to form the necessary threshold to derive the key.
• Reminder that any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component or shares sufficient to form the necessary threshold to derive the key.
Modified
p. 226 → 137
• Any person with access to the media conveying a component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key.
• Steps to ensure any person with access to the media conveying a component/share of a key could not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key, without detection.
Modified
p. 227 → 137
8-2.b Observe key-transfer processes and interview personnel to verify that controls are implemented to ensure that no single person can gain access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. Verify the implemented controls ensure the following:
Modified
p. 227 → 137
• An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
• There is a clear understanding that an individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Modified
p. 227 → 137
• Any person with access to the media conveying a key component or key share must not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
• There is sufficient evidence to show that a person with access to the media conveying a key component or key share could not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key without detection.
Modified
p. 227 → 138
Other similar mechanisms, such as SMS, fax, or telephone shall not be used to convey clear-text key values.
Other similar mechanisms, such as SMS, fax, or telephone must not be used to convey clear-text key values.
Modified
p. 227 → 138
8-3 Validate through interviews, observation, and log inspection that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components/shares.
Removed
p. 228
6C-1.4 For all methods used to convey public keys, perform the following:
• Examine documented procedures for conveying public keys to verify that methods are defined to convey public keys in a manner that protects their integrity and authenticity such as: o Use of public-key certificates created by a trusted CA that meets the requirements of Annex A o A hash of the public key sent by a separate channel (e.g., mail) o Using a MAC (message authentication code) created using the algorithm defined in ISO 16609 o Be within an SCD
• Examine documented procedures for conveying public keys to verify that methods are defined to convey public keys in a manner that protects their integrity and authenticity such as: o Use of public-key certificates created by a trusted CA that meets the requirements of Annex A o A hash of the public key sent by a separate channel (e.g., mail) o Using a MAC (message authentication code) created using the algorithm defined in ISO 16609 o Be within an SCD
Modified
p. 228 → 138
8-4 Public keys must be conveyed in a manner that protects their integrity and authenticity.
Modified
p. 228 → 138
• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A.
• Use of public-key certificates as defined within this Domain that are created by a trusted CA that meets the applicable requirements of this Domain
Modified
p. 228 → 138
• A hash of the public key sent by a separate channel (e.g., mail)
• Validating a hash of the public key sent by a separate channel (e.g., mail)
Modified
p. 228 → 139
8-4.b Validate that procedures dictate that self-signed certificates must not be used as the sole method of authentication.
Modified
p. 228 → 139
8-4.c Observe the process for conveying public keys, associated logs, and interview responsible personnel to verify that the implemented method ensures public keys are conveyed in a manner that protects their integrity and authenticity.
Removed
p. 229
Domain 6 Annex B Requirements Testing Procedures 6C-2 During its transmission, conveyance, or movement between any two organizational entities, any single unencrypted secret or private key component must at all times be protected.
Modified
p. 229 → 140
Sending and receiving entities are equally responsible for the physical protection of the materials involved.
Sending and receiving locations/entities are equally responsible for the physical protection of the materials involved.
Modified
p. 229 → 140
Key components conveyed to and from a key-injection facility must be conveyed in compliance with these requirements. Such key components include but are not limited to those for key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf), or key components for the BDKs themselves, …
Key components/shares conveyed to and from a key-injection facility (or applicable entity providing key-management services) must be conveyed in compliance with these requirements. Such key components/shares include but are not limited to those for key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf), or …
Modified
p. 229 → 140
9-1 During the process to convey it, any single clear-text secret or private key component/share must at all times be either:
Modified
p. 229 → 140
• Locked in a security container (including tamper-evident, authenticable packaging) in such a way that unauthorized access to it would be detected, or
• Sealed in a security container or courier mailer (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access would be detected, or
Modified
p. 229 → 140
Note: No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key.
Note: No single person must be able to access or use all components or a quorum of shares of a single secret or private cryptographic key.
Modified
p. 229 → 140
9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear-text secret or private key component/share must at all times be either:
Modified
p. 229 → 140
• Under the continuous supervision of a person with authorized access to this component,
• Under the continuous supervision of a person with authorized access to this component
Modified
p. 229 → 140
• Under the continuous supervision of a person with authorized access to this component,
• Under the continuous supervision of a person with authorized access to this component
Modified
p. 229 → 140
• Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access to it would be detected, or
• Sealed in a security container or courier mailer (including pre-numbered, tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or
Modified
p. 229 → 140
9-1.b Observe key-management processes, examine associated logs, and interview responsible personnel to verify processes implemented ensure that any single clear-text secret or private key component/share is at all times either:
Modified
p. 229 → 140
• Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access to it would be detected, or
• Sealed in a security container or courier mailer (including pre-numbered tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or contained within a physically secure SCD.
Removed
p. 230
6C-2.2.b Interview responsible personnel and observe processes to verify that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened.
6C-2.3.a Verify that a list(s) of key custodians (and designated backup(s)) authorized to have physical access to key components prior to transmittal or upon receipt of a component is defined and documented.
6C-2.3.b Observe implemented access controls and processes to verify that only those authorized key custodians (and designated backup(s)) have physical access to key components prior to transmittal or upon receipt.
6C-2.3.a Verify that a list(s) of key custodians (and designated backup(s)) authorized to have physical access to key components prior to transmittal or upon receipt of a component is defined and documented.
6C-2.3.b Observe implemented access controls and processes to verify that only those authorized key custodians (and designated backup(s)) have physical access to key components prior to transmittal or upon receipt.
Modified
p. 230 → 141
9-2.b Interview responsible personnel and observe processes to verify that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened.
Modified
p. 230 → 141
9-2.c Verify documented procedures require that any sign of package tampering is identified, reported, and ultimately results in the destruction and replacement of both:
Modified
p. 230 → 141
• Any keys encrypted under this (combined) key 6C-2.2.d Interview responsible personnel and observe processes to verify that, if a package shows signs of tampering, processes are implemented that result in the destruction and replacement of both:
• Any keys encrypted under this (combined) key 9-2.d Interview responsible personnel and observe processes to verify that if a package shows signs of tampering indicating a component was potentially compromised, processes are implemented to identify the tampering, report/escalate it, and ultimately result in the destruction and replacement of both:
Modified
p. 230 → 141
• Any keys encrypted under this (combined) key 6C-2.3 Only the authorized key custodian (and designated backup(s)) shall have physical access to a key component prior to transmittal or upon receipt of a component.
• Any keys encrypted under this (combined) key 9-2.e Examine records related to any escalated transmittal events. Verify that it resulted in the destruction and replacement of both:
Modified
p. 230 → 141
9-3.c Examine physical access logs (e.g., to security containers for key components) to verify that only the authorized individual(s) have access to each component.
Removed
p. 231
Domain 6 Annex B Requirements Testing Procedures 6C-2.4 Mechanisms must exist to ensure that only authorized custodians:
Modified
p. 231 → 142
• Check tamper-evident packaging upon receipt for signs of tamper prior to opening the tamper-evident, authenticable packaging containing key components.
• Check tamper-evident packaging upon receipt for signs of tamper prior to opening tamper-evident authenticable packaging containing key components.
Modified
p. 231 → 142
9-4.a Verify that a list(s) of key custodians authorized to perform the following activities is defined and documented:
Modified
p. 231 → 142
9-4.b Observe implemented mechanisms and processes and examine logs to verify that only the authorized key custodians can perform the following:
Modified
p. 231 → 142
9-5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:
Modified
p. 231 → 142
Note: Numbered courier bags are not sufficient for this purpose 6C-2.5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:
Note: Numbered courier bags are not sufficient for this purpose.
Modified
p. 231 → 142
• Observe the method used to transport clear-text key components using tamper- evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself.
• Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself.
Removed
p. 232
6C-3.1.a Examine documented procedures to verify that all keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed, as delineated in Annex C.
6C-3.1.b Observe key-generation processes to verify that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed, except as noted below for RSA keys used for key transport.
• Verify that: o TDEA keys used for encrypting keys must be at least triple-length keys (have bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment. o A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength. o TDEA keys are not used to protect AES keys. o TDEA keys shall not be used to encrypt keys greater in strength than 112 bits. o …
6C-3.1.b Observe key-generation processes to verify that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed, except as noted below for RSA keys used for key transport.
• Verify that: o TDEA keys used for encrypting keys must be at least triple-length keys (have bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment. o A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength. o TDEA keys are not used to protect AES keys. o TDEA keys shall not be used to encrypt keys greater in strength than 112 bits. o …
Modified
p. 232 → 144
Requirement 10: All key-encryption keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed.
Modified
p. 232 → 144
Key-encryption keys used to convey keys to a key-injection facility must be (at least) as strong as any key transmitted or conveyed. Such keys include but are not limited to, key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf).
Key-encryption keys used to convey keys to a key-injection facility or between locations or systems within the same key-injection facility (or applicable entity providing key-management services) must be at least as strong as any key transmitted or conveyed. Such keys include but are not limited to, key- encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities, locations, or systems (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, …
Modified
p. 232 → 144
10-1 All key-encryption keys used to encrypt for transmittal or conveyance of other cryptographic keys must be at least as strong as the key being sent, as delineated in Annex C., except as noted below for RSA keys used for key transport.
Modified
p. 232 → 144
• A triple-length TDEA key must not be encrypted with a TDEA key of a lesser strength.
• A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength.
Modified
p. 232 → 144
• TDEA keys shall not be used to protect AES keys.
• TDEA keys must not be used to protect AES keys.
Modified
p. 232 → 144
• TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
• TDEA keys must not be used to encrypt keys greater in strength than 112 bits.
Modified
p. 232 → 144
• RSA keys encrypting keys greater in strength than 80 bits shall have bit strength at least 112 bits.
• RSA keys encrypting keys greater in strength than 80 bits must have a bit strength of at least 112 bits.
Modified
p. 232 → 145
• Using the table in Annex C, validate the respective key sizes for TDEA, RSA, Elliptic Curve, DSA, and Diffie Hellman algorithms where used for key encryption.
• Using the table in Annex C, validate the respective key sizes relative to the algorithms used for key encryption.
Modified
p. 232 → 145
10-1.d Examine system documentation and configuration files to validate the above, including HSM settings.
Modified
p. 233 → 146
Requirement 11: Documented procedures must exist and must be demonstrably in use for all key transmission and conveyance processing.
Modified
p. 233 → 146
11-1 Written procedures must exist and be known to all affected parties.
Modified
p. 233 → 146
11-1.a Verify documented procedures exist for all key transmission and conveyance processing.
Modified
p. 233 → 146
11-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for key transmission and conveyance processing.
Modified
p. 233 → 146
11-2 Methods used for the conveyance or receipt of keys must be documented.
Modified
p. 233 → 146
11-2 Verify documented procedures include all methods used for the conveyance or receipt of keys.
Modified
p. 234 → 147
Requirement 12: Secret and private keys must be input into hardware (host) security modules (HSMs) and Point of Interaction (POI) devices in a secure manner:
Modified
p. 234 → 147
Key-injection facilities must load keys using dual control and for clear-text secret and private keys, split knowledge. Such keys include, but are not limited to:
Key-injection facilities (or applicable entities providing key-management services) must load keys using dual control and for clear-text secret and private keys, split knowledge. Such keys include, but are not limited to:
Modified
p. 234 → 147
12-1 The loading of secret or private keys, when from the individual key components or shares, must be performed using the principles of dual control and split knowledge.
Modified
p. 234 → 147
(continued on next page) 12-1.a Using the summary of cryptographic keys, identify keys that are loaded from components and examine documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required.
Modified
p. 234 → 147
12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key.
Modified
p. 234 → 147
12-1.c Witness a structured walk-through/demonstration of various key-loading processes for all key types (MFKs, AWKs, TMKs, PEKs, etc.). Verify the number and length of the key components against information provided through verbal discussion and written documentation.
Removed
p. 235
• usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
6D-1.4.b Examine key-component lengths or device configuration settings to verify that key components used to create a key are the same length as the resultant key.
Domain 6 Annex B Requirements Testing Procedures 6D-1.1.d Verify that the process includes the entry of individual key components by the designated key custodians.
6D-1.3 The loading of clear-text cryptographic keys using a key-loading device requires dual control to authorize any key- loading session. It shall not be possible for a single person to use the key-loading device to load clear keys alone.
6D-1.3.a Examine documented procedures for loading of clear-text cryptographic keys, including public keys, to verify they require dual control to authorize any key-loading session.
6D-1.3.b For all types of production SCDs, observe processes for loading clear-text cryptographic keys, including public keys, to verify that dual control is required to authorize any …
•in a key-loading device) have been disabled or changed.
6D-1.4.b Examine key-component lengths or device configuration settings to verify that key components used to create a key are the same length as the resultant key.
Domain 6 Annex B Requirements Testing Procedures 6D-1.1.d Verify that the process includes the entry of individual key components by the designated key custodians.
6D-1.3 The loading of clear-text cryptographic keys using a key-loading device requires dual control to authorize any key- loading session. It shall not be possible for a single person to use the key-loading device to load clear keys alone.
6D-1.3.a Examine documented procedures for loading of clear-text cryptographic keys, including public keys, to verify they require dual control to authorize any key-loading session.
6D-1.3.b For all types of production SCDs, observe processes for loading clear-text cryptographic keys, including public keys, to verify that dual control is required to authorize any …
Modified
p. 235 → 148
12-1.e Ensure key-loading devices can only be accessed and used under dual control.
Modified
p. 235 → 148
12-2 Procedures must be established that will prohibit any one person from having access to components sufficient to form an encryption key when components are removed from and returned to storage for key loading.
Modified
p. 235 → 148
12-2.a. Examine logs of access to security containers for key components/shares to verify that only the authorized custodian(s) have accessed. Compare the number on the current tamper-evident and authenticable package for each component to the last log entry for that component.
Modified
p. 235 → 149
• Two or more passwords of five characters or more (vendor default values must be changed),
• Two or more passwords/authentication codes of five characters or more (vendor default values must be changed)
Modified
p. 235 → 149
• Multiple cryptographic tokens (such as smartcards), or physical keys,
• Multiple cryptographic tokens (such as smartcards), or physical keys
Modified
p. 235 → 150
Note: For devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. Each half must be a minimum of five characters.
Modified
p. 235 → 150
12-3.c Examine documented records of key-loading to verify the presence of two authorized persons during each type of key-loading activity.
Modified
p. 235 → 150
12-3.d Ensure that any default dual-control mechanisms (e.g., default passwords/authentication codes
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
Modified
p. 235 → 150
12-4 Key components for symmetric keys must be combined using a process such that no active bit of the key can be determined without knowledge of the remaining components⎯e.g., via XOR‘ing of full-length components.
Modified
p. 235 → 150
12-4.a Examine documented procedures for combining symmetric-key components and observe processes to verify that key components are combined using a process such that no active bit of the key can be determined without knowledge of the remaining components⎯e.g., only within an SCD.
Removed
p. 236
6D-1.7.b Examine documented procedures to verify that keys are prohibited from reloading or reuse wherever suspected of being compromised and are withdrawn from use.
Domain 6 Annex B Requirements Testing Procedures 6D-1.5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least triple-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits.
Domain 6 Annex B Requirements Testing Procedures 6D-1.5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least triple-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits.
Modified
p. 236 → 151
12-5 Examine vendor documentation describing options for how the HSM MFK is created and verify the current MFK was created using AES (or double- or triple-length TDEA for existing implementations only). Corroborate this via observation of processes, with information gathered during the interview process, and procedural documentation provided by the entity under review.
Modified
p. 236 → 151
12-6 Any other SCD loaded with the same key components must combine all entered key components using the identical process.
Modified
p. 236 → 151
12-7 The initial terminal master key (TMK) or initial DUKPT key must be loaded to the device using either asymmetric key-loading techniques or manual techniques•e.g., the device keypad, IC cards, key- loading device, etc. Subsequent loading of the terminal master key or an initial DUKPT key may use techniques described in this document such as:
Modified
p. 236 → 151
• Asymmetric techniques
• Asymmetric techniques;
Modified
p. 236 → 151
• The existing TMK to encrypt the replacement TMK for download.
• The existing TMK to encrypt the replacement TMK for download;
Modified
p. 236 → 151
Keys shall not be reloaded by any methodology in the event of a compromised device, and must be withdrawn from use.
Keys must not be reloaded by any methodology in the event of a compromised device and must be withdrawn from use.
Modified
p. 236 → 151
12-7.a Examine documented procedures for the loading of TMKs and initial DUKPT keys to verify that they require asymmetric key-loading techniques or manual techniques for initial loading and allowed methods for replacement TMK or initial DUKPT key loading.
Removed
p. 237
Domain 6 Annex B Requirements Testing Procedures 6D-1.8 If key-establishment protocols using public-key cryptography are used to remotely distribute secret keys, these must meet the requirements detailed in Annex A of this document. For example:
Modified
p. 237 → 152
• Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device actually has (or actually can) compute the session key and that no entity other than the POI device specifically identified can possibly compute the session key.
• Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device has (or can compute) the session key, and that no entity other than the POI device specifically identified can possibly compute the session key.
Modified
p. 237 → 152
12-8.a For techniques involving public-key cryptography, examine documentation to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication for both the host and the POI device.
Modified
p. 237 → 152
12-8.b If key-establishment protocols using public-key cryptography are used to remotely distribute secret keys, verify that the applicable requirements detailed in this Domain are met, including:
Modified
p. 237 → 152
• Use of public and private key lengths that are in accordance with Annex C for the algorithm in question .
• Use of public and private key lengths that are in accordance with Annex C for the algorithm in question.
Modified
p. 238 → 153
• Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to key injection such that the badge-access system enforces the presence of at least two authorized individuals at all times in the room so no one person can singly access the key- loading equipment. Access is restricted to only appropriate personnel involved in the key-loading process
• Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to key injection such that the badge- access system enforces the presence of at least two authorized individuals at all times in the room so no one person can singly access the key-loading equipment. Access is restricted to only appropriate personnel involved in the key-loading process
Modified
p. 238 → 153
• Key-injection platform applications that force the entry of multiple key components and the implementation of procedures that involve multiple key custodians who store and access key components under dual-control and split- knowledge mechanisms
• Key-injection platform applications that force the entry of multiple key components and the implementation of procedures that involve multiple key custodians who store and access key components under dual-control and split-knowledge mechanisms
Modified
p. 238 → 153
• Demonstrable procedures that prohibit key custodians from handing their components to any other individual for key entry 6D-1.9.a Examine documented key-injection procedures to verify that the procedures define use of dual control and split knowledge controls for the loading of keys into devices.
• Demonstrable procedures that prohibit key custodians from handing their components to any other individual for key entry
Modified
p. 238 → 153
12-9.b Interview responsible personnel and observe key-loading processes and controls to verify that dual control and split-knowledge controls are in place for the loading of keys into devices.
Modified
p. 238 → 153
12-9.c Examine records of key-loading processes and controls to verify that the loading of keys does not occur without dual control and split knowledge.
Modified
p. 239 → 154
•such
•must
Requirement 13: The mechanisms used to load secret and private keys•such as terminals, external PIN pads, key guns, or similar devices and methods•must be protected to prevent any type of monitoring that could result in the unauthorized disclosure of any component.
Modified
p. 239 → 154
Key-injection facilities must ensure key-loading mechanisms are not subject to disclosure of key components or keys.
Key-injection facilities (or applicable entities providing key-management services) must ensure key-loading mechanisms are not subject to disclosure of key components or keys.
Modified
p. 239 → 154
Some key-injection platforms use personal-computer (PC)-based software applications, whereby clear-text secret and/or private keys and/or their components exist in unprotected memory outside the secure boundary of an SCD for loading keys. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. These weaknesses include:
Some key-injection platforms use personal-computer (PC)-based software applications, whereby clear-text secret and/or private keys and/or their components exist in memory outside the secure boundary of an SCD for loading keys. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. These weaknesses include:
Removed
p. 240
• The SCD must be inspected prior to use to ensure that it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying materials.
• Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: o SCDs must be inspected to detect evidence of monitoring and to ensure dual- control procedures are not circumvented during key loading. o An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device. o There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys. o The SCD is inspected to ensure it has not been subject to …
• Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: o SCDs must be inspected to detect evidence of monitoring and to ensure dual- control procedures are not circumvented during key loading. o An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device. o There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys. o The SCD is inspected to ensure it has not been subject to …
Modified
p. 240 → 155
• SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.
• SCDs must be inspected to detect evidence of monitoring and to ensure dual control procedures are not circumvented during key loading.
Modified
p. 240 → 155
13-1 Observe key-loading environments, processes, and mechanisms (e.g., terminals, PIN pads, key guns, etc.) used to transfer keys and key components. Perform the following:
Modified
p. 240 → 155
• Ensure that any cameras that are present are positioned to ensure they cannot monitor the entering of clear-text key components.
• Ensure cameras are positioned to ensure they cannot monitor the entering of clear- text key components.
Modified
p. 240 → 156
13-2.b Observe a demonstration of key loading to verify that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key- loading facility.
Removed
p. 241
• Instructions to erase or otherwise destroy all traces of the component from the electronic medium.
• All traces of the component are erased or otherwise destroyed from the electronic medium.
6D-2.4.2 Verify the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it.
Domain 6 Annex B Requirements Testing Procedures 6D-2.3 The loading of secret or private key components from an electronic medium to a cryptographic device (and verification of the correct receipt of the component, if applicable) results in either of the following:
6D-2.3 Examine documented procedures for the loading of secret or private key components from an electronic medium to a cryptographic device. Verify that procedures define specific instructions to be followed as a result of key loading, including:
6D-2.3 Observe key-loading processes to verify that the loading process results in one of the …
• All traces of the component are erased or otherwise destroyed from the electronic medium.
6D-2.4.2 Verify the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it.
Domain 6 Annex B Requirements Testing Procedures 6D-2.3 The loading of secret or private key components from an electronic medium to a cryptographic device (and verification of the correct receipt of the component, if applicable) results in either of the following:
6D-2.3 Examine documented procedures for the loading of secret or private key components from an electronic medium to a cryptographic device. Verify that procedures define specific instructions to be followed as a result of key loading, including:
6D-2.3 Observe key-loading processes to verify that the loading process results in one of the …
Modified
p. 241 → 157
13-4 For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device:
Modified
p. 241 → 157
13-4 Examine documented procedures and observe processes for the use of key-loading devices. Perform the following:
Modified
p. 241 → 157
13-4.1 The key-loading device must be a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
Modified
p. 241 → 157
13-4.1 Verify the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
Modified
p. 241 → 158
13-4.2 Verify the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it.
Modified
p. 241 → 158
13-4.3 The key-loading device must be designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel must ensure that a key- recording device is not inserted between the SCDs.
Modified
p. 241 → 158
13-4.3.a Verify the key-loading device is designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD.
Modified
p. 241 → 158
13-4.3.b Verify that both authorized personnel involved in key-loading activity inspect the key-loading device, prior to use to ensure that a key-recording device has not been inserted between the SCDs.
Removed
p. 242
• from the secure storage location. Verify procedures include the following:
6D-2.5 Any media (electronic or otherwise) containing secret or private key components used for loading cryptographic keys must be maintained in a secure storage location and accessible only to authorized custodian(s).
6D-2.6 Validate through interview and observation that, if components are in human- readable form, they are visible only to the designated key-component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
6D-2.5 Any media (electronic or otherwise) containing secret or private key components used for loading cryptographic keys must be maintained in a secure storage location and accessible only to authorized custodian(s).
6D-2.6 Validate through interview and observation that, if components are in human- readable form, they are visible only to the designated key-component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
Modified
p. 242 → 158
13-4.4 The key-loading device must not retain any information that might disclose the key (e.g., allow replay of the key for injection into a non-SCD) that was installed in the device or a key that it has successfully transferred.
Modified
p. 242 → 158
13-4.4 Verify the key-loading device does not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred. For example, attempt to output the same value more than one time from the device or cause the device to display check values for its contents both before and after injection and compare.
Modified
p. 242 → 159
Key components that can be read/displayed (e.g., those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in clear text to a non-custodian for that component.
Key components that can be read (e.g., those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in clear-text to anyone who is not a designated custodian for that component.
Modified
p. 242 → 159
13-5.a Interview personnel and observe media locations to verify that the media is maintained in a secure location accessible only to custodian(s) authorized to access the key components.
Modified
p. 242 → 159
•or that are otherwise used for the injection of cryptographic keys
13-5.b Examine documented procedures for removing media or devices containing key components
•or that are otherwise used for the injection of cryptographic keys •from the secure storage location. Verify procedures include the following:
•or that are otherwise used for the injection of cryptographic keys •from the secure storage location. Verify procedures include the following:
Modified
p. 242 → 159
• Requirement that media/devices are in the physical possession of only the designated component holder(s).
• Requirement that media/devices be in the physical possession of only the designated component holder(s).
Modified
p. 242 → 159
13-5.c Interview designated component holder(s) and examine key-management logs to verify that media or devices removed from secure storage are in the physical possession of only the designated component holder(s).
Modified
p. 242 → 159
13-5.d Interview key-injection personnel and examine logs for the removal of media/devices from secure storage to verify they are removed only for the minimum practical time necessary to complete the key-loading process.
Modified
p. 242 → 159
13-6 If the component is in human-readable form it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
Modified
p. 242 → 159
13-7 Written or printed key component documents must not be opened until immediately prior to use.
Modified
p. 242 → 159
13-7.a Examine documented procedures and confirm that printed/written key component documents are not opened until immediately prior to use.
Modified
p. 242 → 159
13-7.b Observe key-loading processes and verify that printed/written key component documents are not opened until immediately prior to use.
Removed
p. 243
6D-2.9.1 PCs and similar devices must be:
Modified
p. 243 → 160
13-8.a Examine documented procedures for the use of key components to verify that procedures ensure that any individual custodian only has access to their assigned components and never has access to sufficient key components to reconstruct a cryptographic key.
Modified
p. 243 → 160
13-8.b Examine key-component access controls and access logs to verify that any single authorized custodian can and has only had access to their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key.
Modified
p. 243 → 160
13-9 Key-injection facilities that use PC-based key- loading software platforms or similar devices (e.g., modified PEDs) that allow clear-text secret and/or private keys and/or their components to exist in memory outside the secure boundary of an SCD must minimally implement the following additional controls:
Modified
p. 243 → 160
13-9 Interview appropriate personnel and examine documentation to determine the procedures for key loading to POIs, key-loading devices, and HSMs that are part of the key-loading platform. Examine any logs of key loading.
Modified
p. 243 → 161
• Located in a physically secure room that is dedicated to key-loading activities.
• Located in a physically secure room meeting the criteria of Requirement 32-9 that is dedicated to key-loading activities.
Modified
p. 243 → 161
13-9.1 For facilities using PC-based key-loading software platforms or similar devices, verify through interviews and observation that the platform is:
Removed
p. 244
• Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals.
Modified
p. 244 → 161
• Located in a physically secure room meeting the criteria of Requirement 32-9 that is dedicated to key loading activities 13-9.2 All hardware used in key loading (including the PC) must be managed under dual control. Key-injection must not occur unless there are minimally two individuals in the key-injection room at all times during the process. If a situation arises that would cause only one person to be in the room, all individuals must exit until at least two can …
Modified
p. 244 → 161
13-9.2 Verify through interviews and observation that:
Modified
p. 244 → 161
• Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process.
• Key-injection cannot occur unless there are minimally two individuals in the key- injection room at all times during the process. Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals.
Modified
p. 244 → 162
• User sign-on logs on the PC at the operating-system level;
• User sign-on logs on the PC at the operating- system level;
Modified
p. 244 → 162
13-9.3.a Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
Modified
p. 244 → 162
13-9.3.b Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
Modified
p. 244 → 162
− Access to the room from a badge access system, − Access to the room from a manual sign-in sheet, − User sign-on logs on the PC at the operating system level, − User sign-on logs on the PC at the application level, − Logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key-injection, − Video surveillance logs with a minimum retention period of 45 days.
Removed
p. 245
6D-2.9.4.2 The key-loading device is started from a powered-off position every time key-loading activities occur.
Modified
p. 245 → 162
13-9.4 Additionally: 13-9.4 Verify through interviews and observation that:
Modified
p. 245 → 162
13-9.4.1 Cable attachments and the key-loading device must be examined before each use to ensure the equipment is free from tampering.
Modified
p. 245 → 162
13-9.4.1 Cable attachments and the key-loading device are examined before each use to ensure the equipment is free from tampering.
Modified
p. 245 → 163
13-9.4.2 The key-loading device is started from a powered-off position every time key- loading activities occur.
Modified
p. 245 → 163
13-9.4.3 The software application must load keys without recording any clear-text values on portable media or other unsecured devices.
Modified
p. 245 → 163
13-9.4.3 The software application loads keys without recording any clear-text values on portable media or other unsecured devices.
Modified
p. 245 → 163
13-9.4.4 Clear-text keys must not be stored except within an SCD.
Modified
p. 245 → 163
13-9.4.4 Clear-text keys are not stored except within an SCD.
Modified
p. 245 → 163
•they must be escorted by authorized key-injection personnel
•and they must not have user IDs or
13-9.4.5 The personnel responsible for the systems administration of the PC (e.g., a Windows administrator who configures the PC’s user IDs and file settings, etc.) must not have authorized access into the room
•they must be escorted by authorized key-injection personnel
•and they must not have user IDs or passwords/authentication codes to operate the key-injection application.
•they must be escorted by authorized key-injection personnel
•and they must not have user IDs or passwords/authentication codes to operate the key-injection application.
Modified
p. 245 → 163
•i.e., they are escorted by authorized
•and do not have user IDs or
13-9.4.5 Personnel responsible for the systems administration of the PC do not have authorized access into the room
•i.e., they are escorted by authorized key-injection personnel
•and do not have user IDs or passwords/authentication codes to operate the key-injection application.
•i.e., they are escorted by authorized key-injection personnel
•and do not have user IDs or passwords/authentication codes to operate the key-injection application.
Modified
p. 245 → 163
13-9.4.6 The key-injection personnel must not have system-administration capability at either the O/S or the application level on the PC.
Modified
p. 245 → 163
13-9.4.6 Key-injection personnel do not have system-administration capability at either the O/S or the application level on the PC.
Modified
p. 245 → 163
13-9.4.7 The PC must not be able to boot from external media (e.g., USB devices or CDs). It must boot from the hard drive only.
Modified
p. 245 → 163
13-9.4.7 The PC is not able to boot from external media (e.g., USB devices or CDs). It must boot from the hard drive only.
Modified
p. 246 → 164
13-9.4.8 All openings on the PC that are not used for key-injection are covered with security seals that are tamper-evident and serialized. The seals are recorded in a log, and the log is maintained along with the other key-loading logs in a dual-control safe. Verification of the seals must be performed prior to key-loading activities.
Modified
p. 246 → 164
13-9.4.9 If the PC application stores clear-text key components (e.g., BDKs or TMKs) on portable electronic media (e.g., smart cards), the media must be secured as components under dual control when not in use. The key components must be manually entered at the start of each key-injection session from components that are maintained under dual control and split knowledge.
Modified
p. 246 → 164
Note: For DUKPT implementations, the BDK should be loaded from components each time and this requires manual tracking of the device ID counter and serial numbers from the previous key-loading session. Key- injection facilities with PC applications that require passwords to be used to initiate decryption of keys on portable electronic media (e.g., smart cards) must ensure the passwords are maintained under dual control and split knowledge.
Note: For DUKPT implementations, the BDK must be loaded from components each time and this requires manual tracking of the device ID counter and serial numbers from the previous key-loading session. Key-injection facilities with PC applications that require passwords/authentication codes to be used to initiate decryption of keys on portable electronic media (e.g., smart cards) must ensure the passwords/authentication codes are maintained under dual control and split knowledge.
Modified
p. 246 → 164
13-9.4.9 If the PC application stores keys (e.g., BDKs or TMKs) on portable electronic media (e.g., smart cards), the media is secured as components under dual control when not in use. The key components are manually entered at the start of each key- injection session from components that are maintained under dual control and split knowledge.
Modified
p. 246 → 164
13-9.4.10 Manufacturer’s default passwords/authentication codes for PC-based applications must be changed.
Modified
p. 246 → 164
13-9.4.10 Manufacturer’s default passwords/authentication codes for PC-based applications are changed.
Removed
p. 247
6D-3.2 All cable attachments must be examined before each key-loading operation to ensure they have not been tampered with or compromised.
6D-3.2.a Review documented procedures to ensure they require that cable attachments be examined prior to key-loading function.
6D-3.3 Key-loading equipment usage must be monitored and a log of all key-loading activities maintained for audit purposes containing at a minimum date, time, personnel involved, and number of devices keys are loaded to.
6D-3.2.a Review documented procedures to ensure they require that cable attachments be examined prior to key-loading function.
6D-3.3 Key-loading equipment usage must be monitored and a log of all key-loading activities maintained for audit purposes containing at a minimum date, time, personnel involved, and number of devices keys are loaded to.
Modified
p. 247 → 165
Requirement 14: All hardware and access/authentication mechanisms (e.g., passwords/authentication codes) used for key loading or the signing of authenticated applications (e.g., for “whitelists”) must be managed under dual control.
Modified
p. 247 → 165
Key-injection facilities must ensure that the key-injection application passwords and associated user IDs are managed in such a way as to enforce dual control. Also, the hardware used for key-injection must be managed under dual control. Vendor default passwords must be changed.
Key-injection facilities (or applicable entities providing key-management services) must ensure that the key-injection application passwords/authentication codes and associated user IDs are managed in such a way as to enforce dual control. Also, the hardware used for key- injection must be managed under dual control. Vendor default passwords/authentication codes must be changed.
Modified
p. 247 → 165
14-1 Any hardware and passwords/authentication codes used in the key-loading function or for the signing of authenticated applications must be controlled and maintained in a secure environment under dual control. Resources (e.g., passwords/authentication codes and associated hardware) must be managed such that no single individual has the capability to enable key loading of clear-text keys or their components. This is not to imply that individual access authentication mechanisms must be managed under dual control.
Modified
p. 247 → 165
14-1.a Examine documented procedures to verify they require the following:
Modified
p. 247 → 165
• Any hardware used in the key-loading function must be controlled and maintained in a secure environment under dual control.
• Any hardware used in the key-loading function or for the signing of authenticated applications must be controlled and maintained in a secure environment under dual control.
Modified
p. 247 → 165
• Any resources (e.g., passwords and associated hardware) used in the key- loading function must be controlled and managed such that no single individual has the capability to enable key loading.
• Any resources (e.g., passwords/authentication codes and associated hardware) used in the key-loading function or for the signing of authenticated applications must be controlled and managed such that no single individual has the capability to enable key loading of clear-text keys or their components.
Modified
p. 247 → 165
14-1.b Observe key-loading environments and controls to verify the following:
Modified
p. 247 → 165
• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control.
• All hardware used in the key-loading function or for the signing of authenticated applications is controlled and maintained in a secure environment under dual control.
Modified
p. 247 → 165
• All resources (e.g., passwords and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading.
• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions and for the signing of authenticated applications are controlled and managed such that no single individual has the capability to enable key loading.
Modified
p. 247 → 166
14-2.b Observe key-loading processes to verify that all cable attachments are properly examined at the beginning of an entity’s key-activity operations (system power on/authorization) or application-signing operations.
Modified
p. 247 → 167
14-3.a Observe key-loading and application-signing activities to verify that key-loading equipment usage is monitored.
Modified
p. 247 → 167
14-3.b Verify logs of all key-loading and application-signing activities are maintained and contain all required information.
Removed
p. 248
6D-3.5.b Verify that documented procedures exist to require that these passwords/PINs be changed when assigned personnel change.
Domain 6 Annex B Requirements Testing Procedures 6D-3.4 Any physical tokens (e.g., brass keys or chip cards) used to enable key-loading must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control. These tokens must be secured in a manner similar to key components including the use of access-control logs for when removed or placed into secure storage.
Domain 6 Annex B Requirements Testing Procedures 6D-3.4 Any physical tokens (e.g., brass keys or chip cards) used to enable key-loading must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control. These tokens must be secured in a manner similar to key components including the use of access-control logs for when removed or placed into secure storage.
Modified
p. 248 → 167
14-4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key loading or the signing of authenticated applications. Verify procedures require that physical tokens must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.
Modified
p. 248 → 167
14-4.b Inspect locations and controls for physical tokens to verify that tokens used to enable key loading or the signing of authenticated applications are not in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.
Modified
p. 248 → 167
14-4.c Examine storage locations for physical tokens to determine adequacy to ensure that only the authorized custodian(s) can access their specific tokens.
Modified
p. 248 → 167
14-4.d Verify that access-control logs exist and are in use including notation of tamper- evident, authenticable bag numbers.
Modified
p. 248 → 167
14-4.e Reconcile storage contents to access-control logs.
Modified
p. 248 → 167
14-5.b Verify that documented procedures exist to require that these passwords/authentication codes be changed when assigned personnel change.
Modified
p. 248 → 167
14-5.a Verify that documented procedures require default passwords/authentication codes used to enforce dual-control mechanisms are changed.
Modified
p. 248 → 168
Requirement 15: The loading of keys or key components must incorporate a validation mechanism such that the authenticity of the keys is ensured and it can be ascertained that they have not been tampered with, substituted, or compromised.
Modified
p. 248 → 168
15-1 A cryptographic-based validation mechanism must be in place to ensure the authenticity and integrity of keys and/or their components (e.g., testing key-check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO 11568. Where check values are used, recorded, or displayed key-component check values and key-check values must be generated by a cryptographic process such that all portions of the key or key component are involved in generating the …
Modified
p. 248 → 168
15-1.a Examine documented procedures to verify a cryptographic-based validation mechanism is in place to ensure the authenticity and integrity of keys and/or components.
Modified
p. 248 → 168
15-1.b Observe the key-loading processes to verify that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians.
Modified
p. 248 → 168
15-1.c Verify that the methods used for key validation are consistent with ISO 11568•e.g., when check values are used, they are in accordance with this requirement.
Removed
p. 249
Domain 6 Annex B Requirements Testing Procedures 6D-4.2 The public key must have its authenticity and integrity ensured. In order to ensure authenticity and integrity, a public key must be encrypted, or if in plaintext form, must:
• Be within a PKCS#10; or
• Be within a PKCS#10; or
Modified
p. 249 → 169
• Be within a certificate as defined in Annex A; or
• Be within a certificate as defined in applicable requirements within this Domain; or
Modified
p. 249 → 169
15-2.a Interview personnel and review documented procedures to verify that all public keys exist only in an approved form.
Modified
p. 249 → 169
15-2.b Observe public-key stores and mechanisms to verify that public keys exist only in an approved form.
Modified
p. 249 → 170
Requirement 16: Documented procedures must exist and be demonstrably in use (including audit trails) for all key-loading activities.
Modified
p. 249 → 170
16-1 Documented key-loading procedures must exist for all devices (e.g., HSMs and POI devices), and all parties involved in cryptographic key loading must be aware of those procedures.
Modified
p. 249 → 170
16-1.a Verify documented procedures exist for all key-loading operations.
Modified
p. 249 → 170
16-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for all key-loading operations.
Modified
p. 249 → 170
16-1.c Observe the key-loading process for keys loaded as components and verify that the documented procedures are demonstrably in use. This may be done as necessary on test equipment•e.g., for HSMs.
Modified
p. 249 → 170
16-2 All key-loading events must be documented. Audit trails must be in place for all key-loading events.
Modified
p. 249 → 170
16-2 Examine log files and observe logging processes to verify that audit trails are in place for all key-loading events.
Removed
p. 250
Domain 6 Annex B Requirements Testing Procedures 6E-2 Procedures must exist to prevent or detect the unauthorized substitution (unauthorized key replacement and key misuse) of one key for another key or the operation of any cryptographic device without legitimate keys.
6E-2.2 To prevent or detect usage of a compromised key, key- component packaging or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
6E-2.2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering must result in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
6E-2.2.b Interview personnel and observe processes to verify procedures are implemented to require that key-component packaging/containers showing signs of tampering result in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all …
6E-2.2 To prevent or detect usage of a compromised key, key- component packaging or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
6E-2.2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering must result in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
6E-2.2.b Interview personnel and observe processes to verify procedures are implemented to require that key-component packaging/containers showing signs of tampering result in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all …
Modified
p. 250 → 175
18-6.a Examine documented key-injection procedures to verify that controls are defined to prevent and detect the loading of keys by any one single person.
Modified
p. 250 → 175
•e.g., viewing CCTV images
•are implemented to prevent and detect the loading of keys by any one single person.
18-6.b Interview responsible personnel and observe key-loading processes and controls to verify that controls
•e.g., viewing CCTV images
•are implemented to prevent and detect the loading of keys by any one single person.
•e.g., viewing CCTV images
•are implemented to prevent and detect the loading of keys by any one single person.
Modified
p. 250 → 175
18-7 Key-injection facilities must implement controls to protect against the unauthorized substitution of keys and to prevent the operation of devices without legitimate keys.
Modified
p. 250 → 175
• Key-injection facilities must use something unique about the POI (e.g., logical identifiers) when deriving the key (e.g., DUKPT, TMK) injected into it.
• Key-injection facilities must use something unique about the POI (e.g., logical identifiers) when deriving the key (e.g., DUKPT, TMK) injected into it 18-7.a Examine documented procedures to verify they include:
Modified
p. 250 → 175
18-7.b Interview responsible personnel and observe key-loading processes and controls to verify that:
Removed
p. 251
6E-3.2 Private keys must only be used as follows:
6E-3.1 Encryption keys must be used only for the purpose they were intended (i.e., key-encryption keys must not to be used as PIN-encryption keys, PIN-encryption keys must not be used for account data, etc.). This is necessary to limit the magnitude of exposure should any key(s) be compromised. Using keys only as they are intended also significantly strengthens the security of the underlying system.
6E-3.1 Encryption keys must be used only for the purpose they were intended (i.e., key-encryption keys must not to be used as PIN-encryption keys, PIN-encryption keys must not be used for account data, etc.). This is necessary to limit the magnitude of exposure should any key(s) be compromised. Using keys only as they are intended also significantly strengthens the security of the underlying system.
Modified
p. 251 → 176
Requirement 19: Cryptographic keys must be used only for their sole intended purpose and must never be shared between production and test systems.
Modified
p. 251 → 176
• Where test keys are used, key-injection facilities must use a separate test system for the injection of test keys.
• Where test keys are used, key-injection facilities (or applicable entities providing key-management services) must use a separate test system for the injection of test keys.
Modified
p. 251 → 176
19-1.a Examine key-management documentation (e.g., the cryptographic-key inventory) and interview key custodians and key-management supervisory personnel to verify that cryptographic keys are defined for a specific purpose.
Modified
p. 251 → 176
19-1.b Using a sample of device types, validate via examination of check values, terminal definition files, etc. that keys used for key encipherment or PIN encipherment are not used for any other purpose.
Modified
p. 251 → 177
• For a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both (except fortransaction-originating POI devices).
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for
• Must be used only for a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction- originating POI devices).
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction- originating POI devices).
Modified
p. 251 → 177
• Private keys shall never be used to encrypt other keys.
• Must never be used to encrypt other keys.
Modified
p. 251 → 177
19-2 Examine key-management documentation and interview key custodians and key- management supervisory personnel to verify that private keys are :
Modified
p. 251 → 177
• To create digital signatures or to perform decryption operations.
• Used only to create digital signatures or to perform decryption operations.
Modified
p. 251 → 177
• For a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but notboth (except for POI devices).
•a private key must only be used for either decryption or for creating digital signatures, but not
• Used only for a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both.
•a private key must only be used for either decryption or for creating digital signatures, but not both.
Modified
p. 251 → 177
• Private keys are never used to encrypt other keys.
• Never used to encrypt other keys.
Modified
p. 251 → 177
19-3 Public keys must only be used for a single purpose• a public key must only be used for either encryption or for verifying digital signatures, but not both (except for transaction-originating POI devices).
Modified
p. 251 → 177
19-3 Examine key-management documentation and interview key custodian and key- management supervisory personnel to verify that public keys are only used:
Removed
p. 252
Domain 6 Annex B Requirements Testing Procedures 6E-3.4 Keys must never be shared or substituted between production and test/development systems:
6E-3.5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the key-injection server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements.
6E-3.5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the key-injection server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements.
Modified
p. 252 → 178
• Key used for production keys must never be present or used in a test system, and
• Keys used for production must never be present or used in a test/development system, and
Modified
p. 252 → 178
• Keys used for testing keys must never be present or used in a production system.
• Keys used for testing must never be present or used in a production system.
Modified
p. 252 → 178
19-4.a Examine key-management documentation and interview key custodians and key- management supervisory personnel to verify that cryptographic keys are never shared or substituted between production and test/development systems.
Modified
p. 252 → 178
19-4.b Observe processes for generating and loading keys into production systems to ensure that they are in no way associated with test or development keys.
Modified
p. 252 → 178
19-4.c Observe processes for generating and loading keys into test systems to ensure that they are in no way associated with production keys.
Modified
p. 252 → 178
19-4.d Compare check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.
Modified
p. 252 → 178
At all times the HSMs and servers/computers must be physically and logically secured in accordance with these requirements.
At all times, the HSMs and servers/computers must be physically and logically secured in accordance with these requirements.
Modified
p. 252 → 178
Note: This does not apply to HSMs that are never intended to be used for production.
Modified
p. 252 → 178
19-5 Interview personnel to determine whether production platforms are ever temporarily used for test purposes.
Modified
p. 252 → 178
• Subsequent to completion of testing, all keying materials must be deleted and the server/computer platforms must be wiped and rebuilt from read-only media,
• Subsequent to completion of testing, all keying materials must be deleted and the server/computer platforms must be wiped and rebuilt from read-only media.
Modified
p. 252 → 178
• Prior to reuse for production purposes the HSM is returned to factory state,
• Prior to reuse for production purposes the HSM is returned to factory state.
Removed
p. 253
6E-4.2 Determine whether POI devices are intended to interface with multiple entities for decryption. If so:
• Examine documented procedures for generating all types of keys and verify the procedures ensure that unique keys, or sets of keys, are used for each acquiring organization and are totally independent and not variants of one another.
• Examine documented procedures for generating all types of keys and verify the procedures ensure that unique keys, or sets of keys, are used for each acquiring organization and are totally independent and not variants of one another.
Modified
p. 253 → 183
Requirement 20: All secret and private cryptographic keys ever present and used for any function (e.g., key encipherment or account-data encipherment) by a POI device that processes account data must be unique (except by chance) to that device.
Modified
p. 253 → 183
20-1 POI devices must each implement unique secret and private keys for any function directly or indirectly related to account-data protection. These keys must be known only in that device and in hardware security modules (HSMs) at the minimum number of facilities consistent with effective system operations.
Modified
p. 253 → 183
This means that not only the account-data-encryption key(s), but also keys that are used to protect other keys: firmware- authentication keys, payment application authentication, and display prompt control keys. As stated in the requirement, this does not apply to public keys resident in the device.
This means not only the account-data-encryption key(s), but also keys that are used to protect other keys, firmware- authentication keys, payment-application authentication and display-prompt control keys. As stated in the requirement, this does not apply to public keys resident in the device.
Modified
p. 253 → 183
20-1.a Examine documented procedures for the loading and usage of all keys used in transaction-originating POI devices. Verify the procedures ensure that all private and secret keys used in transaction-originating POI devices are:
Modified
p. 253 → 183
20-1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POI devices to verify that unique keys are generated and used for each POI device.
Modified
p. 253 → 183
20-1.c Examine check values, hash, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI device vendor used) to determine that the associated private keys stored in the POI devices are unique per device•i.e., the public keys are unique.
Modified
p. 253 → 183
20-2 If a POI device directly interfaces with more than one entity for decryption of account data (e.g., different acquiring organizations), the POI device must have a completely different and unique key or set of keys for each acquirer. These different keys, or sets of keys, must be totally independent and not variants of one another.
Modified
p. 253 → 183
20-2.b Interview personnel and observe key-generation processes to verify that unique keys or sets of keys will be generated for each acquiring organization when required.
Removed
p. 254
6E-4.4.a Examine documented key-generation and injection procedures to verify that the following is required when injecting keys into a single POI for more than one acquiring organization:
• The POI must have a completely different and unique key, or set of keys, for each acquiring organization.
• These different keys, or sets of keys, must be totally independent and not variants of one another.
6E-4.4.b Observe processes for generation and injection of keys into a single POI for more than one acquiring organization, to verify:
• The POI has a completely different and unique key, or set of keys, for each acquiring organization.
• These different keys, or sets of keys, are totally independent and not variants of one another.
• The POI must have a completely different and unique key, or set of keys, for each acquiring organization.
• These different keys, or sets of keys, must be totally independent and not variants of one another.
6E-4.4.b Observe processes for generation and injection of keys into a single POI for more than one acquiring organization, to verify:
• The POI has a completely different and unique key, or set of keys, for each acquiring organization.
• These different keys, or sets of keys, are totally independent and not variants of one another.
Modified
p. 254 → 184
This requirement refers to the use of a single “base” key to derive master keys for many different POIs, using a key- derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for derivation of other keys once loaded, e.g., as done with DUKPT.
This requirement refers to the use of a single “base” key to derive initial keys for many different POI devices, using a key-derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for the derivation of other keys once loaded•e.g., as done with DUKPT.
Modified
p. 254 → 184
20-3.a Examine documented procedures and observe processes for generating initial keys. Verify the following is implemented where initial keys are generated by a derivation process and derived from the same Base Derivation Key:
Modified
p. 254 → 184
• Unique data is used for the derivation process such that all transaction-originating POIs receive unique secret keys.
• Unique data is used for the derivation process such that all transaction-originating POI devices receive unique secret keys.
Modified
p. 254 → 184
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device.
Modified
p. 254 → 184
20-3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device.
Modified
p. 254 → 185
20-4 Examine documented key-generation and injection procedures to verify that entities processing or injecting DUKPT or other key-derivation methodologies incorporate a segmentation strategy in their environments using one or more of the following techniques:
Modified
p. 254 → 185
• Different BDKs for each financial institution
• Different BDKs for each financial institution;
Modified
p. 254 → 185
• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model
• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model;
Modified
p. 254 → 185
• Different BDKs by geographic region, market segment, platform, or sales unit Injection vendors must use at least one unique Base Derivation Key (BDK) per acquiring organization, and must be able to support segmentation of multiple BDKs of acquiring organizations.
• Different BDKs by geographic region, market segment, processing platform, or sales unit; FOR COMPONENT PROVIDERS ONLY: Examine documented key-generation and injection procedures to verify that key-injection vendors use at least one unique Base Derivation Key (BDK) per acquiring organization and are able to support segmentation of multiple BDKs of acquiring organizations.
Modified
p. 254 → 185
20-5 Key-injection facilities that load DUKPT keys for various POI types for the same entity must use separate BDKs per terminal type if the terminal IDs can be duplicated among the multiple types of terminals. In other words, the key-injection facility must ensure that any one given key cannot be derived for multiple devices except by chance.
Modified
p. 254 → 185
20-5.a If the key-injection facility loads DUKPT keys, examine documented procedures for generation and use of BDKs to verify they require use of separate BDKs per terminal type.
Modified
p. 254 → 185
20-5.b Observe key-loading processes for a sample of terminal types used by a single entity, to verify that separate BDKs are used for each terminal type.
Removed
p. 255
• Keys must be uniquely identifiable in all hosts and POI Devices (e.g., EPPs/PEDs). Keys must be identifiable via cryptographically verifiable means (e.g., through the use of digital signatures or key check values).
• Key pairs must be unique per POI device (e.g., EPPs and PEDs).
• Key pairs must be unique per POI device (e.g., EPPs and PEDs).
Modified
p. 255 → 185
20-6 Remote Key-Establishment and Distribution Applications The following requirements apply to key-injection facilities participating in remote key-establishment and distribution applications:
Modified
p. 255 → 185
20-6.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including:
Modified
p. 255 → 185
• The mechanisms utilized for mutual device authentication for both the host and the POIPED.
• The mechanisms utilized for mutual device authentication for both the host and the POI device.
Modified
p. 255 → 186
• Key pairs must be unique per POI device⎯e.g., EPPs and PEDs 20-6.b If key-establishment protocols using public-key cryptography are used to distribute secret keys, verify that:
Removed
p. 256
6F-1.2 Wherever key components are used, they have the following properties:
• Contained within a secure cryptographic device 6F-1.1.a Examine documented procedures for key storage and usage and observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored.
• Contained within a secure cryptographic device 6F-1.1.a Examine documented procedures for key storage and usage and observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored.
Modified
p. 256 → 187
Requirement 21: Secret keys used for enciphering account-data-encryption keys or for account-data encryption, or private keys used in connection with remote key-distribution implementations, must never exist outside of SCDs, except when encrypted or securely stored and managed using the principles of dual control and split knowledge.
Modified
p. 256 → 187
Key-injection facilities must ensure that KEKs and account-data-encryption keys do not exist outside of SCDs except when encrypted or stored under dual control and split knowledge.
Key-injection facilities (or applicable entities providing key-management services) must ensure that KEKs and account-data-encryption keys do not exist outside of SCDs except when encrypted or stored under dual control and split knowledge.
Modified
p. 256 → 187
Some key-injection platforms use personal-computer (PC)-based software applications or similar devices whereby clear-text secret and/or private keys and/or their components exist in unprotected memory outside the secure boundary of an SCD for loading keys. Such systems do not therefore meet this requirement. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. The exploitation of some of the weaknesses could be possible without collusion. Therefore, key-injection facilities that use PC-based key-loading software platforms …
Some key-injection platforms use personal-computer (PC)-based software applications or similar devices whereby clear-text secret and/or private keys and/or their components exist in memory outside the secure boundary of an SCD for loading keys.. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. The exploitation of some of the weaknesses could be possible without collusion. Therefore, key-injection facilities that use PC-based key-loading software platforms whereby clear-text secret and/or private keys and/or their components …
Modified
p. 256 → 187
21-1 Secret or private keys must only exist in one or more of the following forms:
Modified
p. 256 → 187
• At least two separate key shares or full-length components
• At least two separate key shares (secret or private) or full-length components (secret)
Modified
p. 256 → 187
21-1.b Observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions).
Modified
p. 256 → 188
21-2 Examine documented procedures and interview responsible personnel to determine all instances where key components/shares are used.
Modified
p. 256 → 188
21-2.1 Knowledge of any one key component/share must not convey any knowledge of any part of the actual cryptographic key.
Modified
p. 256 → 188
21-2.1 Examine processes for creating key components/shares to verify that knowledge of any one key component/ share does not convey any knowledge of any part of the actual cryptographic key.
Modified
p. 256 → 188
21-2.2 Construction of the cryptographic key must require the use of at least two key components/shares.
Modified
p. 256 → 188
21-2.2 Observe processes for constructing cryptographic keys to verify that at least two key components/shares are required for each key construction.
Removed
p. 257
6F-1.2.4 Procedures exist to ensure any custodian never has access to sufficient key components or shares of a secret or private key to reconstruct a cryptographic key.
In an m-of-n scheme where n =5 and where all three components are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key components (e.g., component A and component B), as a second custodian (with, in this example, component C) would be required to reconstruct the final key, ensuring that dual control is maintained.
In an m-of-n scheme where n =5 and where all three components are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key components (e.g., component A and component B), as a second custodian (with, in this example, component C) would be required to reconstruct the final key, ensuring that dual control is maintained.
Modified
p. 257 → 188
21-2.3 Each key component/share must have one or more specified authorized custodians.
Modified
p. 257 → 188
21-2.3.a Examine documented procedures for the use of key components/shares and interview key custodians and key-management supervisory personnel to verify that each key component/share is assigned to a specific individual, or set of individuals, who are designated as key custodians for that component/share.
Modified
p. 257 → 188
21-2.3.b Observe key-component access controls and key-custodian authorizations/assignments to verify that all individuals with access to key components or shares are designated as key custodians for those particular components/shares.
Modified
p. 257 → 189
For example, in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian must not then be assigned component B or C, as this would give them knowledge of two components, which gives them ability …
For example, in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), where only two of any three shares are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one share. If a custodian was previously assigned share A, which was then reassigned, the custodian must not then be assigned share B or C, as this would give them knowledge of two shares, which gives them the …
Modified
p. 257 → 189
21-2.4.a Examine documented procedures for the use of key components/shares to verify that procedures ensure that no custodian ever has access to sufficient key components or shares to reconstruct a secret or private cryptographic key.
Modified
p. 257 → 189
21-2.4.b Examine key-component/share access controls and access logs to verify that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key.
Removed
p. 258
6F-1.3.3 Interview responsible personnel and observe implemented processes to verify that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner
•or designated backup(s)
•has possession of both the token and its access code.
•or designated backup(s)
•has possession of both the token and its access code.
Modified
p. 258 → 190
21-3.1 Key components that exist in clear-text outside of an SCD must be sealed in individual opaque, pre- numbered, tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.
Modified
p. 258 → 190
• used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card, or other media that can be read without direct physical contact, the packaging should be designed to prevent such access to the key component.
Modified
p. 258 → 190
21-3.1.a Examine key components and storage locations to verify that components are stored in individual opaque, pre-numbered, tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.
Modified
p. 258 → 190
• e.g., is the package sufficiently opaque to prevent reading of a component
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
Modified
p. 258 → 190
21-3.1.c Ensure clear-text key components do not exist in non-secure containers, such as databases or in software programs.
Modified
p. 258 → 190
21-3.1.d Confirm that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear (e.g., at the point in the checklist where the keys are entered).
Modified
p. 258 → 190
21-3.2 Key components/shares for each specific custodian must be stored in a separate secure container that is accessible only by the custodian and/or designated backup(s).
Modified
p. 258 → 190
Components/shares for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers.
Modified
p. 258 → 190
21-3.2 Inspect each key component/share storage container and verify the following:
Modified
p. 258 → 190
• Key components for different custodians are stored in separate secure containers.
• Key components/shares for different custodians are stored in separate secure containers.
Modified
p. 258 → 191
21-3.3 Interview responsible personnel and observe implemented processes to verify that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner •or designated backup(s)
•has possession of both the token and its access code.
•has possession of both the token and its access code.
Removed
p. 259
Domain 6 Annex B Requirements Testing Procedures 6F-2 Procedures must exist and must be demonstrably in use to replace any known or suspected compromised key, its subsidiary keys (those keys encrypted with the compromised key), and keys derived from the compromised key, to a value not feasibly related to the original key.
6F-2.1.2 Interview responsible personnel and observe implemented processes to verify that if unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.
6F-2.1.2 Interview responsible personnel and observe implemented processes to verify that if unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.
Modified
p. 259 → 191
Key-injection facilities must have written procedures to follow in the event of compromise of any key associated with the key-injection platform and process. Written procedures must exist, and all parties involved in cryptographic key loading must be aware of those procedures. All key- compromise procedures must be documented.
Key-injection facilities (or applicable entities providing key-management services) must have written procedures to follow in the event of compromise of any key associated with the key-injection platform and process. Written procedures must exist, and all parties involved in cryptographic key loading must be aware of those procedures. All key-compromise procedures must be documented.
Modified
p. 259 → 191
22-1 Procedures for known or suspected compromised keys must include the following:
Modified
p. 259 → 191
22-1 Verify documented procedures exist for replacing known or suspected compromised keys that include all of the following (22-1.1 through 22-1.5 below):
Modified
p. 259 → 191
22-1.1 Key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised.
Modified
p. 259 → 191
22-1.1 Interview responsible personnel and observe implemented processes to verify key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised.
Modified
p. 259 → 192
22-1.2 Interview responsible personnel and observe implemented processes to verify that if unauthorized alteration is suspected, new keys are not installed until the SCD (or, for hybrid decryption solutions, the Host System) has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.
Modified
p. 259 → 192
22-1.3 A secret or private cryptographic key must be replaced with a new key whenever the compromise of the original key is known. Suspected compromises must be assessed and the analysis formally documented. If compromise is confirmed, the key must be replaced. In addition, all keys encrypted under or derived using that key must be replaced with a new key within the minimum feasible time. The replacement key must not be a variant or an irreversible transformation of the original …
Modified
p. 259 → 192
Known or suspected substitution of a secret key must result in the replacement of that key and any associated key- encipherment keys.
Known or suspected substitution of a secret key must result in the replacement of that key and based on an analysis of how the key was substituted, any associated key-encipherment keys that may have been compromised.
Modified
p. 259 → 192
22-1.3 Interview responsible personnel and observe implemented processes to verify that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If compromise is confirmed, and all the following are performed:
Modified
p. 259 → 192
• Processing with that key is halted, and the key is replaced with a new unique key.
• Use of that key is halted, and the key is replaced with a new unique key.
Removed
p. 260
6F-2.1.4.a Interview responsible personnel and review documented procedures to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 6F-2.2 If attempts to load a secret key or key component into a KLD or POI fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI 6F-2.2 Interview responsible personnel and observe implemented processes to verify that if attempts to load a secret key or key component into a KLD or POI fail, the same key or component is not loaded into …
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 6F-2.2 If attempts to load a secret key or key component into a KLD or POI fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI 6F-2.2 Interview responsible personnel and observe implemented processes to verify that if attempts to load a secret key or key component into a KLD or POI fail, the same key or component is not loaded into …
Modified
p. 260 → 192
22-1.4 A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including:
Modified
p. 260 → 193
22-1.4.b Verify notifications include the following:
Modified
p. 260 → 193
22-1.5 Identification of specific events that would indicate a compromise may have occurred. Such events must include but are not limited to:
Modified
p. 260 → 193
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 6F-2.1.5 Interview responsible personnel and review documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation
Removed
p. 261
6F-3.1 Any key generated with a reversible process (such as a variant of a key) of another key must be protected in the same manner as the original key•that is, under the principles of dual control and split knowledge. Variants of the same key may be used for different purposes, but must not be used at different levels of the key hierarchy. For example, reversible transformations must not generate key-encipherment keys from PIN keys.
Modified
p. 261 → 196
Requirement 23: Keys generated using reversible key-calculation methods, such as key variants, must only be used in SCDs that possess the original key.
Modified
p. 261 → 196
Keys generated using reversible key-calculation methods must not be used at different levels of the key hierarchy. For example, a variant of a key- encryption key used for key exchange must not be used as a working key or as a Master File Key for local storage.
Keys generated using reversible key-calculation methods must not be used at different levels of the key hierarchy. For example, a variant of a key-encryption key used for key exchange must not be used as a working key or as a Master File Key for local storage.
Modified
p. 261 → 196
Note: Exposure of keys that are created using reversible transforms of another (key-generation) key can result in the exposure of all keys that have been generated under that key- generation key. To limit this risk posed by reversible key calculation, such as key variants, the reversible transforms of a key must be secured in the same way as the original key- generation key.
Note: Exposure of keys that are created using reversible transforms of another (key-generation) key can result in the exposure of all keys that have been generated under that key-generation key. To limit this risk posed by reversible key calculation, such as key variants, the reversible transforms of a key must be secured in the same way as the original key-generation key.
Modified
p. 261 → 196
23-1.a Examine documented procedures and interview responsible personnel to determine whether keys are generated using reversible key-calculation methods.
Modified
p. 261 → 196
23-1.b Observe processes to verify that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge.
Modified
p. 261 → 197
23-2.a Interview responsible personnel to determine which host MFKs keys exist as variants.
Modified
p. 261 → 197
23-2.b Examine vendor documentation to determine support for key variants.
Modified
p. 261 → 197
23-2.c Via examination of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys used, determine that variants of the MFK are not used external to the logical configuration that houses the MFK.
Modified
p. 262 → 197
23-3 Reversible key transformations are not used across different levels of the key hierarchy. For example, reversible transformations must not generate working keys e.g., DEKs from key-encrypting keys.
Modified
p. 262 → 197
Note: Using transforms of keys across different levels of a key hierarchy
•e.g., generating aPEK key from a key-encrypting key
•increases the risk of exposure of each of those keys.
•e.g., generating a
•increases the risk of exposure of each of those keys.
Note: Using transformations of keys across different levels of a key hierarchy
•e.g., generating a DEK from a key- encrypting key
•increases the risk of exposure of each of those keys.
•e.g., generating a DEK from a key- encrypting key
•increases the risk of exposure of each of those keys.
Modified
p. 262 → 197
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as a PIN key, MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key-encrypting keys.
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key-encrypting keys.
Modified
p. 262 → 197
23-3 Examine documented key-transformation procedures and observe implemented processes to verify that reversible key transformations are not used across different levels of the key hierarchy, as follows:
Modified
p. 262 → 197
• Variants used as KEKs must only be calculated from other key-encrypting keys.
• Variants used as KEKs must only be calculated from other key-encrypting keys
Modified
p. 262 → 198
Requirement 24: Secret and private keys and key components that are no longer used or have been replaced must be securely destroyed.
Modified
p. 262 → 198
24-1.a Verify documented procedures are in place for destroying secret or private keys, and their key components that are no longer used or that have been replaced by a new key.
Modified
p. 262 → 198
24-1.b Identify a sample of keys and key components that are no longer used or have been replaced. For each item in the sample, interview responsible personnel and examine key-history logs and key-destruction logs to verify that all keys have been destroyed.
Modified
p. 262 → 198
24-1.c Examine storage locations for the sample of destroyed keys to verify they are no longer kept.
Removed
p. 263
Domain 6 Annex B Requirements Testing Procedures 6F-4.2 The procedures for destroying keys or key components that are no longer used or that have been replaced by a new key must be documented and sufficient to ensure that no part of the key or component can be recovered. This must be accomplished by use of a cross-cut shredder, pulping or burning. Strip-shredding is not sufficient.
• must be destroyed following the procedures outlined in ISO
• 9564 or ISO
•11568.
6F-4.2.2 The key-destruction process must be observed by a third party other than the custodian.
• must be destroyed following the procedures outlined in ISO
• 9564 or ISO
•11568.
6F-4.2.2 The key-destruction process must be observed by a third party other than the custodian.
Modified
p. 263 → 198
Note: Key destruction for keys installed in HSMs and POI devices is addressed in Requirement 6G-3.
Note: Key destruction for keys installed in HSMs and POI devices is addressed in Requirement 31.
Modified
p. 263 → 198
24-2.a Examine documented procedures for destroying keys and confirm they are sufficient to ensure that no part of the key or component can be recovered.
Modified
p. 263 → 198
24-2.b Observe key-destruction processes to verify that no part of the key or component can be recovered.
Modified
p. 263 → 198
•physically secured, enciphered (except for electronic
24-2.1 Keys on all other storage media types in all permissible forms
•physically secured, enciphered (except for electronic database backups of cryptograms), or components •must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
•physically secured, enciphered (except for electronic database backups of cryptograms), or components •must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
Modified
p. 263 → 198
•physically secured, enciphered, or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
24-2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media types in all permissible forms
•physically secured, enciphered, or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
•physically secured, enciphered, or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
Modified
p. 263 → 198
•physically secured, enciphered, or
•are destroyed following the procedures outlined in ISO
•9564 or ISO
• 11568.
24-2.1.b Observe key-destruction processes to verify that keys on all other storage media types in all permissible forms
•physically secured, enciphered, or component
•are destroyed following the procedures outlined in ISO
•9564 or ISO
• 11568.
•physically secured, enciphered, or component
•are destroyed following the procedures outlined in ISO
•9564 or ISO
• 11568.
Modified
p. 263 → 199
24-2.2.a Observe key-destruction process and verify that it is witnessed by a third party other than a key custodian for any component of that key.
Modified
p. 263 → 199
24-2.2.b Inspect key-destruction logs and verify that a third-party, non-key-custodian witness signs an affidavit as a witness to the key-destruction process.
Modified
p. 263 → 199
24-2.3 Key components for keys other than the HSM or KLD MFKs that have been successfully loaded and confirmed as operational must also be destroyed, unless the HSM does not store the encrypted values on a database but only stores the subordinate keys internal to the HSM. BDKs used in KLDs may also be stored as components where necessary to reload the KLD.
Modified
p. 263 → 199
24-2.3.a Verify documented procedures exist for destroying key components of keys once the keys are successfully loaded and validated as operational.
Modified
p. 263 → 199
24-2.3.b Observe key-conveyance/loading processes to verify that any key components are destroyed once the keys are successfully loaded and validated as operational.
Modified
p. 264 → 199
Requirement 25: Access to secret and private cryptographic keys and key material must be:
Modified
p. 264 → 199
a) Limited on to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use; and
a) Limited on to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use;
Modified
p. 264 → 199
25-1 To reduce the opportunity for key compromise, the number of key custodians must be limited to the minimum required for operational efficiency.
Modified
p. 264 → 199
25-1 Interview key custodians and key-management supervisory personnel and observe implemented processes to verify the following:
Modified
p. 264 → 199
25-1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. Key custodians must be employees or contracted personnel.
Modified
p. 264 → 199
• A primary and a backup key custodian are designated for each component.
• Key custodian(s) are designated for each component.
Modified
p. 264 → 199
• Assigned key custodians are employees or contracted personnel 6F-5.1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.
• Assigned key custodians are employees or contracted personnel.
Modified
p. 264 → 200
25-1.2.a Examine completed key-custodian forms to verify that key custodians sign the form.
Modified
p. 264 → 200
25-1.2.b Examine completed key-custodian forms to verify that backup custodians sign the form.
Modified
p. 264 → 200
25-1.3 Each key-custodian form provides the following:
Modified
p. 264 → 200
• An effective date for the custodian’s access
• An effective date and time for the custodian’s access
Modified
p. 264 → 200
• An effective date for the custodian’s access
• An effective date and time for the custodian’s access
Modified
p. 264 → 200
• Signature of management authorizing the access 6F-5.1.3 Examine all key-custodian forms to verify that they include the following:
• Signature of management authorizing the access 25-1.3 Examine all key-custodian forms to verify that they include the following:
Removed
p. 265
Organizations that are of such insufficient size that they cannot support the reporting-structure requirement must ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian), receive explicit training to instruct them from sharing key components with their direct manager and must sign key-custodian agreements that includes an attestation to the requirement.
Modified
p. 265 → 201
For example, for a key managed as three components, at least two individuals report to different individuals. In an m- of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual. The components collectively held by an individual and his or her direct reports shall not constitute a quorum …
For example, for a key managed as three components, at least two individuals report to different individuals. In an m- of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual.
Modified
p. 265 → 201
(continued on next page) 25-1.4.a Examine key-custodian assignments and organization charts to confirm the following:
Modified
p. 265 → 201
• Neither direct reports nor the direct reports in combination with their immediate supervisor possess the necessary threshold of key components sufficient to form any given key.
• Neither direct reports nor the direct reports in combination with their immediate supervisors possess the necessary threshold of key components sufficient to form any given key.
Modified
p. 265 → 202
25-1.4.b For organizations that are such a small, modest size that they cannot support the reporting-structure requirement, ensure that documented procedures exist and are followed to:
Modified
p. 265 → 202
• Ensure training includes whistleblower procedures to report any violations.
• Ensure training includes procedures to report any violations.
Removed
p. 266
• Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys.
Modified
p. 266 → 211
Requirement 26: Logs must be kept for any time that keys, key components, or related materials are removed from storage or loaded to an SCD.
Modified
p. 266 → 211
Key-injection facilities must maintain logs for the key management of all keys and keying material used in all key-loading sessions. These include keys and materials removed from safes and used in the loading process.
Key-injection facilities (or applicable entities providing key-management services) must maintain logs for the key management of all keys and keying material used in all key-loading sessions. These include keys and materials removed from safes and used in the loading process.
Modified
p. 266 → 211
26-1 Logs must be kept whenever keys, key components, or related materials are removed from secure storage or loaded to an SCD. These logs must be archived for a minimum of two years subsequent to key destruction.
Modified
p. 266 → 211
• Tamper-evident package number (if applicable) 6F-6.1.a Review log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:
• Tamper-evident and authenticable package number (if applicable) 26-1.a Examine log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:
Modified
p. 266 → 211
• Loaded to an SCD 6F-6.1.b Review log files and audit log settings to verify that logs include the following:
• Loaded to an SCD 26-1.b Examine log files and audit log settings to verify that logs include the following:
Modified
p. 266 → 211
• Key-component identifier
• Key component identifier
Modified
p. 266 → 212
27-1.b Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys.
Modified
p. 266 → 212
27-1.a Interview responsible personnel and examine documented procedures and backup records to determine whether any backup copies of keys or their components exist. Perform the following:
Removed
p. 267
Domain 6 Annex B Requirements Testing Procedures 6F-7.2 If backup copies are created, the following must be in place:
6F-8.1 Written procedures must exist, and all affected parties must be aware of those procedures. All activities related to key administration performed by a key-injection facilities must be documented. This includes all aspects of key administration, as well as:
• Security awareness training
6F-8.1 Written procedures must exist, and all affected parties must be aware of those procedures. All activities related to key administration performed by a key-injection facilities must be documented. This includes all aspects of key administration, as well as:
• Security awareness training
Modified
p. 267 → 212
• Creation (including cloning) must require a minimum of two authorized individuals to enable the process.
• Creation (including cloning) of top-level keys
•e.g., MFKs
•must require a minimum of two authorized individuals to enable the process.
•e.g., MFKs
•must require a minimum of two authorized individuals to enable the process.
Modified
p. 267 → 212
27-2 Interview responsible personnel and observe backup processes to verify the following:
Modified
p. 267 → 212
• The creation of any backup copies requires at least two authorized individuals to enable the process.
• The creation of any backup copies for top-level keys requires at least two authorized individuals to enable the process
Modified
p. 267 → 213
Requirement 28: Documented procedures must exist and must be demonstrably in use for all key-administration operations.
Modified
p. 267 → 213
• Management of personnel changes, including revocation of access control and other privileges when personnel move 6F-8.1.a Examine documented procedures for key-administration operations to verify they include:
• Management of personnel changes, including revocation of access control and other privileges when personnel move 28-1.a Examine documented procedures for key-administration operations to verify they cover all activities related to key administration, and include:
Modified
p. 267 → 213
• Background checks for personnel (within the constraints of local laws
• Background checks for personnel (within the constraints of local laws)
Modified
p. 267 → 213
• Management of personnel changes, including revocation of access control and other privileges when personnel move 6F-8.1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
• Management of personnel changes, including revocation of access control and other privileges when personnel move 28-1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
Modified
p. 267 → 213
28-1.c Interview personnel to verify that security-awareness training is provided for the appropriate personnel.
Modified
p. 267 → 213
28-1.d Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws).
Removed
p. 268
6G-1.1.1 Review documented procedures to verify controls are defined to protect POIs and other SCDs from unauthorized access up to point of deployment.
Modified
p. 268 → 217
•and that precautions are taken to minimize the threat of compromise once deployed.
Requirement 29: Equipment used to protect account data (e.g., POI devices and HSMs) must be placed into service only if there is assurance that the equipment has not been substituted or subjected to unauthorized modifications or tampering prior to the deployment of the device
Modified
p. 268 → 217
Key-injection facilities must ensure that only legitimate, unaltered devices are loaded with cryptographic keys.
Key-injection facilities (or applicable entities providing key-management services) must ensure that only legitimate, unaltered devices are loaded with cryptographic keys.
Modified
p. 268 → 217
Secure areas must be established for the inventory of POI devices that have not had keys injected.The area must have extended walls from the real floor to the real ceiling using sheetrock, wire mesh, or equivalent. Equivalence can be steel cages extending floor to real ceiling. The cages can have a steel cage top in lieu of the sides extending to the real ceiling. The cages must have locks (with logs) or badge control with logging for entry.
Secure rooms must be established for inventory that includes securing POI devices that have not had keys injected. The area must have extended walls from the real floor to the real ceiling using sheetrock, wire mesh, or equivalent. Equivalence can be steel cages extending floor to real ceiling. The cages can have a steel cage top in lieu of the sides extending to the real ceiling. The cages must have locks (with logs) or badge control with logging for entry.
Modified
p. 268 → 218
29-1.a Examine documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys:
Modified
p. 268 → 218
• POIs have not been substituted or subjected to unauthorized modifications or tampering.
• POI devices have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 268 → 218
• POIs have not been substituted or subjected to unauthorized modifications or tampering.
• POI devices have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 268 → 218
• SCDs used for key injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
• SCDs used for key-injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 268 → 218
• SCDs used for key injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
• SCDs used for key-injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 268 → 218
29-1.b Observe processes and interview personnel to verify that processes are followed to provide the following assurances prior to the loading of cryptographic keys:
Modified
p. 268 → 218
29-1.1.a Examine documented procedures to verify controls are defined to protect POI devices and other SCDs from unauthorized access up to point of deployment.
Removed
p. 269
6G-1.1.1.2 POIs and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords.
6G-1.1.1.2 Examine vendor documentation or other information sources to identify default keys (such as keys that are pre-installed for testing purposes), passwords, or data. Observe implemented processes and interview personnel to verify that default keys or passwords are not used.
• All personnel with access to POIs and other SCDs are authorized by management.
6G-1.1.1.2 Examine vendor documentation or other information sources to identify default keys (such as keys that are pre-installed for testing purposes), passwords, or data. Observe implemented processes and interview personnel to verify that default keys or passwords are not used.
• All personnel with access to POIs and other SCDs are authorized by management.
Modified
p. 269 → 218
29-1.1.1 Access to all POI devices and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
Modified
p. 269 → 218
29-1.1.1.a Examine access-control documentation and device configurations to verify that access to all POI devices and key-injection/loading devices is defined and documented.
Modified
p. 269 → 218
29-1.1.1.b For a sample of POI device types and other SCDs, observe authorized personnel accessing devices and examine access logs to verify that access to all POI devices and other SCDs is logged.
Modified
p. 269 → 218
29-1.1.1.c Examine implemented access controls to verify that unauthorized individuals cannot access, modify, or substitute any POI device or other SCD.
Modified
p. 269 → 219
29-1.1.3.a Examine documented authorizations for personnel with access to devices to verify that prior to deployment:
Modified
p. 269 → 219
• All personnel with access to POIs and other SCDs are documented in a formal list.
• All personnel with access to POI devices and other SCDs are authorized by management in an auditable manner.
Modified
p. 269 → 219
29-1.1.3.b For a sample of POI device types and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in an auditable manner have access to devices.
Modified
p. 269 → 219
29-2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt to placement into service.
Modified
p. 269 → 219
29-2.a Examine documented processes to verify that the chain of custody is required for devices from receipt to placement into service.
Modified
p. 269 → 219
29-2.b For a sample of devices, examine documented records and interview responsible personnel to verify the chain of custody is maintained from receipt to placement into service.
Modified
p. 270 → 220
• Transportation using a trusted courier service (e.g., via bonded carrier). The devices are then securely stored until key-insertion and deployment occurs.
• Transportation using a trusted courier service (e.g., via bonded carrier). The devices are then securely stored until key-insertion occurs.
Modified
p. 270 → 220
• Use of physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging). The devices are then stored in such packaging, or in secure storage, until key insertion and deployment occurs.
• Use of physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging). The devices are then stored in such packaging, or in secure storage, until key-insertion occurs.
Modified
p. 270 → 220
• A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. Before key-insertion, the SCD used for key-insertion verifies the presence of the correct “transport-protection token” before overwriting this value with the initial key, and the device is further protected until deployment.
• A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. The SCD used for key-insertion verifies the presence of the correct “transport-protection token” before overwriting this value with the initial key, and the device is further protected until deployment.
Modified
p. 270 → 220
(continued on next page) 29-3.a Examine documented procedures to verify they require physical protection of devices from the manufacturer’s facility up to the point of key-insertion and deployment, through one or more of the defined methods.
Modified
p. 270 → 221
• Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been subject to any unauthorized access or modifications. (Note: Unauthorized access includes that by customs officials.) o Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised. (Note: This …
• Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been subject to any unauthorized modifications.
Modified
p. 270 → 221
29-3.b Interview responsible personnel to verify that one or more of the defined methods are in place to provide physical device protection for devices, from the manufacturer’s facility up to the point of key-insertion and deployment.
Modified
p. 271 → 221
•both deployed and spare or
•throughout their
29-4 Dual-control mechanisms must exist to prevent substitution or tampering of HSMs
•both deployed and spare or backup devices
•throughout their lifecycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs, but cannot supplant the implementation of dual-control mechanisms.
•both deployed and spare or backup devices
•throughout their lifecycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs, but cannot supplant the implementation of dual-control mechanisms.
Modified
p. 271 → 221
•both deployed and spare or back-up devices
•throughout their life cycle.
29-4.a Examine documented procedures to verify that dual-control mechanisms exist to prevent substitution or tampering of HSMs
•both deployed and spare or back-up devices
•throughout their life cycle.
•both deployed and spare or back-up devices
•throughout their life cycle.
Modified
p. 271 → 221
•both
•throughout their life
29-4.b Interview responsible personnel and physically verify the dual-control mechanism used to prevent substitution or tampering of HSMs
•both in service and spare or back-up devices
•throughout their life cycle.
•both in service and spare or back-up devices
•throughout their life cycle.
Modified
p. 271 → 222
Note: Documents used for this process must be received via a different communication channel•i.e., the control document used must not have arrived with the equipment. An example of how serial numbers may be documented by the sender includes but is not limited to the manufacturer’s invoice or similar document 6G-1.4.1.a Interview responsible personnel to verify that device serial numbers are compared to the serial number documented by the sender.
Note: Documents used for this process must be received via a different communication channel•i.e., the control document used must not have arrived with the equipment. An example of how serial numbers may be documented by the sender includes but is not limited to manufacturer’s invoice or similar document.
Modified
p. 271 → 222
29-4.1.b For a sample of received devices, examine sender documentation sent by a different communication channel than the device’s shipment (e.g., the manufacturer’s invoice or similar documentation) used to verify device serial numbers. Examine the record of serial-number validations to confirm the serial number for the received device was verified to match that documented by the sender.
Modified
p. 271 → 222
29-4.2 The security policy enforced by the HSM must not allow unauthorized or unnecessary functions. HSM API functionality and commands that are not required to support specified functionality must be disabled before the equipment is commissioned.
Modified
p. 271 → 222
29-4.2.b Examine documentation of the HSM configuration settings from past commissioning events to determine that the functions and commands enabled are in accordance with the security policy.
Modified
p. 271 → 222
29-4.2.c For a sample of HSMs, examine the configuration settings to determine that only authorized functions are enabled.
Modified
p. 272 → 223
•either new or retrieved from secure storage
•prior to installation to verify devices have not been tampered with or compromised.
29-4.4 Inspect and test all HSMs
•either new or retrieved from secure storage
•prior to installation to verify devices have not been tampered with or compromised.
•either new or retrieved from secure storage
•prior to installation to verify devices have not been tampered with or compromised.
Modified
p. 272 → 223
Processes must include:
Processes must include :
Modified
p. 272 → 223
29-4.4 Examine documented procedures to verify they require inspection and testing of HSMs prior to installation to verify the integrity of the device and include requirements specified at 29-4.4.1 through 29-4.4.4 below.
Modified
p. 272 → 223
29-4.4.1 Examine records of device inspections and test results to verify that self-tests are run on devices to ensure the correct operation of the device.
Modified
p. 272 → 223
29-4.4.2 Observe inspection processes and interview responsible personnel to verify that devices are installed, or reinstalled, only after confirming that the device has not been tampered with or compromised.
Modified
p. 272 → 223
29-4.4.3 Physical and/or functional tests and visual inspection to confirm that physical and logical controls and anti-tamper mechanisms are not modified or removed 29-4.4.3 Observe inspection processes and interview responsible personnel to confirm processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not modified or removed.
Modified
p. 272 → 223
29-4.4.4.a Examine records of inspections and interview responsible personnel to verify records of the tests and inspections are maintained.
Modified
p. 272 → 223
29-4.4.4.b Examine records of inspections to verify records are retained for at least one year.
Modified
p. 272 → 223
29-5 Maintain HSMs in tamper-evident packaging or in secure storage until ready for installation.
Modified
p. 272 → 223
29-5.a Examine documented procedures to verify they require devices be maintained in tamper-evident packaging until ready for installation.
Modified
p. 272 → 223
29-5.b Observe a sample of received devices to verify they are maintained in tamper-evident packaging until ready for installation.
Modified
p. 273 → 224
Requirement 30: Physical and logical protections must exist for deployed POI devices.
Modified
p. 273 → 224
30-1 Not used in P2PE 30-2 Not used in P2PE 30-3 Processes must exist to ensure that key-injection operations are performed and reconciled on an inventory of pre-authorized devices.
Modified
p. 273 → 224
30-3.a Obtain and examine documentation of inventory control and monitoring procedures. Determine that the procedures cover:
Modified
p. 273 → 224
30-3.b Interview applicable personnel to determine that procedures are known and followed.
Modified
p. 274 → 225
Key-injection facilities (or applicable entities providing key-management services) must have procedures to ensure keys are destroyed in cryptographic devices removed from service. This applies to any SCDs (e.g., HSM) used in the key-injection platform, as well as to any devices that have been loaded with keys and securely stored or warehoused on site that are subsequently deemed to be unnecessary and never to be placed into service.
Modified
p. 274 → 225
If a key-injection facility receives a used device to reload with keys, procedures shall ensure that old keys that may be in the device are destroyed prior to loading of new keys. (The used device should have had its keys destroyed when it was removed from service, but this is a prudent secondary check that the keys were destroyed.) 6G-3.1 Procedures are in place to ensure that any SCDs to be removed from service
•e.g., retired, or returned for repair
•e.g., retired, or returned for repair
If a key-injection facility receives a used device to reload with keys, procedures must ensure that old keys that may be in the device are destroyed prior to loading of new keys. (The used device should have had its keys destroyed when it was removed from service, but this is a prudent secondary check that the keys were destroyed.)
Modified
p. 274 → 225
• are not intercepted or used in an unauthorized manner, including that all keys, key material, and account data stored within the device must be rendered irrecoverable.
• are not intercepted or used in an unauthorized manner, including rendering all secret and private keys, key material, and account data stored within the device irrecoverable.
Modified
p. 274 → 225
Note: Without proactive key-removal processes, devices removed from service can retain cryptographic keys in battery-backed RAM for days or weeks. Likewise, host/hardware security modules (HSMs) can also retain keys
•and more critically, the Master File Key
•resident within these devices. Proactive key-removal procedures must be in place to delete all such keys from any SCD being removed from the network.
•and more critically, the Master File Key
•resident within these devices. Proactive key-removal procedures must be in place to delete all such keys from any SCD being removed from the network.
Note: Without proactive key-removal processes, devices removed from service can retain cryptographic keys in battery- backed RAM for days or weeks. Likewise, host/hardware security modules (HSMs) can also retain keys
•and more critically, the Master File Key
•resident within these devices. Proactive key-removal procedures must be in place to delete all such keys from any SCD being removed from the network.
•and more critically, the Master File Key
•resident within these devices. Proactive key-removal procedures must be in place to delete all such keys from any SCD being removed from the network.
Modified
p. 274 → 225
31-1 Verify that documented procedures for removing SCDs from service include the following:
Modified
p. 274 → 225
• Procedures require that all keys and key material stored within the device be securely destroyed.
• Procedures require that all secret and private keys, key material, and all account data stored within the device be securely destroyed.
Modified
p. 274 → 225
• Procedures cover all devices removed from service or for repair.
• Procedures cover all devices removed from service permanently or for repair.
Modified
p. 274 → 225
• Procedures cover requirements at 6G-3.1.1 through 6G-3.1.6 below.
• Procedures cover requirements at 31-1.1 through 31-1.6 below.
Modified
p. 274 → 226
31-1.1.a Examine documented procedures for removing HSMs from service to verify that dual control is implemented for all critical decommissioning processes.
Modified
p. 274 → 226
31-1.1.b Interview personnel and observe demonstration (if HSM is available) of processes for removing HSMs from service to verify that dual control is implemented for all critical decommissioning processes.
Modified
p. 274 → 226
31-1.2 Keys and account data are rendered irrecoverable (e.g., zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.
Modified
p. 274 → 226
31-1.2 Interview personnel and observe demonstration of processes for removing SCDs from service to verify that all keying material and account data are rendered irrecoverable (e.g., zeroized), or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.
Removed
p. 275
6G-4.1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, procedures must be documented and implemented to protect against unauthorized access and use.
Modified
p. 275 → 226
31-1.3 SCDs being decommissioned are tested and inspected to ensure keys and account data have been rendered irrecoverable.
Modified
p. 275 → 226
31-1.3 Interview personnel and observe processes for removing SCDs from service to verify that tests and inspections of devices are performed to confirm that keys and account data have been rendered irrecoverable.
Modified
p. 275 → 226
31-1.4 Affected entities are notified before devices are returned.
Modified
p. 275 → 226
31-1.4 Interview responsible personnel and examine device-return records to verify that affected entities are notified before devices are returned.
Modified
p. 275 → 226
31-1.5 Devices are tracked during the return process. 31-1.5 Interview responsible personnel and examine device-return records to verify that devices are tracked during the return process.
Modified
p. 275 → 226
31-1.6 Records of the tests and inspections are maintained for at least one year.
Modified
p. 275 → 226
31-1.6 Interview personnel and observe records to verify that records of the tests and inspections are maintained for at least one year.
Modified
p. 275 → 226
Requirement 32: Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key, or signing applications to be loaded onto a POI device, must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following:
Modified
p. 275 → 226
c) Restriction of logical access to the equipment Key-injection facilities must ensure protection against unauthorized use for SCDs (e.g., HSMs) used in the key-injection platform that are capable of encrypting a key and producing cryptograms of that key.
c) Restriction of logical access to the equipment Key-injection facilities (or applicable entities providing key-management services) must ensure protection against unauthorized use for SCDs (e.g., HSMs) used in the key-injection platform that are capable of encrypting a key and producing cryptograms of that key.
Modified
p. 275 → 227
32-1.a Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices, or for signing applications and/or whitelists to be loaded into POI devices.
Removed
p. 276
6G-4.1.3 Dual control must be implemented for the following:
Modified
p. 276 → 227
32-1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
Modified
p. 276 → 227
Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented for logical access via two individuals with two different passwords at least five characters in length, or for physical access via a physical lock that requires two individuals, each with a different high-security key.
Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented for logical access via two individuals with two different passwords/authentication codes, or for physical access via a physical lock that requires two individuals each with a different high-security key.
Modified
p. 276 → 227
For devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian.
For devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. Each half must be a minimum of five characters.
Modified
p. 276 → 227
Physical keys, authorization codes, passwords, or other enablers must be managed so that no one person can use both the enabler(s) and the device, which can create cryptograms of known keys or key components under a key-encipherment key used in production.
Physical keys, authorization codes, passwords/authentication codes, or other enablers must be managed so that no one person can use both the enabler(s) and the device, which can create cryptograms of known keys or key components under a key-encipherment key used in production.
Modified
p. 276 → 227
32-1.1 Observe dual-control mechanisms and device-authorization processes to confirm that logical and/or physical characteristics are in place that prevent the device being authorized for use except under the dual control of at least two authorized people.
Modified
p. 276 → 227
32-1.2 Passwords/authentication codes used for dual control must each be of at least five numeric and/or alphabetic characters.
Modified
p. 276 → 227
32-1.2 Observe password policies and configuration settings to confirm that passwords/authentication codes used for dual control must be at least five numeric and/or alphabetic characters.
Modified
p. 276 → 228
32-1.3 Examine dual-control mechanisms and observe authorized personnel performing the defined activities to confirm that dual control is implemented for the following:
Removed
p. 277
6G-4.9.1 The KIF must ensure that keys are transmitted between KIF components in accordance with 6C.
Modified
p. 277 → 228
32-1.4.a Examine password policies and documented procedures to confirm default passwords/authentication codes must not be used for HSMs, KLDs, and other SCDs used to generate or load cryptographic keys, or to sign applications or whitelists.
Modified
p. 277 → 228
32-1.4.b Observe device configurations and interview device administrators to verify that HSMs, KLDs and other SCDs used to generate or load cryptographic keys, or to sign applications or whitelists, do not use default passwords/authentication codes.
Modified
p. 277 → 228
32-1.5 To detect any unauthorized use, devices are at all times within a secure room and either:
Modified
p. 277 → 228
Note: POI devices may be secured by storage in the dual- control access key injection room.
Note: For key-injection facilities, or applicable entities providing key-management services, POI devices may be secured by storage in the dual-control access key-injection room.
Modified
p. 277 → 228
32-1.5.a Examine documented procedures to confirm that they require devices are at all times within a secure room and either:
Modified
p. 277 → 228
32-1.5.b Interview responsible personnel and observe devices and processes to confirm that devices are at all times within a secure room and either:
Modified
p. 277 → 238
Functionality of a key-injection facility may be located at a single physical location or distributed over a number of physical locations. Distributed KIF functionality may include key generation, CA functionality, key distribution and key injection. In order to mitigate the expanded attack surface of a distributed KIF, specific controls apply to a distributed architecture. If any secret or private keys or their components/shares appear in the clear outside of a SCD, Requirement 6G-4.10 for a secure room must be met.
Functionality of a key-injection facility (or applicable entity providing key-management services) may be located at a single physical location or distributed over a number of separate physical locations. Distributed KIF functionality may include key generation, CA functionality, key distribution, and key injection. In order to mitigate the expanded attack surface of a distributed KIF, specific controls apply to a distributed architecture. If any secret or private keys or their components/shares appear in the clear outside of a SCD, Requirement 32-9 …
Modified
p. 277 → 238
32-8 Distributed functionality of the KIF that is used for generation and transfer of keys must communicate via mutually authenticated channels. All key transfers between distributed KIF functions must meet the requirements of Control Objective 3.
Modified
p. 277 → 239
32-8.1.a Examine documented procedures for key conveyance or transmittal to verify that keys used between KIF components are addressed in accordance with applicable criteria in Control Objective 3.
Modified
p. 277 → 239
32-8.1.b Interview responsible personnel and observe conveyance processes to verify that the documented procedures are followed for key conveyance or transmittal for keys used between KIF components.
Removed
p. 278
6G-4.9.6 Mutual authentication of the sending and receiving devices must be performed.
Modified
p. 278 → 239
32-8.2 The KIF must implement mutually authenticated channels for communication between distributed KIF functions•e.g., between a host used to generate keys and a host used to distribute keys.
Modified
p. 278 → 239
32-8.2 Examine documented procedures to confirm they specify the establishment of a channel for mutual authentication of the sending and receiving devices.
Modified
p. 278 → 239
32-8.3 The KIF must ensure that injection of enciphered secret or private keys into POI devices meets the requirements of Control Objective 4.
Modified
p. 278 → 239
32-8.4 The channel for mutual authentication is established using the requirements of Control Objective 4.
Modified
p. 278 → 239
32-8.4.a Examine documented procedures for key loading to hosts and POI devices to verify that they are in accordance with applicable criteria in Control Objective 4.
Modified
p. 278 → 239
32-8.4.b Interview responsible personnel and observe key-loading processes to verify that the documented procedures are followed for key conveyance or transmittal for keys used between KIF components.
Modified
p. 278 → 239
32-8.5 The KIF must implement a mutually authenticated channel for the establishment of enciphered secret or private keys between POI devices and an HSM at the KIF.
Modified
p. 278 → 239
32-8.5 Examine documented procedures to confirm they specify the establishment of a mutually authenticated channel for establishment of enciphered secret or private keys between sending and receiving devices•e.g., POI devices and HSMs.
Modified
p. 278 → 240
• KIFs must validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
• KIFs must validate authentication credentials of a POI device prior to any key transport, exchange, or establishment with that device.
Modified
p. 278 → 240
• When a KLD is used as an intermediate device to establish keys between POIs and a KIF HSM it must not be possible to insert an unauthorized SCD into the flow without detection.
• When a KLD is used as an intermediate device to establish keys between POI devices and a KIF HSM it must not be possible to insert an unauthorized SCD into the flow without detection.
Modified
p. 278 → 240
32-8.6 Interview responsible personnel and observe processes for establishment of enciphered secret or private keys between sending and receiving devices to verify:
Modified
p. 278 → 240
• KIFs validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
• KIFs validate authentication credentials of a POI device prior to any key transport, exchange, or establishment with that device.
Modified
p. 278 → 240
• When a KLD is used as an intermediate device to establish keys between POIs and a KIF HSM, it is not possible to insert an unauthorized SCD into the flow without detection 6G-4.9.7 Mechanisms must exist to prevent a non- authorized host from injecting keys into POIs or an unauthorized POI from establishing a key with a legitimate KIF component.
• When a KLD is used as an intermediate device to establish keys between POI devices and a KIF HSM, it is not possible to insert an unauthorized SCD into the flow without detection 32-8.7 Mechanisms must exist to prevent a non-authorized host from injecting keys into POI devices or an unauthorized POI device from establishing a key with a legitimate KIF component.
Modified
p. 278 → 240
32-8.7 Examine documented procedures to confirm they define mechanisms to prevent an unauthorized host from performing key transport, key exchange, or key establishment with POI devices.
Removed
p. 279
Domain 6 Annex B Requirements Testing Procedures 6G-4.10 The KIF must implement a physically secure area (secure room) for key injection where any secret or private keys or their components/shares appear in the clear outside of an SCD.
6G-4.10.1 The secure area must have walls made of solid materials. In addition, if the solid walls do not extend from the real floor to the real ceiling, the secure area must have extended walls from the real floor to the real ceiling using sheetrock or wire mesh.
6G-4.10.5 An electronic access control system (e.g., badge and/or biometrics) must be in place that enforces:
6G-4.10.1 The secure area must have walls made of solid materials. In addition, if the solid walls do not extend from the real floor to the real ceiling, the secure area must have extended walls from the real floor to the real ceiling using sheetrock or wire mesh.
6G-4.10.5 An electronic access control system (e.g., badge and/or biometrics) must be in place that enforces:
Modified
p. 279 → 242
32-9.1 Inspect the secure room designated for key injection to verify that it is constructed with extended walls from the real floor to the real ceiling using sheetrock or wire mesh.
Modified
p. 279 → 242
32-9.2 Any windows into the secure room must be locked and protected by alarmed sensors.
Modified
p. 279 → 242
32-9.2.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors.
Modified
p. 279 → 242
32-9.2.b Examine the configuration of window sensors to verify that the alarm mechanism is active.
Modified
p. 279 → 242
32-9.3 Any windows must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
Modified
p. 279 → 242
32-9.3 Observe all windows in the secure room to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
Modified
p. 279 → 242
32-9.4 A solid-core door or a steel door must be installed to ensure that door hinges cannot be removed from outside the room.
Modified
p. 279 → 242
32-9.4 Inspect the secure room to verify that it is only accessed through a solid- core or a steel door, with door hinges that cannot be removed from outside the room.
Modified
p. 279 → 243
• Dual-access requirements for entry into the secure area, and
• Dual-access requirements for entry into the secure room, and
Modified
p. 279 → 243
32-9.5 Observe authorized personnel entering the secure room to verify that a badge-control system is in place that enforces the following requirements:
Modified
p. 279 → 243
• Dual-access for entry to the secure area
• Dual-access for entry to the secure room
Modified
p. 279 → 243
• Anti-pass-back 6G-4.10.6 The badge-control system must support generation of an alarm when one person remains alone in the secure area for more than 30 seconds.
• Anti-pass-back 32-9.6 The badge-control system must support generation of an alarm when one person remains alone in the secure room for more than 30 seconds.
Modified
p. 279 → 243
32-9.6 Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds.
Removed
p. 280
6G-4.10.10 The CCTV cameras must be positioned to monitor:
Modified
p. 280 → 243
32-9.7 CCTV cameras must record all activity, including recording events during dark periods through the use of infrared CCTV cameras or automatic activation of floodlights in case of any detected activity. This recording may be motion-activated. The recording must continue for at least a minute after the last pixel of activity subsides.
Modified
p. 280 → 243
32-9.7 Inspect CCTV configuration and examine a sample of recordings to verify that CCTV monitoring is in place on a 24/7 basis.
Modified
p. 280 → 243
32-9.8 Monitoring must be supported on a continuous (24/7) basis such that alarms can be resolved by authorized personnel.
Modified
p. 280 → 243
32-9.8 Inspect configuration of monitoring systems and interview monitoring personnel to verify that monitoring is supported on a continuous (24/7) basis and alarms can be resolved by authorized personnel.
Modified
p. 280 → 243
32-9.9 The CCTV server and digital storage must be secured in a separate secure location that is not accessible to personnel who have access to the key-injection secure room.
Modified
p. 280 → 243
32-9.9.a Inspect location of the CCTV server and digital-storage to verify they are located in a secure location that is separate from the key-injection secure room.
Modified
p. 280 → 243
32-9.9.b Inspect access-control configurations for the CCTV server/storage secure location and the key-injection secure room to identify all personnel who have access to each area. Compare access lists to verify that personnel with access to the key-injection secure room do not have access to the CCTV server/storage secure location.
Modified
p. 280 → 244
32-9.10 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor:
Modified
p. 280 → 244
32-9.11 CCTV cameras must be positioned so they do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.
Modified
p. 280 → 244
32-9.11 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.
Removed
p. 281
Domain 6 Annex B Requirements Testing Procedures 6G-5 Documented procedures must exist and be demonstrably in use to ensure the security and integrity of account-data-processing equipment (e.g., POIs and HSMs) placed into service, initialized, deployed, used, and decommissioned.
6G-5.1 Written procedures must exist, and all affected parties must be aware of those procedures. Records must be maintained of the tests and inspections performed by key- injection facilities on PIN-processing devices before they are placed into service, as well as devices being decommissioned.
6G-5.1 Written procedures must exist, and all affected parties must be aware of those procedures. Records must be maintained of the tests and inspections performed by key- injection facilities on PIN-processing devices before they are placed into service, as well as devices being decommissioned.
Modified
p. 281 → 244
33-1.a Examine documented procedures/processes and interview responsible personnel to verify that all affected parties are aware of required processes and are provided suitable guidance on procedures for account-data processing devices placed into service, initialized, deployed, used, and decommissioned 33-1.b Verify that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.
Modified
p. 282 → 251
Requirement 6I: KIF component providers ONLY: report status to solution providers Domain 6 Annex B Requirements Testing Procedures
Requirement 5I: Component providers ONLY: report status to solution providers Domain 5 Requirements Testing Procedures
Modified
p. 282 → 251
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the component provider’s key-management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include key-management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the component provider’s services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers).
Modified
p. 282 → 251
5I-1 For component providers performing key management, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
Modified
p. 282 → 251
5I-1.1 Track status of the deployed key-management services for POIs and HSMs, and provide reports to solution provider annually and upon significant changes, including at least the following:
Modified
p. 282 → 251
Number of devices Type of key(s) injected Key-distribution method
Modified
p. 282 → 251
Note: Adding, changing, or removing POI and/or HSM types, or critical key-management methods may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.
Modified
p. 282 → 251
5I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel to confirm that the following processes are documented and implemented:
Modified
p. 282 → 251
Number of devices Type of key injected Key-distribution method
Modified
p. 282 → 251
• Details of any known or suspected compromised keys, per 6F-2.1 6I-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
• Details of any known or suspected compromised keys, per 22-1 5I-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
Modified
p. 282 → 251
Number of POI devices Type of key injected Key-distribution method
Modified
p. 283 → 252
Algorithm TDEA RSA Curve DSA AES Minimum key size in number of bits 4 168 2048 224 2048/224 128 The strength of a cryptographic key is a measure of the expected work effort an attacker would have to spend to discover the key. Cryptographic strength is measured in "bits of security" (see, e.g., NIST SP 800-57 Part 1). While the concept of bits of security originated with symmetric encryption algorithms, it extends to asymmetric algorithms as well. In neither case …
Algorithm TDEA RSA Elliptic Curve DSA AES Minimum key size in number of bits 2 168 2048 224 2048/224 128 The strength of a cryptographic key is a measure of the expected work effort an attacker would have to spend to discover the key. Cryptographic strength is measured in "bits of security" (see, e.g., NIST SP 800-57 Part 1). While the concept of bits of security originated with symmetric encryption algorithms, it extends to asymmetric algorithms as well. In neither …
Modified
p. 284 → 253
2. ECDH implementations
• Entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (See FIPS186-4). The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entityshall generate a private key d and a public key Q using the specified elliptic curve domain parameters. (See FIPS186-4 for methods of generating d and Q).
• Entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (See FIPS186-4). The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entity
2. ECDH implementations
• Entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (See FIPS186-4). The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entity must generate a private key d and a public key Q using the specified elliptic curve domain parameters. (See FIPS186-4 for methods of generating d and Q).
• Entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (See FIPS186-4). The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entity must generate a private key d and a public key Q using the specified elliptic curve domain parameters. (See FIPS186-4 for methods of generating d and Q).
Modified
p. 284 → 253
3. Each private key shall be statistically unique, unpredictable, and created using an approved random number generator as described in this document.
3. Each private key must be statistically unique, unpredictable, and created using an approved random number generator as described in this document.
Removed
p. 285
NOTE: Any entity performing Remote Key-Distribution Using Asymmetric Techniques Operations must additionally complete Annex A1, either as part of the Solution Assessment or as part of their respective Component Provider assessment.
NOTE: Any entity performing Certification and Registration Authority Operations with respect to remote key distribution must additionally complete Annex A2, either as part of the Solution Assessment or as part of their respective Component Provider assessment.
NOTE: Any entity performing Certification and Registration Authority Operations with respect to remote key distribution must additionally complete Annex A2, either as part of the Solution Assessment or as part of their respective Component Provider assessment.
Removed
p. 294
Domain Solution Provider P2PE Application Encryption- Management Services Entity Decryption- Management Services Entity KIF Services CA/RA Services Entity Domain 1: Encryption Device and Application Management X Domain 2: Application Security X Domain 3: P2PE Solution Management X Domain 4: Merchant-managed Solutions X Domain 5: Decryption Environment X Domain 6: P2PE Cryptographic Key Operations and Device Management Domain 6 Annex A X as applicable X as applicable Domain 6 Annex B