Document Diff - PCI Watch

Added p. 15

P2PE Component Provider types P2PE Report on Validation submission and acceptance processes Annual renewal process for solutions included on the list of Validated P2PE Solutions Vendor Release Agreements for vendors and providers of P2PE solutions, applications, and solution components The P2PE Delta Change process.

Added p. 59

Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-2.2 (continued) 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.

Added p. 65

Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-3 Maintain instructional documentation and training programs for the application’s installation, maintenance/upgrades, and use.

Added p. 108

(continued on next page) 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:

Added p. 116

• The distribution of symmetric keys using asymmetric techniques from a key-distribution host (KDH) to many key-receiving devices (KRDs⎯i.e., POI devices); or

• The exchange of keys between peers, where one is administratively designated as the KDH and one as the KRD (e.g., the transaction processing host).

Added p. 119

Note: PCI-approved HSMs may have their approvals restricted whereby the approval is valid only when the HSM is deployed in controlled environments or more robust (e.g., secure) environments as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy. This information is noted in the Additional Information column of approved PTS devices.

Added p. 125

• Where clear keying material passes through memory of the PC, the PC requirements of Requirement 13 are met.

Note: Printed key components includes manual (handwritten) capture.

6-3.b Observe blind mailers, tamper-evident and authenticable packaging, or other sealed containers used for key components to verify that components cannot be read from within and that tampering can be visually detected.

• Printers used for this purpose are not used for other purposes and are used only under dual control.

6-3.1 The room must have walls made of solid materials. The walls do not have to extend from true floor to true ceiling but do need to extend from floor to ceiling.

6-3.1 Inspect the secure room designated for printing clear-text key components to verify that the walls are made of solid materials and extend from floor to ceiling.

6-3.2 Any windows into the secure room must be:

• Locked and protected by alarmed sensors.

• Locked and protected by …

Added p. 128

6-3.8 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.

6-3.9 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 to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.

6-3.9.a 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.

6-3.9.b Examine storage of captured recordings to verify that at least the most recent 45 days of images are securely archived.

Added p. 133

The package serial number was transmitted as prescribed.

Added p. 204

• Logs are kept whenever keys, key components, or related materials are removed from secure storage or loaded to an SCD.

• Logs are securely stored, for example, in a secure container with the associated key components.

• Logs must be archived for a minimum of two years subsequent to key destruction 26-1.b Examine log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:

• Loaded to an SCD 26-1.c Examine log files and verify they are:

• Archived for a minimum of two years subsequent to key destruction

Added p. 211

Note: This applies to SCDs used for key injection or code signing, including display prompts.

Added p. 214

• Upon tamper of the device it becomes infeasible to load any keying material.

Added p. 217

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.

Added p. 225

(continued on next page) 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:

Added p. 244

Approved key establishment schemes are described in NIST SP800-56A (ECC/FCC3-based key agreement), NIST SP800-56B (IFC- based key agreement) and NIST SP800-38F (AES-based key encryption/wrapping).

Added p. 244

This includes certificates used by the device that are non-device-specific that are part of a vendor PKI, up to and including a vendor root certificate. The only exception to this is that the initial code on ROM that initiates upon the device start may authenticate itself using SHA-1, but all subsequent code must be authenticated using SHA-2.

SHA-2 or higher is recommended for other usages, but SHA-1 may be used in conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key derivation functions (i.e., KDFs) and random number generation. Where applicable, appropriate key length minimums as delineated in the Derived Test Requirements are also required.

Added p. 245

Algorithm TDEA (IFC) (ECDSA, ECDH, ECMQV) (DSA, DH, MQV) Minimum key size in number of bits 5 168 2048 224 2048/224 128 TDEA refers to TDEA (TDES) keys with non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. The DSA key sizes refer to the size of the modulus and the minimum size of a large subgroup. Key-encipherment keys shall be at least of equal or greater strength than any key that they are protecting.6 This applies to any key-encipherment keys used for the protection of secret or private keys that are stored or for keys used to encrypt any secret or private keys for loading or transport. For purposes of this requirement, the following algorithms and keys …

Added p. 246

IFC, FFC and ECC are vulnerable to attacks from large-scale quantum computers. In 2017, NIST initiated a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms, planned to end with a selection of new algorithms by 2023-2025.

Because of rapid progress in the field of quantum computing, it is advised to become informed/aware of this specific threat and its potential mitigations.

Modified p. 1

Payment Card Industry (PCI) Point-to-Point Encryption Security Requirements and Testing Procedures Version ~~3.0~~

Payment Card Industry (PCI) Point-to-Point Encryption Security Requirements and Testing Procedures Version 3.1

Modified p. 12 → 11

PCI SSC for review and acceptance. Upon acceptance, the P2PE component is listed on PCI SSC’s list of Validated P2PE Components. ~~Or:~~

PCI SSC for review and acceptance. Upon acceptance, the P2PE component is listed on PCI SSC’s list of Validated P2PE Components.

Modified p. 12 → 11

− A merchant as a solution provider can perform all domains (including Appendix A) in their entirety.

− A merchant as a solution provider (MMS) can perform all domains (including Appendix A) in their entirety.

Modified p. 13 → 12

• P2PE non-payment software is assessed only per designated P2PE Domain 1 Requirements at 1C-2 during the assessment of the P2PE solution(s) in which the application will be used. Note that this software is not subject to P2PE Domain 2 Requirements.

P2PE non-payment software is assessed only per designated P2PE Domain 1 Requirements at 1C-2 during the assessment of the P2PE solution(s) in which the application will be used. Note that this software is not subject to P2PE Domain 2 Requirements.

Removed p. 14

• All PCI-approved POI devices included in the P2PE solution (for the merchant to use for payment acceptance)

Modified p. 14 → 13

• 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

Domain 1

• Security requirements for the encryption environment All PCI-approved POI devices included in the P2PE solution (for the merchant to use for payment acceptance) 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 For software with access to clear-text account data intended for use on PTS-approved POI …

Modified p. 14 → 13

• 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

• 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 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 …

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 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 Management of all system components located within or connected to the decryption environment, including those used for decryption of account data, …

Removed p. 15

• POI devices (for account-data encryption) are approved per PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements

• 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)

• Cryptographic-key operations for both encryption and decryption environments using key-management practices from the PTS PIN Security Standard

Modified p. 15 → 14

• 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.

POI devices (for account-data encryption) are approved per PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements 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) Cryptographic-key operations for both encryption and decryption environments using key-management practices from the PTS PIN Security Standard The decryption environment is PCI DSS compliant Please note that this standard for point-to-point encryption solutions does …

Modified p. 15 → 14

• 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 → 14

• 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.

Removed p. 16

• P2PE Component Provider types

• P2PE Report on Validation submission and acceptance processes

• Annual renewal process for solutions included on the list of Validated P2PE Solutions

• Vendor Release Agreements for vendors and providers of P2PE solutions, applications, and solution components

• The P2PE Delta Change process.

Modified p. 16 → 15

• 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 → 15

• 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. 21 → 20

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.

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. Refer to “P2PE Solutions and use of Third Parties and/or P2PE Component Providers” for more information about validating this Domain as a solution provider, an encryption management services component …

Modified p. 23 → 22

~~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.

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. 23 → 22

• 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. 24 → 23

~~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.

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. 24 → 23

• 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:

• 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. 47 → 46

The application uses only the external communication methods included in the POI device vendor's security guidance for all external communications.

• The application uses only the external communication methods included in the POI device vendor's security guidance for all external communications.

Modified p. 48 → 47

• 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

Modified p. 56 → 54

~~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:

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. 56 → 54

• 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:

• How each type of change ties to a specific version number (continued on next page) 2B-1.8.a Examine the software vendor’s documented versioning methodology to verify the version methodology includes:

Modified p. 56 → 55

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.

Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.8 (continued) 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. 57 → 55

~~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:

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. 57 → 55

2B-1.9.a Examine the software vendor’s documented versioning methodology to verify that it includes specific identification of how wildcards are used, including:

(continued on next page) 2B-1.9.a Examine the software vendor’s documented versioning methodology to verify that it includes specific identification of how wildcards are used, including:

Modified p. 57 → 56

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:

Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.9 (continued) 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. 57 → 56

• 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 2B-1.10 The vendor’s published versioning methodology must be communicated to customers and integrators/ resellers.

Removed p. 58

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. 58 → 57

2B-1.13 Software vendor must implement a process to document and authorize the final release of the application and any application updates. Documentation must include:

Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.13 Software vendor must implement a process to document and authorize the final release of the application and any application updates. Documentation must include:

Modified p. 58 → 57

• Confirmation that that all secure development processes were followed

• Confirmation that that all secure development processes were followed 2B-2 The application is implemented securely, including the secure use of any resources shared between different applications.

Removed p. 59

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. 59 → 58

~~• Any guidance that the POI device vendor intended for integrators/ resellers, solution providers, and/or end-users~~ 2B-2.1.1 The application must not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device vendor’s security guidance. This includes the use of:

Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-2.1.1 The application must not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device vendor’s security guidance. This includes the use of:

Modified p. 59 → 58

− Link Layer protocols − IP protocols − Security protocols − IP services

− Link Layer protocols − IP protocols − Security protocols − IP services 2B-2.2 The application-development process must include secure integration with any resources shared with or between applications.

Removed p. 60

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. 60 → 58

2B-2.2.a Review the POI device vendor's security guidance and the application’s Implementation Guide.

(continued on next page) 2B-2.2.a Review the POI device vendor's security guidance and the application’s Implementation Guide.

Modified p. 60 → 58

• 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.~~

• Instructions for how the application should be configured to ensure secure integration with shared resources

Modified p. 61 → 59

~~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.

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. 61 → 60

2B-3 The application vendor uses secure protocols, provides guidance on their use, and performs integration testing on the final application.

Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-3 The application vendor uses secure protocols, provides guidance on their use, and performs integration testing on the final application.

Modified p. 66 → 64

~~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.

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. 66 → 64

• 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.~~

• A statement that all applications must be signed via the instructions provided in the Implementation Guide

Modified p. 67 → 65

~~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.

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.

Removed p. 68

• The logical interfaces intended for sharing of clear-text account data (e.g., those used to pass clear-text data back to the approved firmware of the POI device)

Modified p. 68 → 66

• A list of all logical interfaces for the application, and the function/purpose of each.

A list of all logical interfaces for the application, and the function/purpose of each.

Modified p. 68 → 66

• 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 intended for sharing of clear-text account data (e.g., those used to pass clear-text data back to the approved firmware of the POI device) 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. 69 → 67

• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data

• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 2B-1.1 Applications must be developed based on industry best practices and in accordance with the POI device vendor’s security guidance, and information security is incorporated throughout the software development life cycle.

Modified p. 70 → 67

• Instructions detailing back out or de-installation procedures for the application ~~2B-1.10 The vendor’s published versioning methodology must be communicated to customers and integrators/resellers.~~

• Instructions detailing back out or de-installation procedures for the application

Modified p. 70 → 68

• 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-3.1.1 The application developer must provide security guidance describing how cryptographic keys and/or certificates have to be used.

Removed p. 76

• The issue has been resolved and P2PE encryption functionality is restored and re-enabled, or

• The issue has been resolved and P2PE encryption functionality is restored and re-enabled, or

• 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).

• 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. 76 → 74

3A-3.2.1 The POI device must not be re-enabled until it is confirmed that ~~either:~~

3A-3.2.1 The POI device must not be re-enabled until it is confirmed that the issue has been resolved and P2PE encryption functionality is restored and re-enabled.

Modified p. 76 → 74

3A-3.2.1 Examine documented procedures and interview personnel to verify the POI devices must not be re-enabled until it is confirmed that ~~either:~~

3A-3.2.1 Examine documented procedures and interview personnel to verify the POI devices must not be re-enabled until it is confirmed that either the issue has been resolved and P2PE encryption functionality is restored and re- enabled.

Modified p. 83 → 81

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.

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 (MMS). 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. 83 → 81

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. 93 → 91

• Unauthorized use of sensitive functions (e.g., ~~key- management~~ functions)

• Unauthorized use of sensitive functions (e.g., key-management functions)

Modified p. 95 → 92

~~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.

4C-1.3.3 Detecting and reviewing any unexpected transaction data received.

Modified p. 95 → 93

4C-1.3.4 Reviewing data sent by any POI devices that are causing an unusually high rate of transaction authorization rejections.

Requirement 4C: Monitor the decryption environment and respond to incidents Domain 4 Requirements Testing Procedures 4C-1.3.4 Reviewing data sent by any POI devices that are causing an unusually high rate of transaction authorization rejections.

Modified p. 96 → 93

~~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:

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. 96 → 94

~~• 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).

Requirement 4C: Monitor the decryption environment and respond to incidents Domain 4 Requirements Testing Procedures 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).

Modified p. 102 → 99

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.

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. 102 → 100

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.

Requirement 4D: Implement secure hybrid decryption process

• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 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. 103 → 100

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.

4D-1.14.3 The swap/page files and/or core dumps must never be backed up or copied. (continued on next page) 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. 103 → 101

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-1.14.3 (continued) 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. 111 → 109

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:~~

Requirement 4D: Implement secure hybrid decryption process

• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.6 (continued)

Modified p. 111 → 109

~~• 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.

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. 114 → 111

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.

4D-4.21 An audible alarm must sound if the entrance to the secure room remains open for more than 30 seconds.

Removed p. 118

• When used in connection with KIF activities for loading and/or distribution of acquirer keys to transaction-originating devices (POIs) for use in connection with account-data encryption.

Modified p. 118 → 115

• 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 from the transaction-processing host or is distributed directly by the vendor. This includes:

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 from the transaction-processing host or is distributed directly by the vendor. This includes:

Modified p. 118 → 115

− Root and Subordinate Certification Authority keys and keys used in connection with associated Registration Authority activities − Device-specific key pairs used for that purpose − Keys associated with protection of the aforementioned keys during storing, loading, and usage − The generation of the aforementioned keys

− Root and Subordinate Certification Authority keys and keys used in connection with associated Registration Authority activities − Device-specific key pairs used for that purpose − Keys associated with protection of the aforementioned keys during storing, loading, and usage − The generation of the aforementioned keys When used in connection with KIF activities for loading and/or distribution of acquirer keys to transaction-originating devices (POIs) for use in connection with account-data encryption.

Modified p. 118 → 115

• When used for the protection of account data when conveyed between non-integrated PCI-listed POI devices

•e.g., an SCR and a PIN pad.

When used for the protection of account data when conveyed between non-integrated PCI-listed POI devices•e.g., an SCR and a PIN pad.

Modified p. 119 → 116

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 …

Modified p. 119 → 116

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, a certificate is any digitally signed value containing a public key, where the term “digitally signed” refers to …

Modified p. 121 → 118

• Secret Key = Symmetric key (also known as a shared secret key).

Secret Key = Symmetric key (also known as a shared secret key).

Modified p. 121 → 118

• 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).

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 → 118

• 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.

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.

Modified p. 122 → 119

• FIPS 140-2 or 140-3 Level 3 or higher certified, or

• FIPS 140-2 or FIPS 140-3 Level 3 or higher certified, or

Modified p. 122 → 119

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: HSM approval listings must be current⎯HSMs must have a non-expired PCI PTS HSM approval or a non- expired FIPS 140-2 or FIPS 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).

Modified p. 122 → 119

• 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, or higher. Refer 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 FIPS 140-3 Level 3, or higher. Refer http://csrc.nist.gov.

Modified p. 123 → 120

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:

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 FIPS 140-3 Level 3 (or higher) approval listing for each HSM:

Modified p. 128 → 125

• 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.~~

• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device), or

Removed 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.

• Printers are used only under dual control and only within a secure room that meets the requirements of 32-9; and

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 → 126

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.~~

Printers used for this purpose must not be used for other purposes, must not be networked (i.e., locally connected only), and must be managed under dual control. Location must be a secure room that meets the following requirements:

Modified p. 129 → 126

~~6-3.b~~ Observe processes for printing key components to verify that:

6-3.c Observe processes for printing key components to verify that:

Modified p. 129 → 126

• Printers are not ~~networked.~~

• Printers are not networked; and

Modified p. 135 → 133

~~The package serial number was transmitted as prescribed~~ The details of the serial number of the package were transmitted separately from the package itself.

The details of the serial number of the package were transmitted separately from the package itself.

Modified p. 141 → 139

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:

9-2.c Verify documented procedures require that any sign of package tampering is identified, reported, and, if compromise is confirmed, ultimately results in the destruction and replacement of both:

Modified p. 141 → 139

• 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:

• 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, if compromise is confirmed, ultimately result in the destruction and replacement of both:

Modified p. 141 → 139

• 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:

• Any keys encrypted under this (combined) key 9-2.e Examine records related to any escalated transmittal events. Verify that if compromise is confirmed it resulted in the destruction and replacement of both:

Modified p. 144 → 142

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.

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. 151 → 149

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.

12-5 Examine vendor documentation describing options for how the HSM MFK is created and verify the current MFK was created using AES (or triple-length TDEA for existing P2PE implementations only). Corroborate this via observation of processes, with information gathered during the interview process, and procedural documentation provided by the entity under review.

Removed p. 162

• Retained for a minimum of three years.

• Regularly reviewed by an authorized person who does not have access to the room or to the PC.

• The reviews are documented.

Modified p. 162 → 160

• Logs of access to the room from a manual ~~sign-in~~ sheet;

• Logs of access to the room from a manual sign- in sheet;

Modified p. 164 → 162

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.

13-9.4.9 If the PC application reads or stores clear- text key components (e.g., BDKs or TMKs) from 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. 164 → 162

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.

13-9.4.9 If the PC application reads or stores keys (e.g., BDKs or TMKs) from 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.

Removed 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.

Modified p. 168 → 165

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 used for TDEA or TDEA must use, and AES must use a technique where~~ the KCV is calculated by MACing an ~~all-zero~~ block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). …

Note: Check values may be computed by two methods. TDEA may use either method. AES must only use the CMAC method. In the first method, check values are computed by encrypting an all binary zeros 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). In the second method the KCV is calculated by MACing an all binary zeros block using the …

Modified p. 170 → 167

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 are unique per POI device.

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 are unique per POI device.

Modified p. 173 → 170

• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 ~~June 2021.~~

• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 January 2023.

Modified p. 173 → 170

• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 ~~June 2023.~~

• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 January 2025.

Modified p. 173 → 170

• A digital signature computed over that same ~~data;~~

• A digital signature computed over that same data, e.g., TR-34;

Modified p. 178 → 175

• 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. 185 → 182

20-6.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including:

• Key pairs must be unique per POI device⎯e.g., EPPs and PEDs 20-6.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including:

Modified p. 186 → 182

~~• 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:

20-6.b If key-establishment protocols using public-key cryptography are used to distribute secret keys, verify that:

Modified p. 187 → 183

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 …

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. 189 → 184

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 …

Note: 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 …

Modified p. 191 → 186

• Within a secure cryptographic device that meets applicable PCI PTS requirements for such a device,

• Within a secure cryptographic device that meets applicable PCI PTS or FIPS 140-2/140-3 level 3 or higher requirements for such a device,

Modified p. 191 → 186

• Encrypted using an algorithm and key size of equivalent or greater ~~strength,~~ or

• Encrypted using an algorithm and key size of equivalent or greater strength as delineated in Annex C, or

Modified p. 195 → 189

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.3.b Interview responsible personnel and observe implemented mechanisms to verify the prevention of the use of fraudulent certificates.

Modified p. 195 → 190

• ~~EPP/PED~~ devices and KDHs have a minimum RSA 2048 bits or equivalent.

• POI devices and KDHs have a minimum RSA 2048 bits or equivalent.

Modified p. 199 → 193

The third-party witness must sign an affidavit of ~~destruction.~~

The third-party witness must sign an affidavit of destruction, and this affidavit is retained for a minimum of two years.

Modified p. 203 → 197

• Outside network access must exist only for the purposes of “pushing” ~~certificate- status~~ information to relying parties (e.g., KDHs).

• Outside network access must exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).

Modified p. 205 → 198

25-5.1.a Examine documented procedures to verify that:

(continued on next page) 25-5.1.a Examine documented procedures to verify that:

Modified p. 206 → 200

• Success or failure of the event ~~(continued on next page~~ 25-6.3.a Examine audit trails to verify that logical events are divided into operating- system and CA application events.

• Success or failure of the event 25-6.3.a Examine audit trails to verify that logical events are divided into operating- system and CA application events.

Modified p. 211 → 204

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.

26-1 Logs must be kept whenever keys, key components, or related materials are removed from secure storage or loaded to an SCD. The logs must be securely stored, for example, in a secure container with the associated key components. These logs must be archived for a minimum of two years subsequent to key destruction.

Modified p. 211 → 204

• 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:~~

• Tamper-evident and authenticable package number (if applicable) 26-1.a Interview responsible personnel and examine documented procedures to determine the following:

Modified p. 211 → 204

• ~~Loaded to an SCD 26-1.b~~ Examine log files and audit log settings to verify that logs include the following:

• Securely stored 26-1.d Examine log files and audit log settings to verify that logs include the following:

Modified p. 211 → 204

• Tamper-evident and authenticable package number (if applicable) ~~26-1.c Examine audit trail files to verify that they are archived for a minimum of two years subsequent to key destruction.~~

• Tamper-evident and authenticable package number (if applicable)

Removed p. 218

29-1.1.b Verify that documented procedures include 29-1.1.1 through 29-1.1.3 below.

29-1.1.2 Intentionally left blank

Modified p. 218 → 211

29-1.1 All POI devices and other SCDs must be protected against compromise. Any compromise must be detected. Loading and use of any financial keys after the compromise must be prevented. ~~Controls must include the following:~~

29-1.1 All POI devices and other SCDs must be protected against compromise. Any compromise must be detected. Loading and use of any financial keys after the compromise must be prevented.

Modified p. 218 → 211

~~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.

29-1.1 Examine documented procedures to verify controls are defined to protect POI devices and other SCDs from unauthorized access up to point of deployment.

Modified p. 219 → 212

~~29-1.1.3.a~~ Examine documented authorizations for personnel with access to devices to verify that prior to deployment:

29-1.1.2.a Examine documented authorizations for personnel with access to devices to verify that prior to deployment:

Modified p. 219 → 212

~~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.

29-1.1.2.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. 221 → 215

• 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.

• 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.

Modified p. 223 → 217

Processes must ~~include :~~

Processes must include:

Modified p. 223 → 217

~~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.

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. 227 → 221

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.

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 (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.

Modified p. 228 → 221

• To place the device into a state that allows for the input or output of ~~clear-text~~ key components;

• To place the device into a state that allows for the input or output of clear- text key components;

Modified p. 228 → 222

32-1.5.a Examine documented procedures ~~to confirm that they~~ require devices are ~~at all times~~ within a secure room and either:

32-1.5.a Examine and confirm documented procedures require devices are within a secure room and are either:

Modified p. 229 → 222

• 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:~~

• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices

Modified p. 231 → 225

• Specific access authorizations, whether logical or physical

• Specific access authorizations, whether logical or physical 32-2.6.1 All authorized personnel with access through the Level 3 barrier must:

Modified p. 236 → 229

• Actions that disable the intrusion-detection system ~~32-4 All non-CA personnel must sign an access logbook when entering the Level 3 environment.~~

• Actions that disable the intrusion-detection system

Modified p. 240 → 232

• 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.~~

• 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

Modified p. 241 → 233

• 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 2024 the injection of clear-text secret or private keying material must not be allowed for entities engaged in key injection on behalf of others. This applies to new deployments of POI v5 and higher devices. Subsequent to that date, only encrypted key injection will be allowed for POI v5 and higher devices.

Modified p. 241 → 233

• 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.

• Effective 1 January 2026, 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 v5 and higher devices.

Modified p. 243 → 235

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.~~

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, including the ability to record events during dark periods, and if motion activated verify that recording continues for at least a minute after the last pixel of activity subsides.

Removed p. 252

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 case do the bits of security necessarily equal the length of the key.

The following table, which is consistent with NIST SP 800-57 Part 1, Table 2, and with ISO TR-14742, lists the cryptographic strength of the most common key lengths for the relevant symmetric and asymmetric cryptographic algorithms. DEA (DES) refers to TDEA (TDES) keys with non-parity bits. The RSA key size below refers to the size of the modulus. …

Removed p. 253

This applies to any key-encipherment keys used for the protection of secret or private keys that are stored, or for keys used to encrypt any secret or private keys for loading or transport.

For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH):

Modified p. 253 → 246

1. DH implementations

• Entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity ~~generates~~ a private key x and a public key y using the domain parameters (p, q, g,).

1. FFC implementations

• Entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity must generate a private key x and a public key y using the domain parameters (p, q, g,).

Modified p. 253 → 246

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).

2. ECC 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).

Modified p. 253 → 246

4. Entities must authenticate the DH or ~~ECDH~~ public keys using either DSA, ECDSA, a certificate, or a symmetric MAC (see ISO 16609

• Banking

•Requirements for message authentication using symmetric techniques). One of the ~~following:~~ MAC algorithm 1 using padding method 3, MAC algorithm 5 using padding method ~~4 should be used).~~

4. Entities must authenticate the FFC or ECC public keys using either DSA, ECDSA, a certificate, or a symmetric MAC (see ISO 16609

• Banking

•Requirements for message authentication using symmetric techniques). One of the following should be used: MAC algorithm 1 using padding method 3, MAC algorithm 5 using padding method 4).

Modified p. 255 → 248

• Only use hardware-based decryption as part of the P2PE solution (use of hybrid decryption in a merchant-managed P2PE solution is not permitted).

Only use hardware-based decryption as part of the P2PE solution (use of hybrid decryption in a merchant-managed P2PE solution is not permitted).

Modified p. 255 → 248

• Satisfy all P2PE domain requirements (Domains 1, 2, 3, 4, and 5) in this standard, including this Appendix.

Satisfy all P2PE domain requirements (Domains 1, 2, 3, 4, and 5) in this standard, including this Appendix.

Modified p. 255 → 248

• Undergo a full P2PE assessment by a qualified P2PE assessor.

Undergo a full P2PE assessment by a qualified P2PE assessor.

Document Comparison

Content Changes