Document Diff - PCI Watch

Added p. 2

- Updates from v3.0 P2PE Standard references to v3.1. - Revisions made within the Introduction through Section 3 to add clarity and consistency, both within this P-ROV and across all v3.1 P-ROVs as applicable. - Context of “PCI-listed” P2PE Products updated to “Validated”. - Revision to the description for the use of Not Applicable to add clarity and guidance. - Reformatting and restructuring of tables in Sections 2 and 3 with additional guidance. - Instructions added where applicable regarding the use of this template for KMS Component assessments vs. Solution assessments. - Table numbering in sections 1 through 3 modified as needed to better align across all v3.1 P-ROVs. - New table in section 4 to document all requirements determined to be Not Applicable. - Updates to section 4 to align with the updates from the P2PE v3.1 Standard, in addition to errata. - Added check boxes to section 4 …

Added p. 5

Tables have been included in this template to facilitate the reporting process for certain lists and other information as appropriate. The tables in this template may be modified to increase/decrease the number of rows, as necessary. Additional appendices may be added if the assessor feels there is relevant information to be included that is not addressed in the current format. However, the assessor must not remove any details from the tables provided in this document. Personalization, such as the addition of company logos, is acceptable but limited to the title page.

Added p. 7

N/A (Not Applicable) ‘Not Applicable’, or ‘N/A’, is only acceptable as a finding where the requirement, through testing and review, is determined to not apply to the P2PE Product.

Note: ‘Not Applicable’ cannot be used by entities that provide only partial aspects of a defined Component Provider service to validate to that Component Provider type. Refer to the “P2PE Applicability of Requirements” in the P2PE Program Guide.

Don’t mark “N/A” without providing an explanation and justification for why it is “N/A”.

Provide details for any additional P2PE Assessors involved with the P2PE assessment. Add additional rows as needed.

(DD-MMM-YYYY) Ex: 01-Jan-2021 Timeframe of Assessment:

No (If No, the component has never been listed) P2PE KMS Component Type for this assessment. Select one of the following: (Do not check anything for Solution Assessments) KIF (Key Injection Facility) Key Management Component Provider (KMCP) Key Loading Component Provider (KLCP) Certification Authority / Registration Authority (CA/RA) Remote Key Distribution …

Added p. 13

KMS COMPONENT ASSESSMENTS: Complete this table if Validated P2PE Component Providers are being used to help satisfy applicable requirements for this KMS Component assessment.

It is not permissible to use a PCI-listed P2PE Component Provider of the same type as the entity under assessment.

- A PCI-listed KIF cannot be used to satisfy the requirements of a KIF under assessment. This applies to all Component type assessments. - By extension, a KIF cannot be used to satisfy either a KLCP or a KMCP assessment. - A KIF, KLCP, or a KMCP cannot be used to satisfy CA/RA requirements, and a CA/RA cannot be used to satisfy KIF, KLCP, or KMCP requirements.

Note 1: Refer to the “P2PE Applicability of Requirements” in the P2PE Program Guide.

Note 2: The use of PCI-listed P2PE Component Providers must be considered Validated. Refer to the P2PE Program Guide for additional details. https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_components Are Validated P2PE Component Providers being …

Added p. 14

Provide more detail than simply, e.g., “The KLCP is satisfying part of the KIF services”. Do not leave this blank unless No was checked above.

Third-party entities are entities that are not PCI-listed P2PE Component Providers. Third-party entities must be assessed as applicable for each P2PE assessment in which the third-party service is used to satisfy applicable P2PE requirements. Refer to the P2PE Standard and the P2PE Program Guide for additional information.

SOLUTION ASSESSMENTS: Document the use of all Third Parties as they relate to (only) Key Management Services here. It is not necessary to duplicate this information in the Solution P-ROV.

KMS COMPONENT ASSESSMENTS: Document the use of all applicable Third Parties.

Are Third Party entities involved in the scope of Key Management Services for this assessment? Yes (If Yes, provide details below - insert additional rows as necessary) No (If No, leave remainder of this table blank) Entity Name Entity Location(s) Role …

Added p. 17

Note: This table must correlate correctly with Table 2.1 for the assessment type. Refer to the “P2PE Applicability of Requirements” in the P2PE Program Guide.

Mark Yes or No, as applicable to the assessment type and the overall findings, and mark N/A for all other assessment types.

Solution Provider (or MMS as a Solution Provider) Yes No N/A KIF (Key Injection Facility) Yes No N/A Key Management Component Provider (KMCP) Yes No N/A Key Loading Component Provider (KLCP) Yes No N/A Certification Authority / Registration Authority (CA/RA) Yes No N/A Additional Remote Key Distribution Requirements If the scope of the Key Management Services assessment includes Remote Key Distribution (RKD), as indicated by a YES in Table 2.1, mark the overall compliance status of the additional “RKD” requirements here (either Yes or No). Otherwise mark N/A.

3. Details and Scope of P2PE Assessment INSTRUCTIONS FOR SECTION 3 Solution Assessments: Complete the entirety of section …

Added p. 24

Key ID: Retain generic ID or use specific IDs from assessment Key Type: E.g., DEK, MFK, BDK, KEK, IEK, PEK, MAC, Public, Private, etc. Algorithm: E.g., TDEA, AES, RSA, DSA, ECC, etc. Key Mgmt: E.g., DUKPT, MK/SK, Fixed, One-time use, etc.

Key Length: Full length (include parity bits as applicable) Key Storage: Smartcard, SCD, HSMs, Components, etc. Key Destruction: List destruction methods for each storage method Key Distribution: E.g., Courier, Remote, etc.

ID Key Type Algorithm Key Mgmt Key Length (bits) Fill out all the information below for each key type Key_1 Description & Purpose:

Copy the entire table below as needed and paste a new one to use for every remaining key type Key_N Description & Purpose:

4. Findings and Observations “In Place” may be a mix of “In Place” and “Not Applicable” responses, however it must not include any “Not in Place” responses.

NOTE: Entities only meeting a partial set of applicable requirements …

Added p. 33

All N/A responses require reporting on testing performed (including interviews conducted and documentation reviewed) and must explain how it was determined that the requirement does not apply within the scope of the assessment for the P2PE Product. Note: ‘Not Applicable’ cannot be used by entities that provide only partial aspects of a defined Component Provider service to validate to that Component Provider type. Refer to the “P2PE Applicability of Requirements” in the P2PE Program Guide.

Every requirement denoted as ‘N/A’ in the reporting section below must be documented in this table and vice versa.

List requirements in the order as they appear in the reporting section below. Insert additional rows if needed.

Requirement Document how it was determined that the requirement is Not Applicable to the P2PE Product under assessment

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

Added p. 35

• Any applications, including application version number, resident within the device which were included in the PTS assessment For each PCI-approved HSM used, describe how the observed HSM device configurations verified that all of the device characteristics at 6A-1.4.a match the PTS listing:

Added p. 39

6-1.3.a Examine documented procedures for all key-generation methods. Verify procedures require that:

Added p. 41

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

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

<Report Findings Here> 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 are not networked; and

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

<Report Findings Here> 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.

CA/RA Identify the P2PE Assessor who confirms the walls are made of solid materials and extend from floor to ceiling in the secure room designated for printing clear-text key components:

Added p. 43

<Report Findings Here> 6-3.2 Any windows into the secure room must be:

Added p. 43

6-3.2.a Observe all windows in the secure room to verify they are:

Identify the P2PE Assessor who confirms all windows in the secure room are:

<Report Findings Here> 6-3.2.b Examine configuration of window sensors to verify that the alarm mechanism is active.

Identify the P2PE Assessor who confirms the alarm mechanism is active for the window sensors:

<Report Findings Here> 6-3.3 An electronic access control system (for example, badge and/or biometrics) must be in place that:

• Enforces dual-access requirements for entry into the secure room, and anti-pass-back requirements.

• Supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds.

6-3.3.a Observe authorized personnel entering the secure room to verify that a badge-control system is in place that enforces the following requirements:

• Dual access for entry to the secure room

• Dual access for entry to the secure room

• Anti-pass-back Identify the P2PE Assessor who confirms that a badge-control …

Added p. 45

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

Identify the P2PE Assessor who confirms through observation and interview of personnel that monitoring is supported on a continuous (24/7) basis and alarms can be resolved by authorized personnel.

<Report Findings Here> 6-3.6 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 secure room.

6-3.6.a Inspect location of the CCTV server and digital storage to verify they are located in a secure location that is separate from the secure room.

Identify the P2PE Assessor who confirms the CCTV server and digital storage are located in a secure location that is separate from the secure room.

<Report Findings Here> 6-3.6.b Inspect access-control configurations for the CCTV server/storage secure location and the …

Added p. 46

6-3.7 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor:

Identify the P2PE Assessor who confirms through observation and examination of sample recordings that CCTV cameras are positioned to monitor:

<Report Findings Here> 6-3.8 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.

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.

Identify the P2PE Assessor who confirms through observation and examination of sample recordings that CCTV cameras do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.

Added p. 47

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.

Identify the P2PE Assessor who confirms digital-recording system configurations have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.

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

Identify the P2PE Assessor who confirms at least the most recent 45 days of images are securely archived from captured recordings.

Added p. 69

<Report Findings Here> 12-1.d Verify that the process includes the entry of individual key components by the designated key custodians.

Added p. 94

Be within a certificate as defined in applicable requirements within this Domain; or Be within a PKCS#10 (authentication and integrity occurs via other mechanisms); or Be within an SCD; or Have a MAC (message authentication code) created using the algorithm defined in ISO 16609.

Added p. 99

<Report Findings Here> 18-1.b Verify that implemented procedures include:

Added p. 132

The key-pair lifecycle must result in expiration of KDH keys every five years, unless another mechanism exists to prevent the use of a compromised KDH private key.

<Report Findings Here> 22-5.c Verify that KDH keys expire every five years unless another mechanism exists to prevent the use of a compromised KDH private key.

Added p. 141

<Report Findings Here> 25-2.1 All user access must be restricted to actions authorized for that role.

Added p. 152

<Report Findings Here> 25-8 Implement user-authentication management for all system components as follows:

<Report Findings Here> 25.8.3 If passwords are used, system-enforced expiration life must not exceed 90 days and a minimum life at least one day.

Added p. 156

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

• 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 Personnel interviewed: <Report Findings Here> Documented procedures reviewed:

Added p. 157

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

Added p. 165

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

Added p. 169

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

• Shipped and stored containing a secret that: o Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and o Can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.

• 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: this control must be used in conjunction with one of the other methods.) o Controls exist and are in use to ensure that all physical and logical controls and anti-tamper mechanisms used are not modified or removed.

Added p. 172

<Report Findings Here> 29-4.4.1 Running self-tests to ensure the correct operation of the device.

<Report Findings Here> 29-5 Maintain HSMs in tamper-evident packaging or in secure storage until ready for installation.

Added p. 174

<Report Findings Here> 30-3.b Interview applicable personnel to determine that procedures are known and followed.

Added p. 182

<Report Findings Here> 32-2.2.2 The facility has a guarded entrance or a foyer with a receptionist. No entry is allowed for visitors if the entryway is not staffed•i.e., only authorized personnel who badge or otherwise authenticate themselves can enter when entryway is unstaffed.

Added p. 183

<Report Findings Here> 32-2.3.1 Visitors must be authorized and escorted at all times within the Level 2 environment.

Added p. 187

<Report Findings Here> 32-2.7.2 The system must enforce anti-pass-back.

Added p. 194

<Report Findings Here> 32-4.1 The access log must include the following details:

Added p. 195

<Report Findings Here> 32-6.b Examine security-system configurations and documented alarm events to verify that all alarm events are logged.

Added p. 196

<Report Findings Here> 32-6.3.c Conduct a test to verify the appropriate response occurs.

Added p. 202

<Report Findings Here> 32-9.2.b Examine configuration of window sensors to verify that the alarm mechanism is active.

Added p. 203

Describe how the alarm mechanisms observed verified that a badge-control system supports generation of an alarm when one person remains alone in the secure area for more than 30 seconds:

Added p. 208

<Report Findings Here> 5A-1.3.1 Maintain documentation of all cryptographic keys managed as part of the P2PE solution, including:

Modified p. 1

Payment Card Industry (PCI) Point-to-Point Encryption Key Management Services Template for Report on Validation for use with P2PE ~~v3.0~~ for P2PE Key Management Services Assessments

Payment Card Industry (PCI) Point-to-Point Encryption Key Management Services Template for Report on Validation for use with P2PE v3.1 for P2PE Key Management Services Assessments

Removed p. 4

Tables have been included in this template to facilitate the reporting process for certain lists and other information as appropriate. The tables in this template may be modified to increase/decrease the number of rows, or to change column width. Additional appendices may be added if the assessor feels there is relevant information to be included that is not addressed in the current format. However, the assessor must not remove any details from the tables provided in this document. Personalization, such as the addition of company logos, is acceptable but limited to the title page.

The table below summarizes the P2PE v3.0 P-ROVs and the applicability of each P-ROV relative to the assessment type. The following acronyms are used:

SP = Solution Provider CP = Component Provider

Modified p. 4 → 5

Use of this Reporting Template is mandatory for all P2PE ~~v3.0~~ Key Management Services Component Provider assessments (i.e., for a KIF, KMCP, KLCP, or a CA/RA assessment).

KMS Component Assessments: Use of this Reporting Template is mandatory for all P2PE v3.1 Key Management Services Component Provider assessments (i.e., for a KIF, KMCP, KLCP, or a CA/RA assessment).

Modified p. 4 → 5

Use of this Reporting Template is mandatory for all P2PE ~~v3.0~~ Solution (and ~~MMS) assessments~~ where the Solution Provider is directly responsible for all or part of the Key Management Services requirements (i.e., when they have not ~~outsourced~~ the ~~entirety~~ of their key management services ~~to PCI-listed Component Providers).~~

Solution Assessments: Use of this Reporting Template is mandatory for all P2PE v3.1 Solution (and Merchant-managed Solution) assessments, where the Solution Provider is directly responsible for all or part of the Key Management Services requirements (i.e., when they have not completely satisfied the full scope of their key management services within the applicable EMS and DMS requirements.

Modified p. 4 → 5

A P2PE compliance assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers. These work papers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, references, screenshots, and other evidence collected during the course of the assessment. The P-ROV is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed the validation activities and how …

Removed p. 5

Note: A separate Merchant-Managed Solution P-ROV is used as part of MMS assessments.

Solution assessments that do not outsource the entirety of their Encryption Management Services to PCI-Listed Component Providers, either to an EMCP or to BOTH a PDCP AND a PMCP, must complete this P-ROV in addition to the Solution P-ROV.

Component Provider assessments for an EMCP, PDCP, or a PMCP must complete this P-ROV.

Solution assessments that do not outsource the entirety of their Decryption Management Services to a PCI Listed DMCP must complete this P-ROV in addition to the Solution P-ROV.

Component Provider assessments for a DMCP must complete this P-ROV.

Tables have been included in this template to facilitate the reporting process for certain lists and other information as appropriate. The tables in this template may be modified to increase/decrease the number of rows, or to change column width. Additional appendices may be added if the assessor feels

Modified p. 5 → 6

Encryption Management Services (EMS) Solution (SP) Encryption Management CP (EMCP) POI Deployment CP (PDCP) POI Management CP (PMCP) Encryption Management Services relates to the distribution, management, and use of POI devices in a P2PE Solution.

Encryption Management Services (EMS) Solution (SP) Encryption Management CP (EMCP) POI Deployment CP (PDCP) POI Management CP (PMCP) Encryption Management Services relates to the distribution, management, and use of POI devices in a P2PE Solution. Solution assessments that have not satisfied the entirety of their Encryption Management Services (Domain 1 with Domain 5) via the use of applicable Validated P2PE Component Providers must complete the EMS P-ROV in addition to the Solution P-ROV. Component Provider assessments for an EMCP, PDCP, …

Modified p. 5 → 6

P2PE Application P2PE Application Any assessment that utilizes software on the POI devices intended for use in a P2PE Solution that has the potential to access clear-text ~~cardholder~~ data must complete ~~this P-ROV.~~

P2PE Application P2PE Application Any assessment that utilizes software on the PTS-approved POI devices intended for use in a P2PE Solution that has the potential to access clear-text account data must complete a P2PE Application P- ROV (one for each application).

Modified p. 5 → 6

Decryption Management Services (DMS) Solution (SP) Decryption Management CP (DMCP) Decryption Management Services relates to the management of a decryption environment, including applicable devices ~~(e.g., HSMs)~~ used to support a P2PE Solution.

Decryption Management Services (DMS) Solution (SP) Decryption Management CP (DMCP) Decryption Management Services relates to the management of a decryption environment, including applicable account-data decryption devices used to support a P2PE Solution. Solution assessments that have not satisfied the entirety of their Decryption Management Services (Domain 4 with Domain 5) with applicable Validated P2PE Component Providers must complete the DMS P-ROV in addition to the Solution P-ROV. Component Provider assessments for a DMCP must complete the DMS P-ROV.

Modified p. 5 → 6

Solution assessments that have not satisfied the key management services requirements (Domain 5) either through the use of ~~PCI-listed~~ Component Providers and/or through the assessment of their Encryption Management Services and/or Decryption Management Services must complete the KMS P-ROV. E.g., if the P2PE Solution offers remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account-data encryption, or the operation of an applicable ~~CA/RA, or~~ any other relevant key management service that …

Solution assessments that have not satisfied the entirety of key management services requirements (Domain 5) either through the use of Validated P2PE Component Providers and/or through the assessment of their Encryption Management Services and/or Decryption Management Services must complete the KMS P-ROV. E.g., if the P2PE Solution offers remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account-data encryption, or the operation of an applicable CA/RA. Or if any other relevant …

Modified p. 5 → 6

Component Provider assessments for a KIF, KMCP, KLCP, or a CA/RA must complete ~~this P-ROV.~~

Component Provider assessments for a KIF, KMCP, KLCP, or a CA/RA must complete the KMS P- ROV.

Removed p. 6

Do not delete any content from any place in this document, including this section and the versioning above. These instructions are important for the assessor as they complete reporting, but also provide context for the report recipient(s). Addition of text or sections is applicable within reason, as noted above.

A P2PE compliance assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers. These work papers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, references, screenshots, and other evidence collected during the course of the assessment. The P-ROV is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed the validation activities and how the resultant findings were reached. At a high level, the P-ROV provides a summary of testing activities performed and information collected during …

Modified p. 6 → 7

• Section 1: Contact Information and Report Date

Section 1: Contact Information and Report Date

Modified p. 6 → 7

• Section 2: Summary Overview

Section 2: Summary Overview

Modified p. 6 → 7

• Section 3: Details and Scope of P2PE Assessment

Section 3: Details and Scope of P2PE Assessment

Modified p. 6 → 7

• Section 4: Findings and Observations This Reporting Template includes tables with Reporting Instructions built-in. Details provided should focus on concise quality of detail, rather than lengthy, repeated verbiage.

Section 4: Findings and Observations This Reporting Template includes tables with Reporting Instructions built-in. Details provided should focus on concise quality of detail, rather than lengthy, repeated verbiage.

Modified p. 6 → 7

P-ROV Summary of Findings This version of the P2PE Reporting Template reflects an on-going effort to simplify assessor summary reporting. All summary findings for “In Place,” “Not in Place,” and “Not Applicable” are found at the beginning of ~~4. Findings~~ and ~~Observations~~ and are only addressed at that high-level. A summary of ~~all domain findings~~ is ~~also~~ at ~~“2.5 Summary~~ of P2PE Compliance Status.” The following table is a representation when considering which selection to make. ~~Remember, assessors~~ must select …

P-ROV Summary of Findings This version of the P2PE Reporting Template reflects an on-going effort to simplify assessor summary reporting. All summary findings for “In Place,” “Not in Place,” and “Not Applicable” are found at the beginning of section 4 “Findings and Observations” and are only addressed at that high-level. The summary of the overall compliance status is at section 2.8 “Summary of P2PE Assessment Compliance Status.” The following table is a representation when considering which selection to make. Assessors …

Removed p. 7

(Not Applicable) The requirement does not apply to the P2PE Product.

Modified p. 7

In Place The expected testing has been performed, and all elements of the requirement have been met as stated. ~~This may be a mix of In Place and Not Applicable responses, but no Not in Place response.~~ Requirements fulfilled by other P2PE Components or Third Parties should be In Place, unless the requirement does not apply.

RESPONSE WHEN TO USE THIS RESPONSE In Place The expected testing has been performed, and all elements of the requirement have been met as stated. Requirements fulfilled by other P2PE Components or Third Parties should be In Place, unless the requirement does not apply.

Modified p. 7

All ~~Not Applicable~~ responses require reporting on testing performed and must explain how it was determined that the requirement does not ~~apply.~~

All N/A responses require reporting on testing performed (including interviews conducted and documentation reviewed) and must explain how it was determined that the requirement does not apply within the scope of the assessment for the P2PE Product.

Modified p. 7 → 8

• “Identify the P2PE Assessor who confirms…” Indicates only an affirmative response where further reporting is deemed unnecessary by PCI SSC. The P2PE Assessor’s name or a Not Applicable response are the two appropriate responses here. A Not Applicable response will require brief reporting to explain how this was confirmed via testing.

“Identify the P2PE Assessor who confirms…” Indicates only an affirmative response where further reporting is deemed unnecessary by PCI SSC. The P2PE Assessor’s name or a Not Applicable response are the two appropriate responses here. A Not Applicable response will require brief reporting to explain how this was confirmed via testing.

Modified p. 7 → 8

• Document name or interviewee reference At ~~3.5,~~ “Documentation Reviewed,” and ~~3.6,~~ “Individuals Interviewed,” there is a space for a reference ~~number and~~ it is the P2PE Assessor’s choice to use the document name/interviewee job title or the reference number in responses. A listing is sufficient here, no further detail required.

Document name or interviewee reference At section 3.6, “Documentation Reviewed,” and section 3.7, “Individuals Interviewed,” there is a space for a reference number; it is the P2PE Assessor’s choice to use the document name/interviewee job title or the reference number in responses. A listing is sufficient here, no further detail required.

Modified p. 7 → 8

• Sample reviewed Brief list is expected or sample identifier. ~~Again, where~~ applicable, it is the P2PE Assessor’s choice to list out each sample within reporting or to utilize sample identifiers from the sampling summary table.

Sample reviewed Brief list is expected or sample identifier. Where applicable, it is the P2PE Assessor’s choice to list out each sample within the reporting or to utilize sample identifiers from the sampling summary table.

Removed p. 8

• Brief description/short answer

Modified p. 8

• “Describe how…” ~~These are the only reporting instructions that will stretch across half of the table; the above are all a quarter-table’s width to serve as a visual indicator of detail expected in response.~~ These responses must be a narrative response that provides explanation as to the observation•both a summary of what was witnessed and how that verified the criteria of the testing procedure.

Brief description/short answer

• “Describe how…” These responses must be a narrative response that provides explanation as to the observation•both a summary of what was witnessed and how that verified the criteria of the testing procedure.

Removed p. 9

• Describe how a Requirement was verified as the Reporting Instruction directs, not just that it was verified.

• Don’t include forward-looking statements or project plans in responses.

Modified p. 9

• Complete all applicable P-ROVs based on the ~~assessment.~~

Complete all applicable P-ROVs based on the assessment type.

Modified p. 9

• Read and understand the intent of each Requirement and Testing Procedure.

Read and understand the intent of each Requirement and Testing Procedure.

Modified p. 9

• Provide a response for every Testing Procedure, even if N/A.

Provide a response for every Testing Procedure, even if N/A.

Modified p. 9

• Provide sufficient detail and information to demonstrate a finding of “in place” or “not applicable.”

Provide sufficient detail and information to demonstrate a finding of “in place” or “not applicable.” Describe how a Requirement was verified as the Reporting Instruction directs, not just that it was verified.

Modified p. 9

• Ensure all parts of each Testing Procedure are addressed.

Ensure all parts of each Testing Procedure are addressed.

Modified p. 9

• Ensure the response covers all applicable application and/or system components.

Ensure the response covers all applicable application and/or system components.

Modified p. 9

• Perform an internal quality assurance review of the P-ROV for clarity, accuracy, and quality.

Perform an internal quality assurance review of the P-ROV for clarity, accuracy, and quality.

Modified p. 9

• Perform an internal quality assurance review of all submitted ~~P- ROVs~~ and the details within the PCI SSC Portal.

Perform an internal quality assurance review of all submitted P-ROVs and the details within the PCI SSC Portal.

Modified p. 9

• Provide useful, meaningful diagrams, as directed.

Provide useful, meaningful diagrams, as directed.

Modified p. 9

• Don’t report items in the “In Place” column unless they have been verified as being “in place.”

Don’t report items in the “In Place” column unless they have been verified as being “in place.” Don’t include forward-looking statements or project plans in responses.

Modified p. 9

• Don’t simply repeat or echo the Testing Procedure in the response.

Don’t simply repeat or echo the Testing Procedure in the response.

Modified p. 9

• Don’t copy responses from one Testing Procedure to another.

Don’t copy responses from one Testing Procedure to another.

Modified p. 9

• Don’t copy responses from previous assessments.

Don’t copy responses from previous assessments.

Modified p. 9

• Don’t include information irrelevant to the assessment.

Don’t include information irrelevant to the assessment.

Modified p. 10

1. Contact Information and Report Date 1.1 Contact Information ~~P2PE~~ Solution/Component Provider ~~contact information~~ Company name: Company URL:

1. Contact Information and Report Date 1.1 Contact Information Solution/Component Provider Contact Information Company name: Company URL:

Modified p. 10

P2PE Company and Lead Assessor ~~contact information~~ Company name: Assessor company credentials: QSA (P2PE) PA-QSA (P2PE) Company Servicing Markets for P2PE: (see https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_assessors) Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:

P2PE Assessor Company and Lead Assessor Contact Information Company name: Assessor company credentials: QSA (P2PE) PA-QSA (P2PE) Company Servicing Markets for P2PE: (see https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_assessors) Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:

Modified p. 10

Confirm that internal QA was fully performed on the entire P2PE submission, per requirements in relevant program documentation.

Confirm that internal QA was fully performed on the entire P2PE submission, per requirements in the relevant program documentation.

Modified p. 10

No ~~(if no,~~ this is not in accordance with PCI Program requirements) QA reviewer name: ~~Assessor~~ credentials:

No (If No, this is not in accordance with PCI Program requirements) QA reviewer name: QA reviewer credentials:

Modified p. 10

(Leave blank if not applicable) QA reviewer phone number: ~~Assessor~~ e-mail address:

(Leave blank if not applicable) QA reviewer phone number: QA reviewer e-mail address:

Modified p. 10

~~P2PE additional Assessor contact information (add additional rows as needed)~~ Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:

Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:

Modified p. 11

~~1.2.a~~ Additional ~~services provided~~ by ~~PA-QSA(P2PE)/QSA (P2PE)/QSA company The~~ P2PE QSA ~~(P2PE)~~ and ~~PA-QSA (P2PE)~~ Qualification ~~Requirements v2.1, Section 2.2~~ “Independence” specifies requirements for QSAs around disclosure of such services and/or offerings that could reasonably be viewed to affect independence of assessment. Complete the sections below after review of this portion of the ~~Validation Requirements,~~ to ensure responses are consistent with documented obligations.

(From DD-MMM-YYYY To DD-MMM-YYYY) 1.3 Additional Services Provided by PA-QSA(P2PE) / QSA(P2PE) / P2PE QSA Company The current version of the “Qualification Requirements for Point-to-Point Encryption (P2PE)TM Qualified Security Assessors

• QSA(P2PE) and PA-QSA(P2PE)” (P2PE QSA Qualification Requirements), section “Independence” specifies requirements for P2PE QSAs around disclosure of such services and/or offerings that could reasonably be viewed to affect independence of assessment. Complete the sections below after review of this portion of the P2PE QSA Qualification Requirements to ensure responses are …

Modified p. 11

• Disclose all services offered to the assessed entity by the ~~PA- QSA(P2PE)/QSA (P2PE)/QSA~~ company, including but not limited to whether the assessed entity uses any security-related devices or security-related applications that have been developed or manufactured by the QSA, or to which the QSA owns the rights or that the QSA has configured or manages:

Disclose all services offered to the assessed entity by the PA-QSA(P2PE) / QSA(P2PE) / P2PE QSA company, including but not limited to whether the assessed entity uses any security-related devices or security-related applications that have been developed or manufactured by the QSA, or to which the QSA owns the rights or that the QSA has configured or manages:

Modified p. 11

• Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the ~~PA-QSA(P2PE)/QSA (P2PE)/QSA~~ company:

Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the PA-QSA(P2PE) / QSA(P2PE ) / P2PE QSA company:

Removed p. 12

If any PCI-listed KMS Component Providers are being used in the Solution complete Table 2.2.

Solution Name <Solution Name> If No (this is a Component Provider assessment ONLY), complete Part A. Also complete Table 2.2 for any PCI-listed KMS Components are being used.

PCI SSC Ref # P2PE Component Type. Please select only one of the following:

KIF Key Management Component Provider (KMCP) Key Loading Component Provider (KLCP) CA/RA Notes: Within Section 4, “Findings and Observations,” applicable requirements are identified as follows (KLCP, KMCP, KIF, CA/RA, RKD and SP).

Modified p. 12

2. Summary Overview 2.1 P2PE Assessment Details Is this P-ROV ~~assessment~~ being submitted as part of a Solution assessment? If ~~Yes, please~~ enter Solution ~~Name.~~

2. Summary Overview 2.1 P2PE Assessment Details Solution or Component Assessment Is this P-ROV being submitted as part of a Solution assessment or for a KMS Component assessment? Solution If Solution, enter the Solution Name: (Complete this P-ROV with the Solution P-ROV) KMS Component If KMS Component, complete the P2PE Component Details below.

Modified p. 12

P2PE Component Details ~~• Part A~~ P2PE Component ~~name:~~

P2PE Component Details (for KMS Component assessments ONLY) P2PE Component Name:

Modified p. 12

Is the Component already listed on the PCI SSC List of Validated P2PE Components? Yes ~~(if yes,~~ provide ~~ref #) No~~

Is the Component already (or was it previously) listed on the PCI SSC List of Validated P2PE Components? Yes (If Yes, provide listing reference #):

Removed p. 13

Description of how other P2PE Component Providers are used:

Type of Component (select one per row) P2PE Component Provider Name P2PE Component Name PCI SSC Reference # KLCP KMCP KIF CA/RA 2.3 Other Third-Party Service Provider entities involved in P2PE Solution/Component This could include Key Management Services who have opted NOT to list with PCI SSC as a P2PE Component and therefore must be assessed fully for each P2PE Component in which the service is used. This could also include other third-party service providers in use as applicable.

“Other details” is to be used as needed. For example, if there is a third-party service provider providing Key Management Services but it is not a P2PE Component at 2.2, use “Other details” to address data. Mark as “N/A” if no other details are needed.

Entity Name: Role/Function: Entity Location(s): Other Details, if needed:

Removed p. 14

Identifier PTS Approval or FIPS #:

Key Management Services Solution Provider (or MMS as a Solution Provider) Yes No N/A KIF Yes No N/A Key Management Component Provider Yes No N/A Key Loading Component Provider Yes No N/A Remote Key Distribution using Asymmetric Techniques Yes No N/A CA/RA Yes No N/A

Modified p. 14 → 16

~~Manufacturer/~~ Model ~~Name/ Number: Hardware#(s) Firmware#(s) Location: #~~ of ~~devices~~ per Approved ~~key function(s)~~ & ~~2.5 Summary of P2PE Compliance Status P2PE Function Compliant Comments (optional):~~

Identifier Type PTS and/or FIPS Approval # Manufacturer / Model Name / Number Hardware #(s) Firmware #(s) Location Number of Devices per Location Approved Key Function(s) & Purpose

Removed p. 15

• Locations of critical facilities

• Location of systems performing key-management functions <Insert Key Management Services high level diagram(s)>

Modified p. 15 → 18

• ~~Describe the~~ methods or processes used to identify all elements in scope of the P2PE assessment:

• The methods or processes used to identify all elements in scope of the P2PE assessment:

Modified p. 15 → 18

• ~~Describe how the P2PE assessor confirmed that~~ the scope of the assessment is accurate and ~~covers~~ all components and facilities for Key Management Services:

• How the scope of the assessment was confirmed to be accurate and to cover all components and facilities for the Key Management Services:

Removed p. 16

• Key Distribution / Loading / Injection onto POI devices

• Other Key Distribution / Loading / Injection activities

• Key Archiving (if applicable)

< Insert applicable diagram(s) showing all key-management processes >

Removed p. 17

Note: A detailed Key Matrix is included in Findings and Observations, below.

Modified p. 17 → 24

~~Key type/description Purpose/function of the key~~

Key_2 Description & Purpose:

Removed p. 18

P2PE Assessor’s Lab Solution/Component Provider’s Lab Address of the lab environment used for this assessment:

Describe the lab environment used for this assessment:

List of all facilities INCLUDED in this assessment Description and purpose of facility included in assessment Address of facility List of facilities used in P2PE Solution/Component that were EXCLUDED from this assessment* Description and purpose of facility excluded from assessment Address of facility Explanation why the facility was excluded from the assessment Details of any separate assessments performed for the facility, including how the other assessment was verified to cover all Solution/Components in scope for this Solution/Component * Note: Does not include merchant locations.

Removed p. 19

All documentation reviewed for this P2PE Assessment:

Reference # (optional use) Document Name (including version, if applicable) Document date (latest version date) Document Purpose 3.6 Individuals Interviewed List of all personnel interviewed for this Assessment:

Reference # (optional use) Interviewee’s Name Company Job Title

Removed p. 20

Note: Use of the “Sample Reference #” is optional, but if not used here, all of the sample’s serial numbers or other identifiers in the third column will need to be included in the reporting findings Sample Ref #:

Modified p. 20 → 23

(optional) Sample Size Serial Numbers of Tested ~~Devices/Other~~ Identifiers Sampling Rationale

Sample Ref #: (optional) PTS and/or FIPS Approval # Sample Size (x of y) Serial Numbers of Tested Devices / Other Identifiers Sampling Rationale

Removed p. 21

Not used in P2PE 1-1      1-3      1-4

Modified p. 21 → 25

~~4. Findings and Observations~~ Key Management Services

• Summary of Findings Reference Appendix I: P2PE Applicability of Requirements in the P2PE ~~v3.0~~ Program Guide.

Key Management Services

• Summary of Findings Reference Appendix I: P2PE Applicability of Requirements in the latest P2PE v3.x Program Guide.

Modified p. 21 → 25

KLCP Key Loading Component Provider KMCP Key Management Component Provider KIF Key Injection Facility CA/RA Certification Authority/Registration Authority SP Solution Provider (or MMS as a Solution Provider) RKD Remote Key Distribution Key Management Services: P2PE Validation Requirements Summary of Findings (check one) In Place N/A Not in ~~Place~~ Applies to:

KLCP Key Loading Component Provider KMCP Key Management Component Provider KIF Key Injection Facility CA/RA Certification Authority/Registration Authority SP Solution Provider (or MMS as a Solution Provider) RKD Remote Key Distribution (denotes additional requirements) Key Management Services: P2PE Validation Requirements Summary of Findings (check one) KMCP KLCP KIF CA/RA RKD SP Control Objective and Requirements In Place N/A Not in Applies to: Control Objective 1:

Modified p. 22 → 26

Cryptographic keys used for account-data encryption/decryption and related key management 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 ~~    5-1     6-1     6-2     6-3     6-4     6-5     6-6     7-1     7-2~~ …

Cryptographic keys used for account-data encryption/decryption and related key management 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 Applies to:

Modified p. 22 → 26

Keys are conveyed or transmitted in a secure manner ~~     8-1      8-2      8-3      8-4     9-1     9-2     9-3~~

Keys are conveyed or transmitted in a secure manner

Removed p. 30

Table 4.1

• Key Matrix. List of all cryptographic keys (by type) used in P2PE Solution/Component Key type/ description:

Algorithm

• e.g., TDEA, AES, RSA Cryptographic Mode(s) of Operation (as applicable ) Full Key Length (bits) Purpose/function of the key (including types of devices using key):

How key is distributed

• e.g., manually via courier, and/or via remote key distribution (RKD).

Types of media used for key storage:

Method of key destruction:

P2PE Key Management Services

• Reporting Key Management Services

• Reporting to Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1-1 Not used in P2PE 1-2 Key-injection facilities must only inject keys into equipment that conforms to the requirements for SCDs.

Modified p. 30 → 34

Documented procedures reviewed: <Report Findings Here>

Documented procedures reviewed: <Report Findings Here> 1-3 All hardware security modules (HSMs) must be either:

Removed p. 31

<Report Findings Here> 1-4 The approval listing must match the deployed devices in the following characteristics:

Modified p. 31 → 34

• ~~FIPS140-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. 31 → 34

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

Modified p. 31 → 35

• 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 ~~For each PCI-approved HSM used, describe how the observed HSM device configurations verified~~ that all of the device characteristics ~~at 6A-1.4.a~~ match the PTS ~~listing:~~

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

Modified p. 32 → 35

~~• Any applications, including application version number, resident within the device which were included in the PTS assessment~~ <Report Findings Here> 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 or 140-3 Level 3 (or higher) approval listing for each HSM:

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

Modified p. 32 → 35

• The FIPS 140 Approval Number For each FIPS-approved HSM used, describe how the observed HSM device configurations verified that all of the device characteristics at 6A-1.4.b match the ~~FIPS140-2~~ Level 3 (or higher) approval listing:

• The FIPS 140 Approval Number For each FIPS-approved HSM used, describe how the observed HSM device configurations verified that all of the device characteristics at 6A-1.4.b match the FIPS140- 2 Level 3 (or higher) approval listing:

Modified p. 32 → 36

Relevant personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 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.

Relevant personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 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.

Modified p. 32 → 36

Relevant personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here>

Relevant personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 1-5.c Examine the key-management flows and interview personnel to verify:

Removed p. 33

• approved HSM or POI device

Modified p. 33 → 37

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

<Report Findings Here> 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. 33 → 37

• An approved key-generation function of a PCI

• An approved key-generation function of a PCI •approved HSM or POI device

Modified p. 33 → 37

• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 Documented ~~POI~~ configuration and deployment procedures examined:

• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 Documented configuration and deployment procedures examined:

Removed p. 34

• approved HSM or POI device

Modified p. 34 → 37

• An approved key-generation function of a PCI

• An approved key-generation function of a PCI •approved HSM or POI device

Modified p. 34 → 37

Identify the P2PE Assessor who confirms that devices used for ~~key- generation~~ are those noted above, including validation of firmware used.

Identify the P2PE Assessor who confirms that devices used for key-generation are those noted above, including validation of firmware used.

Modified p. 34 → 38

• Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key Documented procedures examined: <Report Findings Here> ~~Responsible~~ personnel ~~interviewed: <Report Findings Here>~~

• Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key Documented procedures examined: <Report Findings Here> 6-1.1.b Observe key-generation process demonstration and interview responsible personnel to verify:

Modified p. 35 → 38

• Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian and not the entire key Describe how the key generation processes observed verified that 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:

• Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian and not the entire key Responsible personnel interviewed: <Report Findings Here> Describe how the key generation processes observed verified that 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:

Modified p. 35 → 38

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.

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. 35 → 38

<Report Findings Here> 6-1.2.b Examine key-generation logs to verify that:

<Report Findings Here> CA/RA 6-1.2.b Examine key-generation logs to verify that: Key-generation logs reviewed:

Modified p. 36 → 39

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

Modified p. 36 → 40

<Report Findings Here> 6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during ~~key-generation~~ processes where clear-text keying material is in use. It must not be feasible to observe any clear-text keying material either directly or via camera monitoring.

<Report Findings Here> 6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during key- generation processes where clear-text keying material is in use. It must not be feasible to observe any clear-text keying material either directly or via camera monitoring.

Removed p. 37

Documented procedures examined: <Report Findings Here> 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.

• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) or Describe how the single-purpose computers with an installed SCD verified that either:

Modified p. 37 → 41

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

Documented procedures examined: <Report Findings Here> 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.

Modified p. 37 → 41

<Report Findings Here> Describe how the generation process observed for each type of key verified that ~~multi-purpose~~ computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory:

<Report Findings Here> Describe how the generation process observed for each type of key verified that multi- purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory:

Removed p. 38

• 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

• Printers are not networked Describe how processes observed for printing key components verified 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:

Modified p. 38 → 41

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. 38 → 42

• Only approved key custodians can observe ~~their~~ the key component.

• Only approved key custodians can observe the key component.

Modified p. 38 → 42

<Report Findings Here> ~~6-3.b~~ Observe processes for printing key components to verify ~~that :~~

<Report Findings Here> 6-3.c Observe processes for printing key components to verify that:

Modified p. 39 → 42

Describe how ~~the blind mailers or other sealed containers used~~ for key components ~~observed~~ verified ~~that tampering can be visually detected:~~

Describe how processes observed for printing key components verified the criteria in the test procedure:

Modified p. 41 → 50

• Conveying clear-text private key shares or secret key components/shares without containing them within ~~tamper-evident~~ and authenticable packaging

• Conveying clear-text private key shares or secret key components/shares without containing them within tamper- evident and authenticable packaging

Modified p. 41 → 50

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

• 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. 43 → 52

<Report Findings Here> 7-2.b Observe demonstrations for the generation of ~~higher- level~~ keys to verify that all key-generation events are logged.

<Report Findings Here> 7-2.b Observe demonstrations for the generation of higher-level keys to verify that all key-generation events are logged.

Modified p. 44 → 53

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

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

Modified p. 44 → 53

Identify the P2PE Assessor who determined whether keys are transmitted encrypted, or as ~~clear- text~~ components, or within an SCD:

Identify the P2PE Assessor who determined whether keys are transmitted encrypted, or as clear-text components, or within an SCD:

Modified p. 45 → 54

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

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

Modified p. 45 → 54

<Report Findings Here> ~~Responsible personnel interviewed:~~

Modified p. 45 → 54

<Report Findings Here> Describe how the observed method to transport clear-text key components using tamper- evident mailers verified that details of the serial number of the package are transmitted separately from the package itself:

<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how the observed method to transport clear-text key components using tamper- evident mailers verified that details of the serial number of the package are transmitted separately from the package itself:

Modified p. 47 → 56

Documented ~~device- configuration~~ procedures examined:

Documented device-configuration procedures examined:

Removed p. 50

<Report Findings Here> 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. 50 → 59

<Report Findings Here> Describe how the observed process for conveying public keys verified that all methods ensure public keys are conveyed in a manner that protects their integrity and authenticity:

Responsible personnel interviewed: <Report Findings Here> Describe how the observed process for conveying public keys verified that all methods ensure public keys are conveyed in a manner that protects their integrity and authenticity:

Modified p. 50 → 60

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.

• Contained within a physically secure SCD. 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. 52 → 61

<Report Findings Here> 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.

Documented procedures reviewed: <Report Findings Here> 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. 52 → 61

<Report Findings Here> Describe how the processes observed verified that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened:

Responsible personnel interviewed: <Report Findings Here> Describe how the processes observed verified that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened:

Modified p. 53 → 62

<Report Findings Here> 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:

<Report Findings Here> 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. 53 → 62

• Any keys encrypted under this (combined) key Responsible personnel interviewed :

• Any keys encrypted under this (combined) key Responsible personnel interviewed : <Report Findings Here> Describe how the process observed verified that if a package shows signs of tampering, processes are implemented that result in the destruction and replacement of both:

Modified p. 53 → 62

• Any keys encrypted under this (combined) key <Report Findings Here> 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 <Report Findings Here> 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. 53 → 62

• Any keys encrypted under this (combined) key Documented records examined:

• Any keys encrypted under this (combined) key Documented records examined: <Report Findings Here>

Removed p. 54

<Report Findings Here> 9-4 Mechanisms must exist to ensure that only authorized custodians:

Removed p. 55

<Report Findings Here> 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.

Modified p. 55 → 65

Documented procedures reviewed:

Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed:

Modified p. 56 → 66

<Report Findings Here> 9-6.b Examine logs to verify that procedures are followed.

Documented procedures reviewed: <Report Findings Here> 9-6.b Examine logs to verify that procedures are followed.

Modified p. 57 → 67

<Report Findings Here> 10-1.c Observe key-generation processes for the key types identified above. 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 for RSA keys. To verify that:~~

Appropriate Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 10-1.c Observe key-generation processes for the key types identified above. Verify that all keys used to transmit or convey other cryptographic keys are at least as strong as any key Describe how the key-generation processes observed verified that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed, as delineated in Annex C.

Modified p. 57 → 68

- 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. - A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength. - TDEA keys are not used to protect AES keys. - TDEA keys are not be used to encrypt keys greater in strength than 112 bits. ~~- RSA keys …~~

• Verify that: - 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. - A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength. - TDEA keys are not used to protect AES keys. - TDEA keys are not be used to encrypt keys greater in strength than 112 bits.

Removed p. 58

<Report Findings Here> 11-2 Methods used for the conveyance or receipt of keys must be documented.

Modified p. 58 → 68

<Report Findings Here> 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.

Documented procedures examined: <Report Findings Here> 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. 58 → 68

Responsible personnel interviewed:

Responsible personnel interviewed: <Report Findings Here>

Modified p. 58 → 69

<Report Findings Here> 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.

Documented procedures reviewed: <Report Findings Here> 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. 58 → 69

<Report Findings Here> 12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key.

Documented procedures reviewed: <Report Findings Here> 12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key.

Modified p. 58 → 69

<Report Findings Here> 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.

Appropriate personnel interviewed: <Report Findings Here> 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.

Modified p. 61 → 72

Describe how the observed processes for loading clear-text cryptographic keys for all types of production SCDs verified that dual control is required to ~~authorized~~ any ~~key- loading~~ sessions, expected techniques are used, any passwords used are a minimum of five characters (default passwords/authentication codes are reset) and any passwords/authentication codes or tokens are maintained separately:

Describe how the observed processes for loading clear-text cryptographic keys for all types of production SCDs verified that dual control is required to authorize any key-loading sessions, expected techniques are used, any passwords used are a minimum of five characters (default passwords/authentication codes are reset) and any passwords/authentication codes or tokens are maintained separately:

Modified p. 61 → 72

<Report Findings Here> 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 length as the resultant key.

Documented procedures reviewed: <Report Findings Here> 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 length as the resultant key.

Modified p. 62 → 73

12-5.a 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.a 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.

Modified p. 62 → 73

<Report Findings Here> Identify the P2PE Assessor who corroborated how the HSM MFK is created:

Vendor documentation reviewed: <Report Findings Here> Identify the P2PE Assessor who corroborated how the HSM MFK is created:

Modified p. 62 → 73

<Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how it was confirmed that any devices that are loaded with the same key components use the same mathematical process to derive the final key:

Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how it was confirmed that any devices that are loaded with the same key components use the same mathematical process to derive the final key:

Modified p. 62 → 73

<Report Findings Here> 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:

<Report Findings Here> 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. 62 → 73

Documented procedures reviewed:

Documented procedures reviewed: <Report Findings Here>

Modified p. 63 → 74

<Report Findings Here> 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:

Documented procedures reviewed: <Report Findings Here> 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:

Removed p. 64

<Report Findings Here> 13-1 Clear-text secret and private keys and key components must be transferred into an SCD only when it can be ensured that:

Modified p. 64 → 75

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

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

• 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. - An SCD transfers a plaintext secret or private key only when at least two authorized individuals are identified by the device. - …

Modified p. 68 → 81

Personnel interviewed: <Report Findings Here> Media locations observed: <Report Findings Here>

Personnel interviewed: <Report Findings Here> Media locations observed: <Report Findings Here> 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:

Modified p. 70 → 82

<Report Findings Here> 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.~~

<Report Findings Here> 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 Describe how the observed key-component access controls and access logs verified that any single authorized custodian can only access their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key:

Removed p. 72

• 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. 72 → 85

- 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, and - Video surveillance logs with a minimum retention period of 45 days.

- 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,

Modified p. 72 → 85

<Report Findings Here> ~~13-9.4 Additionally:~~

Modified p. 74 → 88

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.

Modified p. 74 → 88

Describe how it was verified that if the PC application stores keys on portable electronic media:

Describe how it was verified that if the PC application reads or stores keys from portable electronic media:

Modified p. 74 → 88

• The key components are manually entered at the start of each ~~keyinjection~~

• The key components are manually entered at the start of each key injection

Removed p. 75

The secure room for key injection must include the following:

Removed p. 75

• 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.0 and higher devices.

Modified p. 76 → 90

<Report Findings Here> 14-3 Key-loading equipment usage must be ~~monitored~~ and a log of all key-loading and application-signing activities maintained for audit ~~purposes, containing~~ at a ~~minimum~~ date, time, personnel involved, and number of devices keys are loaded to.

<Report Findings Here> 14-3 Key-loading equipment usage must be monitored, and a log of all key-loading and application-signing activities maintained for audit purposes must contain, at a minimum, date, time, personnel involved, and number of devices keys are loaded to.

Modified p. 77 → 91

Access-control logs reviewed: <Report Findings Here> ~~14-4.e Reconcile storage contents to access-control logs. Identify the P2PE Assessor who reconciled storage contents to access-control logs:~~

Access-control logs reviewed: <Report Findings Here>

Removed p. 78

• Be within a certificate as defined in applicable requirements within this Domain; or

• Be within a PKCS#10 (authentication and integrity occurs via other mechanisms); or

• Be within an SCD; or

• Have a MAC (message authentication code) created using the algorithm defined in ISO 16609.

Modified p. 78 → 93

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

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). wherein the second method the KCV is calculated by MACing an all binary zeros block using the …

Modified p. 78 → 94

Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here>

Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 15-2.b Observe public-key stores and mechanisms to verify that public keys exist only in an approved form.

Removed p. 79

<Report Findings Here> 15-3.b Interview applicable personnel to verify that mutual authentication of the sending and receiving devices is performed, as follows:

Modified p. 79 → 94

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.

<Report Findings Here> 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.

Removed p. 81

<Report Findings Here> 16-2 All key-loading events must be documented. Audit trails must be in place for all key-loading events.

Modified p. 81 → 98

SP 17-1.a Examine the documented key matrix and operational procedures and interview personnel to determine whether any ~~Documented key matrix reviewed:~~

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.

Modified p. 82 → 98

Documented operational procedures <Report Findings Here> Personnel interviewed: <Report Findings Here> 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:

<Report Findings Here> Documented operational procedures <Report Findings Here> Personnel interviewed: <Report Findings Here> 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:

Modified p. 82 → 98

• 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 of the original conveyance of the keying material, but rather on values generated from stored zone production keys from the production host database. Cryptograms may be …

• 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 of the original conveyance of the keying material, but rather on values generated from stored zone production keys from the production host database. Cryptograms may be used …

Modified p. 84 → 101

• 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. 84 → 101

• 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. 84 → 101

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

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

Modified p. 85 → 102

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

Modified p. 88 → 105

<Report Findings Here> ~~19-2 Private keys:~~

Modified p. 88 → 106

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

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

Removed p. 89

<Report Findings Here> 19-4 Keys must never be shared or substituted between production and test/development systems.

Removed p. 91

<Report Findings Here> 19-7 KDH private keys must not be shared between devices except for load balancing and disaster recovery.

Modified p. 91 → 108

<Report Findings Here> 19-6 Key pairs must not be reused for certificate renewal or replacement•i.e., new key pairs must be generated.

<Report Findings Here> 19-6 Key pairs must not be reused for certificate renewal or replacement•i.e., new key pairs must be generated. Each key pair must result in only one certificate.

Removed p. 94

<Report Findings Here> 19-12 Certificates used in conjunction with remote key-distribution functions must only be used for a single purpose.

Removed p. 95

<Report Findings Here> 19-12.c If CA separation is used to ensure certificate segmentation, confirm that the following are true:

Modified p. 96 → 114

• Certificates issued for all of the remote ~~key-distribution~~ functions (i.e. encryption, POI authentication, or KDH authentication) include a mechanism to identify designation for this purpose.

• Certificates issued for all of the remote key- distribution functions (i.e. encryption, POI authentication, or KDH authentication) include a mechanism to identify designation for this purpose.

Modified p. 97 → 115

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.

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. 99 → 117

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 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 derivation of other keys once loaded•e.g., as done with DUKPT.

Modified p. 101 → 119

• 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 20-6.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including:

Removed p. 102

<Report Findings Here> 21-1 Secret or private keys must only exist in one or more of the following forms:

<Report Findings Here> Describe how the key stores observed verified that secret or private keys only exist in one or more approved forms at all times when stored:

<Report Findings Here> 21-2.3 Each key component/share must have one or more specified authorized custodians.

Removed p. 104

<Report Findings Here> 21-3 Key components/shares must be stored as follows:

Modified p. 105 → 124

~~<Report Findings Here>~~ 21-3.3 If a key ~~component/share~~ is stored on a token, and an access code ~~(e.g., a PIN~~ or similar ~~access-control~~ mechanism) is used to access the token, only that token’s owner or designated backup(s) ~~must have~~ possession of both the token and its access code.

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.

Removed p. 106

<Report Findings Here> 22-1 Procedures for known or suspected compromised keys must include the following:

Modified p. 106 → 124

• Within a secure cryptographic device that meets applicable PCI 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. 106 → 124

• 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. 106 → 124

• As components using a recognized (e.g., Shamir) ~~secret-sharing scheme.~~

• As components using a recognized secret-sharing scheme (e.g., Shamir) that are at all times managed under dual control and split knowledge.

Modified p. 107 → 126

Note: The compromise of a key must result in the replacement and destruction of that key and all variants and ~~non-reversible~~ transformations of that key, as well as all keys encrypted under or derived from that key.

Note: The compromise of a key must result in the replacement and destruction of that key and all variants and non- reversible transformations of that key, as well as all keys encrypted under or derived from that key.

Modified p. 107 → 126

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

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

Removed p. 109

<Report Findings Here> 22-1.5 Identification of specific events that would indicate a compromise may have occurred. Such events must include but are not limited to:

Removed p. 111

<Report Findings Here> 22-4.3 Mechanisms (e.g., time stamping) must exist to prevent the usage of fraudulent certificates, once identified.

Removed p. 112

<Report Findings Here> 22-5 Minimum cryptographic strength for the CA system must be:

Modified p. 112 → 131

• The CA performs a damage assessment to determine the need to either:

• The CA performs a damage assessment to determine the need to either: - Reissues and distributes certificates to affected parties, or - Notifies the affected parties to apply for new certificates.

Modified p. 112 → 132

• ~~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. 113 → 133

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. 113 → 134

~~<Report Findings Here> 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~~ Describe how the review of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys used verified that variants of the MFK are not used external to the logical configuration that houses the MFK:

Describe how the review of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys used verified that variants of the MFK are not used external to the logical configuration that houses the MFK:

Modified p. 114 → 134

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.

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

<Report Findings Here> Key-history logs examined: <Report Findings Here>

<Report Findings Here> Key-history logs examined: <Report Findings Here> Key-destruction logs examined: <Report Findings Here> 24-1.c Examine storage locations for the sample of destroyed keys to verify they are no longer kept.

Modified p. 116 → 137

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.

Removed p. 117

<Report Findings Here> 25-1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.

Modified p. 117 → 139

• Signature of management authorizing the access

• Signature of management authorizing the access 25-1.3 Examine all key-custodian forms to verify that they include the following:

Modified p. 118 → 140

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.

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. 120 → 142

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

• Outside network access shall exist only for the purposes of “pushing” certificate- status information to relying parties (e.g., KDHs) <Report Findings Here> 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).

Modified p. 122 → 144

• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) <Report Findings Here> ~~25-5 All CA systems that are not operated exclusively offline must be hardened to prevent insecure network access, to include:~~

• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) <Report Findings Here>

Removed p. 123

<Report Findings Here> 25-5.1 All vendor-default IDs must be changed, removed, or disabled unless necessary for a documented and specific business reason.

<Report Findings Here> 25-6 Audit trails must include but not be limited to the following:

Modified p. 125 → 149

Sample of certificate issuances ~~Examined:~~ <Report Findings Here> Audit records examined: <Report Findings Here> 25-6.2.b For a sample of certificate revocations, examine audit records to verify that the records are retained for at least the life of the associated certificate.

Sample of certificate issuances <Report Findings Here> Audit records examined: <Report Findings Here> 25-6.2.b For a sample of certificate revocations, examine audit records to verify that the records are retained for at least the life of the associated certificate.

Modified p. 125 → 149

Sample of certificate revocations ~~examined:~~ <Report Findings Here> Audit records examined: <Report Findings Here> 25-6.3 Logical events are divided into operating-system and CA application events. For both, the following must be recorded in the form of an audit record:

Sample of certificate revocations <Report Findings Here> Audit records examined: <Report Findings Here> 25-6.3 Logical events are divided into operating-system and CA application events. For both, the following must be recorded in the form of an audit record:

Modified p. 126 → 150

The signing/MACing key(s) used for this must be protected using a secure cryptographic device in accordance with the ~~key-management~~ requirements stipulated in this document.

The signing/MACing key(s) used for this must be protected using a secure cryptographic device in accordance with the key- management requirements stipulated in this document.

Modified p. 127 → 151

• Notify the firewall administrator in near real time of any item that may need immediate attention such as a ~~break-in,~~ little disk space available, or other related messages so that an immediate action can be taken.

• Notify the firewall administrator in near real time of any item that may need immediate attention such as a break- in, little disk space available, or other related messages so that an immediate action can be taken.

Modified p. 131 → 155

<Report Findings Here> Describe how the observed time-related system parameters verified that system clocks and times are synchronized for all systems involved in ~~keymanagement~~ operations:

<Report Findings Here> Describe how the observed time-related system parameters verified that system clocks and times are synchronized for all systems involved in key management operations:

Modified p. 131 → 155

Documented procedures examined: <Report Findings Here> ~~25.9.d If a manual process is defined, examine system configurations and synchronization logs to verify that the process occurs at least quarterly.~~

Documented procedures examined: <Report Findings Here>

Removed p. 132

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

Modified p. 132 → 156

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

<Report Findings Here> 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:

Modified p. 132 → 157

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

• Securely stored Log files examined: <Report Findings Here> 26-1.d Examine log files and audit log settings to verify that logs include the following:

Modified p. 132 → 157

~~Audit trail files examined:~~ <Report Findings Here> Describe how the audit train files examined verified that they are archived for a minimum of two years subsequent to key destruction.

• Tamper-evident package number (if applicable) <Report Findings Here> Describe how the audit train files examined verified that they are archived for a minimum of two years subsequent to key destruction.

Modified p. 133 → 158

• Subject to at least the same level of security control as operational keys as specified in this document <Report Findings Here>

• Subject to at least the same level of security control as operational keys as specified in this document <Report Findings Here> 27-2 If backup copies are created, the following must be in place:

Removed p. 139

<Report Findings Here> 29-1.1.b Verify that documented procedures include 29-1.1.1 through 29-1.1.3 below.

Modified p. 139 → 166

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

Removed p. 140

• All personnel with access to POI devices and other SCDs are authorized by management.

Modified p. 140 → 166

<Report Findings Here> ~~29-1.1.2 Intentionally left blank.~~

Modified p. 140 → 167

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

Removed p. 141

<Report Findings Here> 29-2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt to placement into service.

Removed p. 142

- Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and - Can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.

• 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. 142 → 169

• Transportation uses a trusted courier service (e.g., via bonded carrier). The devices are then securely stored until ~~key-insertion~~ occurs.

• Transportation uses a trusted courier service (e.g., via bonded carrier). The devices are then securely stored until key- insertion occurs.

Modified p. 142 → 169

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

• 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. 142 → 169

Note: Unauthorized access includes that by customs officials.

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.

Removed p. 146

<Report Findings Here> 30-3 Processes must exist to ensure that key-injection operations are performed and reconciled on an inventory of pre-authorized devices.

Modified p. 147 → 175

<Report Findings Here> 31-1 Procedures must be 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 manner, including rendering all secret and private keys, key material, and account data stored within the device 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. 147 → 175

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.

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.

Removed p. 149

<Report Findings Here> 32-1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.

Modified p. 149 → 178

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.

For devices that do not support two or more passwords/authentication codes (at least five characters in length), 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.

Removed p. 150

<Report Findings Here> 32-1.3 Dual control must be implemented for the following:

<Report Findings Here> 32-1.5 To detect any unauthorized use, devices are at all times within a secure room and either:

Modified p. 151 → 180

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

• Locked in a secure cabinet and/or sealed in ~~tamper-evident~~ packaging at all times, or

• Locked in a secure cabinet and/or sealed in tamper- evident packaging at all times, or

Modified p. 151 → 180

• Locked in a secure cabinet and/or sealed in ~~tamper-evident~~ packaging at all times, or

• Locked in a secure cabinet and/or sealed in tamper- evident packaging at all times, or

Modified p. 152 → 181

• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices <Report Findings Here> ~~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 <Report Findings Here>

Removed p. 153

<Report Findings Here> Level 2 Barrier 32-2.3 The Level 2 barrier/entrance must only allow authorized personnel beyond this entrance.

Removed p. 154

<Report Findings Here> 32-2.4 The Level 2 entrance must be monitored by a video-recording system.

Removed p. 156

<Report Findings Here> 32-2.6.1 All authorized personnel with access through the Level 3 barrier must:

Removed p. 158

<Report Findings Here> 32-2.7.3 Dual occupancy requirements are managed using electronic (e.g., badge and/or biometric) systems.

Modified p. 158 → 188

<Report Findings Here> Security personnel interviewed: <Report Findings Here>

<Report Findings Here> Security personnel interviewed: <Report Findings Here> 32-2.8 Access to the Level 3 room must create an audit event, which must be logged.

Removed p. 159

<Report Findings Here> 32-2.8.1 Invalid access attempts to the Level 3 room must create audit records, which must be followed up by security personnel.

Removed p. 160

<Report Findings Here> 32-2.9.3 Continuous or motion-activated, appropriate lighting must be provided for the cameras.

Removed p. 162

<Report Findings Here> 32-3.2 Any windows or glass walls must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.

Removed p. 163

<Report Findings Here> 32-3.4 Alarm activity must include unauthorized entry attempts or any actions that disable the intrusion-detection system.

Modified p. 164 → 194

• For visitor access, the initials of the person escorting the visitor <Report Findings Here> ~~32-4.2 The logbook must be maintained within the Level 3 secure environment.~~

• For visitor access, the initials of the person escorting the visitor <Report Findings Here>

Modified p. 165 → 195

<Report Findings Here> Alarm event records reviewed: <Report Findings Here> ~~32-6.2 The use of any emergency entry or exit mechanism must cause an alarm event.~~

<Report Findings Here> Alarm event records reviewed: <Report Findings Here>

Removed p. 168

<Report Findings Here> 32-8.6 Mutual authentication of the sending and receiving devices must be performed.

Removed p. 169

• Effective 1 January 2023, the same restriction applies to entities engaged in key injection of devices for which they are the processors.

<Report Findings Here> 32-9.2 Any windows into the secure room must be locked and protected by alarmed sensors.

Removed p. 170

<Report Findings Here> 32-9.5 An electronic access control system (e.g., badge and/or biometrics) must be in place that enforces:

Removed p. 171

Describe how the observation of authorized personnel entering the secure area verified that a badge-control system is in place that enforces the following requirements:

• Dual-access for entry to the secure area

<Report Findings Here> 32-9.8 Monitoring must be supported on a continuous (24/7) basis such that alarms can be resolved by authorized personnel.

Modified p. 171 → 203

~~• Anti-pass-back~~ <Report Findings Here> 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.

<Report Findings Here> 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. 171 → 203

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.

Modified p. 171 → 203

<Report Findings Here> Describe how the CCTV configurations observed verified that CCTV monitoring is in places on a 24/7 ~~basis:~~

<Report Findings Here> Describe how the CCTV configurations observed verified that CCTV monitoring is in places 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. 172

<Report Findings Here> 32-9.10 The CCTV cameras must be positioned to monitor:

Modified p. 177 → 211

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.

• Details of any known or suspected compromised keys, per 22-1 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.

Document Comparison

From Revision History

Content Changes