Document Comparison
PCI-P2PE-KMS-ROV-Template_v3_1.pdf
→
PCI-P2PE-KMS-ROV-Template-v3.2.pdf
89% similar
212 → 206
Pages
71661 → 70051
Words
738
Content Changes
Content Changes
738 content changes. 252 administrative changes (dates, page numbers) hidden.
Added
p. 2
July 2025 3.2 1.0 This template includes the following updates:
- Updates from the PCI P2PE Standard v3.2 - Updates based on stakeholder feedback - Errata updates to section 4
- Updates from the PCI P2PE Standard v3.2 - Updates based on stakeholder feedback - Errata updates to section 4
Added
p. 6
Note: A separate Merchant-Managed Solution P-ROV is used as part of validating MMS.
Validation of P2PE Component services provided by an EMCP, PDCP, or a PMCP must use this P- ROV.
This applies for both P2PE Applications intended to be Listed, as well as P2PE Applications that are not intended to be Listed and are assessed only as part of, and allowed for use in, a specific P2PE Solution (Solution-specific P2PE Applications).
Note: Validation of a P2PE Application must be performed by a qualified P2PE Application Assessor Company.
Validation of P2PE Solutions that do not outsource the entirety of their Decryption Management Services to a Listed DMCP must include this P-ROV in addition to a Solution P-ROV.
Validation of P2PE Component services provided by a DMCP must use this P-ROV.
Validation of P2PE Component services provided by an EMCP, PDCP, or a PMCP must use this P- ROV.
This applies for both P2PE Applications intended to be Listed, as well as P2PE Applications that are not intended to be Listed and are assessed only as part of, and allowed for use in, a specific P2PE Solution (Solution-specific P2PE Applications).
Note: Validation of a P2PE Application must be performed by a qualified P2PE Application Assessor Company.
Validation of P2PE Solutions that do not outsource the entirety of their Decryption Management Services to a Listed DMCP must include this P-ROV in addition to a Solution P-ROV.
Validation of P2PE Component services provided by a DMCP must use this P-ROV.
Added
p. 8
• Brief description/short answer
• Provide sufficient detail and information to demonstrate a finding of “in place” or “not applicable”
• Don’t include forward-looking statements or project plans in responses
P2PE Assessor Company and Lead Assessor Contact Information Company name: Assessor company credentials: P2PE Assessor P2PE Application Assessor Assessor name: Assessor credentials: P2PE Assessor P2PE Application Assessor Assessor phone number: Assessor e-mail address:
• Disclose all services offered to the assessed entity by the P2PE Assessor / P2PE Assessor 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 P2PE Assessor company, or to which the P2PE Assessor company owns the rights or that the P2PE Assessor company has configured or manages:
• Provide sufficient detail and information to demonstrate a finding of “in place” or “not applicable”
• Don’t include forward-looking statements or project plans in responses
P2PE Assessor Company and Lead Assessor Contact Information Company name: Assessor company credentials: P2PE Assessor P2PE Application Assessor Assessor name: Assessor credentials: P2PE Assessor P2PE Application Assessor Assessor phone number: Assessor e-mail address:
• Disclose all services offered to the assessed entity by the P2PE Assessor / P2PE Assessor 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 P2PE Assessor company, or to which the P2PE Assessor company owns the rights or that the P2PE Assessor company has configured or manages:
Added
p. 25
Not used in P2PE 1-1 1-3 1-4
Added
p. 33
The Assessor may use the reference number throughout the reporting section, rather than providing a narrative for each N/A requirement.
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment Note: If the solution/component provider has applied a vendor security patch resulting in an updated HSM firmware version, and the PCI SSC or NIST validation of that updated firmware version has not yet been completed (resulting in a mismatch between the HSM firmware version in use and the listed, validated one), the solution provider must obtain documentation from the vendor regarding the update that includes confirmation the update has been submitted for evaluation per the process specified by either PCI SSC or NIST (as applicable to the HSM).
<Report Findings Here> 1-4.c If the solution/component provider has applied a vendor security patch that resulted in an updated HSM firmware version, and …
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment Note: If the solution/component provider has applied a vendor security patch resulting in an updated HSM firmware version, and the PCI SSC or NIST validation of that updated firmware version has not yet been completed (resulting in a mismatch between the HSM firmware version in use and the listed, validated one), the solution provider must obtain documentation from the vendor regarding the update that includes confirmation the update has been submitted for evaluation per the process specified by either PCI SSC or NIST (as applicable to the HSM).
<Report Findings Here> 1-4.c If the solution/component provider has applied a vendor security patch that resulted in an updated HSM firmware version, and …
Added
p. 39
<Report Findings Here> Describe how the key-generations processes observed verified that there is no mechanism (including connectivity) that might disclose a cleartext key or key component between the key-generation device and the device or medium receiving the key or key component:
Key-generation logs examined:
<Report Findings Here> 6-1.3 Devices used for the generation of cleartext key components that are output in the clear must either be powered off when not in use or require re-authentication whenever key generation is invoked.
Key-generation logs examined:
<Report Findings Here> 6-1.3 Devices used for the generation of cleartext key components that are output in the clear must either be powered off when not in use or require re-authentication whenever key generation is invoked.
Added
p. 42
<Report Findings Here> 6-3 Printed key components must be protected against compromise. Key components must be printed in a way that prevents observation by any party other than the approved key custodian(s) of those components. Key components transmitted electronically prior to printing must be secured during transmission, and the equipment used for the printing process must be secured to prevent compromise and storage of the components.
The following sub-requirements are applicable to the printing of key components:
6-3.a Examine documented procedures for printed key components and verify the requirement is satisfied.
Describe how the interviews performed and processes observed verified that the requirement is satisfied:
The following sub-requirements are applicable to the printing of key components:
6-3.a Examine documented procedures for printed key components and verify the requirement is satisfied.
Describe how the interviews performed and processes observed verified that the requirement is satisfied:
Added
p. 53
8-1.a Examine documentation and interview personnel (as needed) to determine whether keys are transmitted encrypted, as cleartext components/shares, and/or within an SCD. Carry out the additional testing procedures as applicable.
• Examine documented procedures for sending components in tamper-evident, authenticable packaging to verify that: - They define how the details of the package serial number are to be transmitted - There is a requirement that the package serial number is to be sent separately from the package itself - Each component is to be sent to/from only the custodian(s) authorized for the component - At least two communication channels are used to send the components of a given key (not just separation by sending on different days) - Prior to the use of the components, the serial numbers are to be confirmed
• Examine documentation (e.g., record of past key transfers), interview personnel and observe as needed to verify that the process …
• Examine documented procedures for sending components in tamper-evident, authenticable packaging to verify that: - They define how the details of the package serial number are to be transmitted - There is a requirement that the package serial number is to be sent separately from the package itself - Each component is to be sent to/from only the custodian(s) authorized for the component - At least two communication channels are used to send the components of a given key (not just separation by sending on different days) - Prior to the use of the components, the serial numbers are to be confirmed
• Examine documentation (e.g., record of past key transfers), interview personnel and observe as needed to verify that the process …
Added
p. 65
• Observe the method used to transport cleartext key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself
9-6.a Examine documents, interview personnel, and observe processes as needed to verify that:
Documented procedures examined: <Report Findings Here> 10-1.b Examine documented procedures and interview personnel as needed to verify the requirement is satisfied for all applicable keys. Consider keys manually transferred (e.g., cryptograms sent to an Encryption and Support Organisation ( ESO)) as well as those that are system-generated and transferred (e.g., KEK or TMK encrypting working keys).
Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> Keys identified that protect other keys for transmission:
9-6.a Examine documents, interview personnel, and observe processes as needed to verify that:
Documented procedures examined: <Report Findings Here> 10-1.b Examine documented procedures and interview personnel as needed to verify the requirement is satisfied for all applicable keys. Consider keys manually transferred (e.g., cryptograms sent to an Encryption and Support Organisation ( ESO)) as well as those that are system-generated and transferred (e.g., KEK or TMK encrypting working keys).
Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> Keys identified that protect other keys for transmission:
Added
p. 67
Documented procedures observed: <Report Findings Here>
12-1.a Examine documented procedures, interview personnel, and observe processes as needed to verify the requirement is satisfied for all applicable keys.
12-1.a Examine documented procedures, interview personnel, and observe processes as needed to verify the requirement is satisfied for all applicable keys.
Added
p. 71
• Any passwords/authentication codes or tokens are maintained separately Describe how the observed processes for loading cleartext cryptographic keys for all sampled production POI device verified that
Added
p. 83
<Report Findings Here> 14-4 Any physical tokens (e.g., brass keys or chip cards) used to enable key loading must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control. These tokens must be secured in a manner similar to key components, including tamper- evident, authenticable packaging and the use of access-control logs for when removed or placed into secure storage.
Added
p. 84
Access-control logs examined: <Report Findings Here> 14-4.e Examine documented procedures, interview personnel, and observe processes as needed to reconcile storage contents to access-control logs.
Added
p. 87
<Report Findings Here> 15-3.b Interview applicable personnel to verify that mutual authentication of the sending and receiving devices is performed, as follows:
Added
p. 109
Note: The same BDK with the same KSN installed in multiple injection systems or installed multiple times within the same injection system will not meet uniqueness requirements.
Added
p. 110
• Unique data is used for the derivation process such that all transaction-originating PTS POI devices receive unique secret keys
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating PTS POI <Report Findings Here> 20-3.b Examine/observe to verify that derivation keys used to generate keys for multiple devices are never loaded into a PTS POI device.
<Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how the observed key-injection processes for devices associated with different acquiring organizations verified that Base Derivation Key(s) unique to each organization are used:
• Key pairs must be unique per PTS POI device.
<Report Findings Here> 21-2 Wherever key components/shares are used, they must have the following properties:
21-2 Examine documented procedures and interview personnel to determine all instances where key components/shares are used.
<Report Findings Here> 21-2.1 Knowledge of any one key component/share does not convey any knowledge of any part of the actual …
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating PTS POI <Report Findings Here> 20-3.b Examine/observe to verify that derivation keys used to generate keys for multiple devices are never loaded into a PTS POI device.
<Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how the observed key-injection processes for devices associated with different acquiring organizations verified that Base Derivation Key(s) unique to each organization are used:
• Key pairs must be unique per PTS POI device.
<Report Findings Here> 21-2 Wherever key components/shares are used, they must have the following properties:
21-2 Examine documented procedures and interview personnel to determine all instances where key components/shares are used.
<Report Findings Here> 21-2.1 Knowledge of any one key component/share does not convey any knowledge of any part of the actual …
Added
p. 116
Identify the P2PE Assessor who confirms that cleartext key components to verify they do not exist in non-secure containers, such as databases or in software programs:
Added
p. 136
<Report Findings Here> 25-3 The system enforces an explicit and well-defined certificate security policy and certification practice statement. This must include the following:
Added
p. 142
<Report Findings Here> Describe how the examined audit trails for a sample of key-management operations verified they include:
Added
p. 147
25-8.5 For a sample of system components, examine system configuration settings to verify that authentication parameters are set to require that a user’s account be locked out after not more than five invalid logon attempts.
Added
p. 156
• Determination that the requestor is valid, which may include, but not limited to, verifying that the: o organization exists by using at least one third-party identity-proofing service or database o organizational documentation issued by or filed with the applicable government agency or competent authority confirms the existence of the organization
Added
p. 161
<Report Findings Here> 29-2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt to placement into service.
Documented records examined: <Report Findings Here> 29-3 Implement physical protection of devices from the manufacturer’s facility up to the point of key-insertion or deployment, through one or more of the following:
Note: Dual-control mechanisms can include any manner of physical and/or logical means that satisfies the objective.
• throughout their life cycle:
Documented records examined: <Report Findings Here> 29-3 Implement physical protection of devices from the manufacturer’s facility up to the point of key-insertion or deployment, through one or more of the following:
Note: Dual-control mechanisms can include any manner of physical and/or logical means that satisfies the objective.
• throughout their life cycle:
Added
p. 167
<Report Findings Here> 30-3 Processes must exist to ensure that key-injection operations are performed and reconciled on a defined inventory of devices.
Added
p. 171
<Report Findings Here> 32-1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
Added
p. 205
• Types/models of PTS POI devices and/or HSMs for which keys have been injected
• For each type/model of PTS POI device and/or HSM: o Number of devices o Type of key(s) injected o Key-distribution method
• Details of any known or suspected compromised keys, per 22-1 Note: Adding, changing, or removing PTS POI devices and/or HSM types, or critical key-management methods may require Delta Change. Please refer to the PCI P2PE Program Guide for details about obligations when adding, changing, or removing elements of a Listed P2PE Product.
5I-1.1.a Examine the component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component- provider personnel to confirm that the following processes are documented and implemented:
• For each type/model of PTS POI device and/or HSM: o Number of devices o Type of key(s) injected o Key-distribution method
• Details of any known or suspected compromised keys, per 22-1 Note: Adding, changing, or removing PTS POI devices and/or HSM types, or critical key-management methods may require Delta Change. Please refer to the PCI P2PE Program Guide for details about obligations when adding, changing, or removing elements of a Listed P2PE Product.
5I-1.1.a Examine the component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component- provider personnel to confirm that the following processes are documented and implemented:
Modified
p. 1
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
Payment Card Industry (PCI) Point-to-Point Encryption (P2PE)® Key Management Services Template for Report on Validation For use with the PCI P2PE Standard v3.2 for P2PE Key Management Services Assessments
Modified
p. 5
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).
KMS Component Assessments: Use of this Reporting Template is mandatory for all P2PE v3.2 Key Management Services Component Provider assessments (i.e., for a KIF, KMCP, KLCP, or a CA/RA assessment).
Modified
p. 5
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.
Solution Assessments: Use of this Reporting Template is mandatory for all P2PE v3.2 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. 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 …
A P2PE 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 …
Modified
p. 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. 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, …
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 PCI-approved PTS POI devices in a P2PE Solution. Validation of P2PE Solutions that do not outsource the entirety of their Encryption Management Services to Listed P2PE Component Providers, either to an EMCP or to BOTH a PDCP AND a PMCP, must include this P-ROV in addition to a Solution P-ROV.
Modified
p. 6
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).
P2PE Application P2PE Application Validation of a P2PE Application (software on the PCI-approved POI device intended for use in a P2PE Solution that has the potential to access cleartext cardholder data) must use this P-ROV.
Modified
p. 6
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.
Decryption Management Services (DMS) P2PE Solution (SP) Decryption Management CP (DMCP) “Decryption Management Services” relates to the management of a decryption environment, including applicable devices (for example, HSMs) used to support a P2PE Solution.
Modified
p. 6
Key Management Services (KMS) Solution (SP) Key Injection Facility (KIF) Key Management CP (KMCP) Key Loading CP (KLCP) Key Management Services relates to the generation, conveyance, management, and loading of cryptographic keys including the management of associated devices.
Key Management Services (KMS) P2PE Solution (SP) Key Injection Facility (KIF) Key Management CP (KMCP) Key Loading CP (KLCP) “Key Management Services” relates to the generation, conveyance, management, and loading of cryptographic keys including the management of associated devices (POI devices, HSMs, etc.).
Modified
p. 6
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 …
Validation of a P2PE Solution that has not satisfied the key management services requirements (Domain 5) either using Listed 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 PCI-approved PTS POI devices for use in connection with account-data
Modified
p. 6 → 7
Component Provider assessments for a KIF, KMCP, KLCP, or a CA/RA must complete the KMS P- ROV.
Validation of P2PE Component services provided by a KIF, KMCP, KLCP, and a CA/RA must complete this P-ROV.
Modified
p. 7
Section 1: Contact Information and Report Date
• Section 1: Contact Information and Report Date
Modified
p. 7
Section 2: Summary Overview
• Section 2: Summary Overview
Modified
p. 7
Section 3: Details and Scope of P2PE Assessment
• Section 3: Details and Scope of P2PE Assessment
Modified
p. 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. 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 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 …
P-ROV Summary of Findings 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 validation status is at section 2.8 “Summary of P2PE Assessment Compliance Validation Status.” The following table provides guidance for Assessors when considering which selection to make. Assessors must select only one response at the sub- requirement level, and the …
Modified
p. 7 → 8
Note: Checkboxes have been added to the “Summary of Assessment Findings” so that the assessor may double click to check the applicable summary result. Hover over the box you’d like to mark and click once to mark with an ‘x.’ To remove a mark, hover over the box and click again. Mac users may instead need to use the space bar to add the mark.
Note: Checkboxes have been added to the “Summary of Assessment Findings” so that the Assessor may double-click to check the applicable summary result. Hover over the box to select and single-click to mark with an ‘x.’ To remove a mark, hover over the box and click again. Mac users may instead need to use the space bar to select a box.
Modified
p. 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. 8
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.
• 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. 8
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.
• 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.
Modified
p. 8
• “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.
• “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.
Modified
p. 9
Complete all applicable P-ROVs based on the assessment type.
• 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
• 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 include forward-looking statements or project plans in responses.
• Don’t report items in the “In Place” column unless they have been verified as being “in place”
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. 9
Don’t mark “N/A” without providing an explanation and justification for why it is “N/A”.
• Don’t mark “N/A” without providing an explanation and justification for why it is “N/A”
Removed
p. 10
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
Internal P2PE Assessor Company QA Review Affirm that internal QA was fully performed on the entire P2PE submission.
Modified
p. 10
Yes (Internal QA on this submission has been performed in accordance with PCI P2PE Program Requirements) QA Primary reviewer name: QA Primary reviewer credentials:
Modified
p. 10
QA Primary reviewer phone number: QA Primary reviewer e-mail address:
Modified
p. 10
Assessor name: Assessor credentials: QSA (P2PE) PA-QSA (P2PE) Assessor phone number: Assessor e-mail address:
Assessor name: Assessor credentials: P2PE Assessor P2PE Application Assessor Assessor phone number: Assessor e-mail address:
Removed
p. 11
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
(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 …
•
(From DD-MMM-YYYY To DD-MMM-YYYY) 1.3 Additional Services Provided by P2PE Assessor / P2PE Assessor Company The current version of the “Qualification Requirements for Point-to-Point Encryption (P2PE)TM
• P2PE Assessor and P2PE Application Assessors” (P2PE Qualification Requirements), section “Independence”, specifies requirements for P2PE Assessors 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 Qualification Requirements to ensure responses are consistent with documented …
• P2PE Assessor and P2PE Application Assessors” (P2PE Qualification Requirements), section “Independence”, specifies requirements for P2PE Assessors 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 Qualification Requirements to ensure responses are consistent with documented …
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 ) / P2PE QSA company:
• Describe efforts made to ensure no conflict of interest resulted from the above mentioned services provided by the P2PE Assessor / P2PE Assessor company:
Modified
p. 12
Remote key distribution using asymmetric techniques for the distribution of keys to PCI- approved POI devices for use in connection with account-data encryption.
Remote key distribution using asymmetric techniques for the distribution of keys to PCI- approved PTS POI devices for use in connection with account-data encryption.
Modified
p. 12
Yes (If Yes, ensure the additional requirements marked “RKD” in section 4 are satisfied) No (If No, only Local Key Injection is supported)
Yes (If Yes, ensure the additional requirements marked “RKD” in section 4 are satisfied) No (If No, only Local Key Injection is supported) Key Types Supported
Modified
p. 13
- 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.
- 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 …
Modified
p. 13
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 used to help satisfy requirements in scope for this assessment? Yes (If Yes, document below accordingly. Ensure all remaining applicable requirements are assessed and satisfied as they relate to the full scope of the assessment.) No (If No, leave the remainder of this table blank. Ensure all applicable requirements are assessed …
Note 2: The use of 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 used to help satisfy requirements in scope for this assessment? Yes (If Yes, document below accordingly. Ensure all remaining applicable requirements are assessed and satisfied as they relate to the full scope of the assessment.) No (If No, leave the remainder of this table blank. Ensure all applicable requirements are assessed and …
Modified
p. 15
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.
Third-party entities are entities that are not Validated 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.
Modified
p. 16
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
Identifier Type PTS and/or FIPS Approval # PTS Version # Manufacturer / Model Name / Number Hardware #(s) Firmware #(s) Location Number of Devices per Location Approved Key Function(s) & Purpose
Modified
p. 19
• Other necessary components, as applicable to the Key Management Services Provide any additional information below that is not adequately captured within the diagram(s). Otherwise, check No Additional Details. No Additional Details <Additional Details, as needed> <Insert Key Management Services diagram(s) here>
Modified
p. 20 → 19
• Locations of critical facilities
• Location of systems performing key-management functions
• Key Distribution / Loading / Injection onto POI devices • Other Key Distribution / Loading / Injection activities • Key Archiving (if applicable) • Any other relevant information
• Location of systems performing key-management functions
• Key Distribution / Loading / Injection onto POI devices • Other Key Distribution / Loading / Injection activities • Key Archiving (if applicable) • Any other relevant information
Modified
p. 23
Sample Ref #: (optional) PTS and/or FIPS Approval # Sample Size (x of y) Serial Numbers of Tested Devices / Other Identifiers Sampling Rationale
Sample Ref #: (optional) PTS and/or FIPS Approval # Hardware #(s) (comma delimited) Firmware #(s) (comma delimited) Sample Size (x of y) Serial Numbers of Tested Devices / Other Identifiers Sampling Rationale
Modified
p. 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 Applies to:
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 …
Modified
p. 26
Keys are conveyed or transmitted in a secure manner
Keys are conveyed or transmitted in a secure manner 8-1 8-2 8-3 8-4 9-1 9-2 9-3
Modified
p. 33
Requirement Document how it was determined that the requirement is Not Applicable to the P2PE Product under assessment
Reference # (optional use) Requirement Document how and why it was determined that the requirement is Not Applicable to the P2PE Product under assessment
Modified
p. 34
Documented procedures reviewed: <Report Findings Here> 1-3 All hardware security modules (HSMs) must be either:
Documented procedures examined: <Report Findings Here> 1-3 All hardware security modules (HSMs) must be either:
Modified
p. 34
• 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 FIPS 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).
• PCI approved Note 1: HSM approval listings must be current⎯HSMs must have a non-expired PCI PTS HSM approval or a non-expired FIPS 140-2 or FIPS 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).
Modified
p. 34
Note 2: PCI-approved HSMs may have their approvals restricted whereby the approval is valid only when the HSM is deployed in controlled environments or more robust (e.g., secure) environments as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy. This information is noted in the Additional Information column of approved PTS POI devices.
Modified
p. 34
Note 3: Key-injection platforms and systems must include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs. This includes SCDs used in key-injection facilities (e.g., modified PEDs). A PED used for key injection must be validated and approved to the KLD approval class.
Modified
p. 34
1-3.a For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval), and examine the list of approved devices to verify that all HSMs are either:
1-3.a For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and the list of approved devices to verify that all HSMs are either:
Modified
p. 34
• 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.
• 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 (overall), or higher. Refer to http://csrc.nist.gov.
Modified
p. 34
• Listed on the PCI SSC website, with a valid SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Refer to https://www.pcisecuritystandards.org.
• Listed on the PCI SSC website, with a valid PCI SSC reference number, as Approved PCI PTS Devices under the approval class “HSM”. Refer to https://www.pcisecuritystandards.org.
Modified
p. 35
1-4.a For all PCI-approved HSMs used, examine HSM devices and 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. 35
• The PCI PTS HSM number
• The PCI PTS approval number
Modified
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:
• 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 1.4.a match the PTS listing:
Modified
p. 35 → 36
• 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 1.4.b match the FIPS140-2 Level 3 (or higher) approval listing:
Modified
p. 36
• Maintain current documentation that describes or illustrates the architecture of the KIF, including all KIF functionality.
• Maintain current documentation that describes and/or illustrates the architecture of the KIF, including all KIF functionality.
Modified
p. 36
1-5.a Interview relevant personnel and examine documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
1-5.a Interview personnel and examine documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
Modified
p. 36
Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 1-5.b Interview 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. 36
Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here>
Modified
p. 36 → 37
• Documentation shows all key-management flows across functions and networks from the point the key is generated through to the point the key is injected into the POI.
• Documentation shows all key-management flows across functions and networks from the point the key is generated through to the point the key is injected into the PTS POI device.
Removed
p. 37
<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. 37 → 38
6-1.1 Any clear-text output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the clear text of any key component/share. Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not to the entire key.
6-1.1 Any cleartext output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the cleartext of any key component/share. Each custodian’s access to cleartext output is limited to the individual component(s)/share(s) assigned to that custodian, and not to the entire key.
Modified
p. 38
• Any key-generation process with clear-text output is performed under dual control
• Any key-generation process with cleartext output is performed under dual control
Modified
p. 38
• Any output of a clear-text component or share is overseen by only the assigned key custodian(s) for that component/share
• Any output of a cleartext component or share is overseen by only the assigned key custodian(s) for that component/share
Modified
p. 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> 6-1.1.b Observe key-generation process demonstration and interview responsible personnel to verify:
• Each custodian’s access to cleartext 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>
Modified
p. 38 → 39
• Any key-generation process with clear-text output is performed under dual control.
• Any key-generation process with cleartext output is performed under dual control.
Modified
p. 38 → 39
• Any output of clear-text component or share is overseen by only the assigned key custodian(s) for the component/share.
• Any output of cleartext component or share is overseen by only the assigned key custodian(s) for the component/share.
Modified
p. 38 → 39
• 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:
• Each custodian’s access to cleartext 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 cleartext 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. 38 → 39
<Report Findings Here> 6-1.2 There must be no point in the key-generation process where a single individual has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
<Report Findings Here> 6-1.2 There must be no point in the key-generation process where a single individual has the ability to determine, obtain, or ascertain any part of a cleartext key or all the components for a key.
Modified
p. 38 → 39
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 cleartext key or all the components for a key.
Modified
p. 38 → 39
Describe how the end-to-end process observed verified that 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:
Documented procedures examined: <Report Findings Here> Describe how the end-to-end process observed verified that there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a cleartext key or all the components for a key:
Modified
p. 38 → 39
<Report Findings Here> CA/RA 6-1.2.b Examine key-generation logs to verify that: Key-generation logs reviewed:
<Report Findings Here> 6-1.2.b Examine key-generation logs to verify that:
Removed
p. 39
<Report Findings Here> 6-1.3 Devices used for the generation of clear-text key components that are output in the clear must either be powered off when not in use or require re-authentication whenever key generation is invoked.
Modified
p. 39 → 40
• Key-generation devices that generate clear-text key components are powered off when not in use or require re-authentication whenever key generation is invoked; or
• Key-generation devices that generate cleartext key components are powered off when not in use or require re-authentication whenever key generation is invoked; or
Modified
p. 39 → 40
• If the device used for key generation is logically partitioned for concurrent use in other processes, the key-generation capabilities are enabled for execution of the procedure and disabled when the procedure is complete.
• If the device used for key generation is logically partitioned for concurrent use in other processes, the key- generation capabilities are enabled for execution of the procedure and disabled when the procedure is complete.
Modified
p. 39 → 40
<Report Findings Here> 6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear-text key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component.
<Report Findings Here> 6-1.4 Key-generation equipment used for generation of cleartext key components must not show any signs of tampering (e.g., unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a cleartext key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component.
Modified
p. 39 → 40
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 cleartext key or key component (e.g., a tapping device).
Removed
p. 40
For example, it is not permitted for the cryptographic key to be passed through the memory of a computer unless it has been specifically tasked for the sole purpose of key generation/loading. Computers that have been specifically purposed and used solely for key generation/loading are permitted for use if all other requirements can be met, including those of Requirement 5 and the controls defined in Requirement 13.
Note: See Requirement 5 and Requirement 13.
Note: See Requirement 5 and Requirement 13.
Modified
p. 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 cleartext keying material is in use. It must not be feasible to observe any cleartext keying material either directly or via camera monitoring.
Modified
p. 40 → 41
<Report Findings Here> 6-2 Multi-use/purpose computing systems must not be used for key generation where any clear-text secret key or private key, or key component thereof, appears in memory outside the tamper-protected boundary of an SCD.
<Report Findings Here> 6-2 Multi-use/purpose computing systems must not be used for key generation where any cleartext secret key or private key, or key component thereof, appears in memory outside the tamper-protected boundary of an SCD.
Modified
p. 40 → 41
This requirement excludes from its scope computers used only for administration of SCDs, or key-generation devices that do not have the ability to access cleartext cryptographic keys or components.
Modified
p. 40 → 41
Single-purpose computers with an installed SCD or a modified PED where clear keying material is injected directly from a secure port on the key-generating SCD to the target (e.g., a POI device) meet this requirement. Where the components pass through memory of the PC, Requirement 13 must be met.
Single-purpose computers with an installed SCD or a modified PED where clear keying material is injected directly from a secure port on the key-generating SCD to the target (e.g., a POI device) meet this requirement.
Removed
p. 41
• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) or
• Where clear keying material passes through memory of the PC, the PC requirements of Requirement 13 are met.
Describe how the single-purpose computers with an installed SCD verified that either:
• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device), or
• Where clear keying material passes through unprotected memory of the PC, the PC requirements of Requirement 13 are met.
<Report Findings Here> 6-3 Printed key components must be printed within blind mailers or sealed in tamper-evident and authenticable packaging immediately after printing or transcription to ensure that:
• Only approved key custodians can observe the key component.
• Tampering can be visually detected.
• Where clear keying material passes through memory of the PC, the PC requirements of Requirement 13 are met.
Describe how the single-purpose computers with an installed SCD verified that either:
• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device), or
• Where clear keying material passes through unprotected memory of the PC, the PC requirements of Requirement 13 are met.
<Report Findings Here> 6-3 Printed key components must be printed within blind mailers or sealed in tamper-evident and authenticable packaging immediately after printing or transcription to ensure that:
• Only approved key custodians can observe the key component.
• Tampering can be visually detected.
Modified
p. 41
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.
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 cleartext 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. 41
Vendor documentation reviewed for each type of key:
Vendor documentation examined for each type of key:
Modified
p. 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 cleartext secret or private key or component thereof appears in unprotected memory:
Modified
p. 41
<Report Findings Here> 6-2.c Where single-purpose computers with an installed SCD or a modified PED are used, verify that either:
<Report Findings Here> 6-2.c Where single-purpose computers with an installed SCD or a modified PED are used, examine, observe, and interview as Describe how the single-purpose computers with an installed SCD verified that clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) .
Modified
p. 41 → 42
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:
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 requirements 6.3.1 through 6.3.9.
Modified
p. 41 → 42
Note: Printed key components includes manual (handwritten) capture.
Note: This requirement includes manual (handwritten) capture.
Removed
p. 42
• Only approved key custodians can observe the key component.
• Tampering can be visually detected.
• Tampering can be visually detected.
Removed
p. 42
<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.
Describe how the blind mailers or other sealed containers used for key components observed verified that tampering can be visually detected:
• Key components are printed within blind mailers or sealed in tamper-evident and authenticable packaging (that is able to be authenticated) immediately after printing, such that no one but the authorized custodian ever has physical access to the output;
• Printers are not networked; and
• Printers used for this purpose are not used for other purposes and are used only under dual control.
Describe how processes observed for printing key components verified the criteria in the test procedure:
Describe how the blind mailers or other sealed containers used for key components observed verified that tampering can be visually detected:
• Key components are printed within blind mailers or sealed in tamper-evident and authenticable packaging (that is able to be authenticated) immediately after printing, such that no one but the authorized custodian ever has physical access to the output;
• Printers are not networked; and
• Printers used for this purpose are not used for other purposes and are used only under dual control.
Describe how processes observed for printing key components verified the criteria in the test procedure:
Modified
p. 42
<Report Findings Here> 6-3.c Observe processes for printing key components to verify that:
<Report Findings Here> 6-3.b Interview personnel and observe processes to verify the requirement is satisfied.
Modified
p. 42
<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.
<Report Findings Here> 6-3.c REMOVED 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.
Modified
p. 42
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:
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 cleartext key components:
Modified
p. 43
• Covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
• Covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room 6-3.2.a Observe all windows in the secure room to verify they are:
Modified
p. 43
• Covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
• Covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room Identify the P2PE Assessor who confirms all windows in the secure room are:
Modified
p. 43
• Covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
• Covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room <Report Findings Here> 6-3.2.b Examine configuration of window sensors to verify that the alarm mechanism is active.
Modified
p. 43
• Enforces dual-access requirements for entry into the secure room, and anti-pass-back requirements.
• Enforces dual-access (i.e., the presence of at least two individuals) requirements for entry into the secure room, and anti-pass-back requirements.
Modified
p. 44
6-3.4 Inspect CCTV configuration and examine a sample of recordings to verify that CCTV monitoring includes the ability to record events during dark periods, and verify that, if motion- activated, recording continues for at least a minute after the last pixel of activity subsides.
6-3.4 Examine the CCTV configuration and a sample of recordings to verify that CCTV monitoring includes the ability to record events during dark periods, and verify that, if motion- activated, recording continues for at least a minute after the last pixel of activity subsides.
Modified
p. 44
Identify the P2PE Assessor who confirms through observation and examination of sample recordings that a CCTV monitoring includes the ability to record events during dark periods, and verify that, if motion-activated, recording continues for at least a minute after the last pixel of activity subsides.
Identify the P2PE Assessor who confirms that CCTV monitoring includes the ability to record events during dark periods, and verify that, if motion-activated, recording continues for at least a minute after the last pixel of activity subsides.
Modified
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.
6-3.5 Examine configuration of monitoring systems and interview monitoring personnel to verify that monitoring is supported on a continuous (24/7) basis and alarms can be resolved by authorized personnel.
Modified
p. 45
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.
6-3.6.a Observe the location of the CCTV server and digital storage to verify they are located in a secure location that is separate from the secure room.
Modified
p. 45
<Report Findings Here> 6-3.6.b Inspect access-control configurations for the CCTV server/storage secure location and the key-injection secure room to identify all personnel who have access to each area. Compare access lists to verify that personnel with access to the secure room do not have access to the CCTV server/storage secure location.
<Report Findings Here> 6-3.6.b Examine access-control configurations for the CCTV server/storage secure location and the key-injection secure room to identify all personnel who have access to each area. Compare access lists to verify that personnel with access to the secure room do not have access to the CCTV server/storage secure location.
Removed
p. 46
• Any equipment that is used.
• Any equipment that is used.
• Any equipment that is used.
Modified
p. 46
6-3.7 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor:
6-3.7 Observe CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor:
Modified
p. 46
Identify the P2PE Assessor who confirms through observation and examination of sample recordings that CCTV cameras are positioned to monitor:
• Any equipment that is used Identify the P2PE Assessor who confirms through observation and examination of sample recordings that CCTV cameras are positioned to monitor:
Modified
p. 46
<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.
• Any equipment that is used <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.
Modified
p. 46
6-3.8 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.
6-3.8 Observe 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.
Modified
p. 48
• Any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation.
• Any residue that may contain cleartext keys or components is destroyed or securely deleted immediately after generation
Modified
p. 48
• Specific direction as to the method of destruction is included in the procedure.
• Specific direction as to the method of destruction is included in the procedure
Modified
p. 48
• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key.
• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key
Modified
p. 48
• Examine logs of past destructions and deletions to verify that procedures are followed.
• Examine logs of past destructions and deletions to verify that procedures are followed Documented procedures examined: <Report Findings Here>
Removed
p. 49
• The method of destruction is consistent with Requirement 24.
<Report Findings Here> Identify the P2PE Assessor who confirms that the method of destruction is consistent with Requirement 24.
<Report Findings Here> Identify the P2PE Assessor who confirms that the method of destruction is consistent with Requirement 24.
Modified
p. 49
• Any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation.
• Any residue that may contain cleartext keys or components is destroyed or securely deleted immediately after generation
Modified
p. 49
If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key.
• The method of destruction is consistent with Requirement 24 If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key.
Modified
p. 49
Describe how the destruction process of the identified key residue observed verified that any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation:
Describe how the destruction process of the identified key residue observed verified that any residue that may contain cleartext keys or components is destroyed or securely deleted immediately after generation:
Modified
p. 49
<Report Findings Here> If a key is generated in a separate device before being exported into the end-use device, describe how the destruction process of the identified key residue observed verified that the key and all related critical security parameters are deleted from the generation and/or injection device immediately after the transfer to the device that will use the key:
<Report Findings Here> Identify the P2PE Assessor who confirms that the method of destruction is consistent with Requirement 24 <Report Findings Here> If a key is generated in a separate device before being exported into the end-use device, describe how the destruction process of the identified key residue observed verified that the key and all related critical security parameters are deleted from the generation and/or injection device immediately after the transfer to the device that will use the key:
Modified
p. 49
• If generated externally, the key pair and all related critical security parameters are deleted (zeroized) immediately after the transfer to the device that will use the key pair.
• If generated externally, the key pair and all related critical security parameters are deleted (zeroized) immediately after the transfer to the device that will use the key pair Documented procedures for asymmetric-key generation examined:
Modified
p. 49
• If generated externally, the key pair and all related critical security parameters are deleted (e.g., zeroized) immediately after the transfer to the device that will use the key pair.
• If generated externally, the key pair and all related critical security parameters are deleted (e.g., zeroized) immediately after the transfer to the device that will use the key pair Describe how the key-generation processes observed verified that asymmetric-key pairs are either:
Modified
p. 49
• If generated externally, the key pair and all related critical security parameters are deleted immediately after the transfer to the device that will use the key pair.
• If generated externally, the key pair and all related critical security parameters are deleted immediately after the transfer to the device that will use the key pair <Report Findings Here>
Modified
p. 50
• Faxing, e-mailing, or otherwise electronically conveying clear-text private or secret keys or components
• Faxing, e-mailing, or otherwise electronically conveying cleartext private or secret keys or components
Modified
p. 50
• Conveying clear-text private key shares or secret key components/shares without containing them within tamper- evident and authenticable packaging
• Conveying cleartext private key shares or secret key components/shares without containing them within tamper- evident and authenticable packaging
Modified
p. 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 cleartext private or secret keys or their components/shares across insecure channels, including but not limited to:
Modified
p. 50
• Faxing, e-mailing, or otherwise electronically conveying clear-text keys or components
• Faxing, e-mailing, or otherwise electronically conveying cleartext keys or components
Modified
p. 50
• Conveying clear-text private key shares or secret key components/shares without containing them within tamper-evident and authenticable packaging
• Conveying cleartext private key shares or secret key components/shares without containing them within tamper-evident and authenticable packaging
Modified
p. 51
• Faxing, e-mailing, or otherwise electronically conveying clear-text keys or components
• Faxing, e-mailing, or otherwise electronically conveying cleartext keys or components
Modified
p. 51
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
• Conveying cleartext private or secret key components without containing them within tamper-evident, authenticable packaging
Modified
p. 51
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
• Conveying cleartext private or secret key components without containing them within tamper-evident, authenticable packaging
Modified
p. 51
• Faxing, e-mailing, or otherwise conveying clear-text keys or components
• Faxing, e-mailing, or otherwise conveying cleartext keys or components
Removed
p. 53
• Where key components are transmitted in clear text using pre-numbered, tamper-evident, authenticable mailers:
• Details of the serial number of the package are conveyed separately from the package itself.
• Documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material.
Identify the P2PE Assessor who determined whether keys are transmitted encrypted, or as clear-text components, or within an SCD:
• Details of the serial number of the package are conveyed separately from the package itself.
• Documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material.
Identify the P2PE Assessor who determined whether keys are transmitted encrypted, or as clear-text components, or within an SCD:
Modified
p. 53
• Clear-text key components/shares must be conveyed in SCDs or using tamper-evident, authenticable packaging.
• Cleartext key components/shares must be conveyed in SCDs or using tamper-evident, authenticable packaging
Modified
p. 53
• Components/shares must be conveyed using at least two separate communication channels, such as different courier services. Components/shares sufficient to form the key must not be conveyed using the same communication channel.
• If key components are transmitted in clear text using pre-numbered, tamper-evident, authenticable mailers: o Components/shares must be conveyed using at least two separate communication channels, such as different courier services o Components/shares sufficient to form the key must not be conveyed using the same communication channel o Details of the serial number of the package are conveyed separately from the package itself o Documented procedures exist and are followed to require that the serial numbers be verified prior to …
Modified
p. 53
• Where SCDs are used for conveying components/shares, the mechanisms or data (e.g., PIN) to obtain the key component/share from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
• If SCDs are used for conveying components/shares, the mechanisms or data (e.g., PIN) to obtain the key component/share from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering
Modified
p. 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. 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 …
• If 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. 53
Describe how keys are transmitted, i.e., encrypted, or as cleartext components, and/or within an SCD:
Removed
p. 54
• Examine documented procedures for sending components in tamper-evident, authenticable packaging to verify that: - They define how the details of the package serial number are to be transmitted. - There is a requirement that the package serial number is to be sent separately from the package itself. - Each component is to be sent to/from only the custodian(s) authorized for the component. - At least two communication channels are used to send the components of a given key (not just separation by sending on different days). - Prior to the use of the components, the serial numbers are to be confirmed.
• Confirm through observation, interview, and inspection of the records of past key transfers that the process used to transport clear-text key components using pre-numbered, tamper-evident, authenticable packaging, is sufficient to ensure: - The package serial number was transmitted as prescribed. - The details of the serial number of …
• Confirm through observation, interview, and inspection of the records of past key transfers that the process used to transport clear-text key components using pre-numbered, tamper-evident, authenticable packaging, is sufficient to ensure: - The package serial number was transmitted as prescribed. - The details of the serial number of …
Modified
p. 54
<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:
<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how the observed method to convey cleartext 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. 55
• Examine documented procedures to verify that the mechanism to obtain the keying material (e.g., PIN) is conveyed using a separate communication channel from the associated SCD.
• Examine documented procedures to verify that the mechanism to obtain the keying material (e.g., PIN) is conveyed using a separate communication channel from the associated SCD
Modified
p. 55
• Examine documented procedures to verify that each SCD is inspected to ensure that there are not any signs of tampering.
• Examine documented procedures to verify that each SCD is inspected to ensure that there are not any signs of tampering
Modified
p. 55
• Examine the chain-of-custody document for the SCDs and any transport logs to ensure the movement of each device is tracked and that there is evidence that the SCDs and dual-control mechanisms were separated sufficiently to ensure that no one person gained access to the SCDs and both SCD enablers.
• Examine the chain-of-custody document for the SCDs and any transport logs to ensure the movement of each device is tracked and that there is evidence that the SCDs and dual-control mechanisms were separated sufficiently to ensure that no one person gained access to the SCDs and both SCD enablers Documented procedures examined:
Modified
p. 55
<Report Findings Here> 8-1.d Where an SCD is conveyed with pre-loaded secret and/or private keys, perform the following:
<Report Findings Here> 8-1.d If an SCD is conveyed with pre-loaded secret and/or private keys, perform the following:
Modified
p. 55
• Examine the documented procedures to ensure the method of shipment of the SCD and dual-control mechanisms (e.g., smart cards or passphrases) are separated in a way that ensures there is no opportunity for one person to gain access to the SCD and both authorization mechanisms (e.g., both smartcards, etc.).
• Examine the documented procedures to ensure the method of shipment of the SCD and dual-control mechanisms (e.g., smart cards or passphrases) are separated in a way that ensures there is no opportunity for one person to gain access to the SCD and both authorization mechanisms (e.g., both smartcards, etc.)
Modified
p. 55
• Examine documented procedures to verify that the SCD is inspected to ensure there are no signs of tampering.
• Examine documented procedures to verify that the SCD is inspected to ensure there are no signs of tampering
Modified
p. 55
• Examine records of key transfers and interview responsible personnel to verify the mechanisms that make the SCD operational are conveyed using separate communication channels.
• Examine records of key transfers and interview responsible personnel to verify the mechanisms that make the SCD operational are conveyed using separate communication channels Documented procedures examined:
Modified
p. 56
Note: An m-of-n scheme is a component- or share-allocation scheme where m is the number of shares or components necessary to form the key, and n is the number of the total set of shares or components related to the key. Management of the shares or components must be sufficient to ensure that no one person can gain access to enough of the item to form the key alone E.g., in an m-of-n scheme (which must use a recognized secret-sharing …
Note: An m-of-n scheme is a component- or share-allocation scheme where m is the number of shares or components necessary to form the key, and n is the number of the total set of shares or components related to the key. Management of the shares or components must be sufficient to ensure that no one person can gain access to enough of the item to form the key alone.
Modified
p. 56
• Designation of person(s) permitted to convey/receive keys.
• Designation of person(s) permitted to convey/receive keys
Modified
p. 56
• Reminder that any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component or shares sufficient to form the necessary threshold to derive the key.
• Reminder that any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component or shares sufficient to form the necessary threshold to derive the key
Modified
p. 56
• Steps to ensure any person with access to the media conveying a component/share of a key could not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key, without detection.
• Steps to ensure any person with access to the media conveying a component/share of a key could not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key, without detection Documented device-configuration procedures examined:
Modified
p. 57
• There is sufficient evidence to show that a person with access to the media conveying a key component or key share could not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key without detection Personnel interviewed: <Report Findings Here> Describe how the observed key-transfer processes verified that:
• There is sufficient evidence to show that a person with access to the media conveying a key component or key share could not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key without detection Personnel interviewed: <Report Findings Here> Describe how the observed key transfer processes verified that:
Modified
p. 57
• An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
• An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying other components or shares of this key that are sufficient to form the necessary threshold to derive the key
Modified
p. 57
• Any person with access to the media conveying a key component or key share must not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
• Any person with access to the media conveying a key component or key share must not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key <Report Findings Here> 8-2.c Examine records of past key transfers to verify that the method used did not allow for any personnel to have access to components or shares …
Modified
p. 58
Other similar mechanisms, such as SMS, fax, or telephone must not be used to convey clear-text key values.
Other similar mechanisms, such as SMS, fax, or telephone must not be used to convey cleartext key values.
Modified
p. 58
8-3 Interview personnel and examine logs to verify that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components/shares.
Modified
p. 58
Personnel interviewed: <Report Findings Here> Logs reviewed: <Report Findings Here> Describe the observations that confirmed that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components:
Personnel interviewed: <Report Findings Here> Logs examined: <Report Findings Here> Describe the observations that confirmed that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components:
Modified
p. 59
<Report Findings Here> 8-4.b Validate that procedures dictate that self-signed certificates must not be used as the sole method of authentication.
<Report Findings Here> 8-4.b Examine documentation, interview personnel, and observe processes as needed to verify that self-signed certificates are not used as the sole method of authentication.
Modified
p. 60
• 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.
• 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. 60
9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear-text secret or private key component/share must at all times be either:
9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single cleartext secret or private key component/share must at all times be either:
Modified
p. 60
• Under the continuous supervision of a person with authorized access to this component,
• Under the continuous supervision of a person with authorized access to this component
Modified
p. 60
• Contained within a physically secure SCD.
• Contained within a physically secure SCD Documented procedures examined:
Removed
p. 61
• Contained within a physically secure SCD.
Modified
p. 61
• Sealed in a security container or courier mailer (including pre-numbered tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or contained within a physically secure SCD.
• Sealed in a security container or courier mailer (including pre-numbered tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or contained within a physically secure SCD Responsible personnel interviewed:
Modified
p. 61
<Report Findings Here> Describe how the key-management processes observed verified that processes are implemented to ensure that any single clear-text secret or private key component/share is at all times either:
<Report Findings Here> Describe how the key-management processes observed verified that processes are implemented to ensure that any single cleartext secret or private key component/share is at all times either:
Modified
p. 61
<Report Findings Here> 9-2 Packaging or mailers (i.e., pre-numbered, tamper-evident packaging) containing clear-text key components are examined for evidence of tampering before being opened. Any sign of package tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and replacement of:
• Contained within a physically secure SCD <Report Findings Here> 9-2 Packaging or mailers (i.e., pre-numbered, tamper-evident packaging) containing cleartext key components must be examined for evidence of tampering before being opened. Any sign of package tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and replacement of:
Modified
p. 61
• Any keys encrypted under this (combined) key 9-2.a Verify documented procedures include requirements for all packaging or mailers containing clear-text key components to be examined for evidence of tampering before being opened.
• Any keys encrypted under this (combined) key 9-2.a Examine documented procedures to verify they include requirements for all packaging or mailers containing cleartext key components to be examined for evidence of tampering before being opened.
Modified
p. 61
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.
Documented procedures examined: <Report Findings Here> 9-2.b Interview responsible personnel and observe processes to verify that all packaging or mailers containing cleartext key components are examined for evidence of tampering before being opened.
Modified
p. 61
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:
Responsible personnel interviewed: <Report Findings Here> Describe how the processes observed verified that all packaging or mailers containing cleartext key components are examined for evidence of tampering before being opened:
Modified
p. 62
• Any keys encrypted under this (combined) key Documented procedures reviewed:
• Any keys encrypted under this (combined) key Documented procedures examined:
Modified
p. 63
9-3.a Verify the existence of a list(s) of key custodians⎯and designated backup(s)⎯authorized to have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
9-3.a Examine the list(s) of key custodians⎯and designated backup(s)⎯authorized to have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
Modified
p. 63
Documentation examined: <Report Findings Here> 9-3.b Observe implemented access controls and processes to verify that only those authorized key custodians⎯and designated backup(s)⎯have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
Removed
p. 64
• Check the serial number of the tamper-evident packaging upon receipt of a component package.
Modified
p. 64
9-4.a Verify that a list(s) of key custodians authorized to perform the following activities is defined and documented:
9-4.a Examine the list(s) of key custodians authorized to perform the following activities is defined and documented:
Modified
p. 64
• Place the key component into pre-numbered tamper- evident packaging for transmittal.
• Place the key component into pre-numbered tamper- evident packaging for transmittal
Modified
p. 64
• Place the key component into pre-numbered tamper- evident packaging for transmittal.
• Place the key component into pre-numbered tamper- evident packaging for transmittal
Modified
p. 64
• Check the serial number of the tamper-evident packaging upon receipt of a component package.
• Check the serial number of the tamper-evident packaging upon receipt of a component package <Report Findings Here>
Modified
p. 64
Documented reviewed: <Report Findings Here> 9-4.b Observe implemented mechanisms and processes and examine logs to verify that only the authorized key custodians can perform the following:
• Check the serial number of the tamper-evident packaging upon receipt of a component package Documented examined: <Report Findings Here> 9-4.b Observe implemented mechanisms and processes and examine logs to verify that only the authorized key custodians can perform the following:
Modified
p. 64
• Check the serial number of the tamper-evident packaging upon receipt of a component package.
• Check the serial number of the tamper-evident packaging upon receipt of a component package Describe how the implemented mechanisms and processes observed verified that only the authorized key custodians can perform the following:
Modified
p. 64
• Place the key component into pre-numbered tamper-evident packaging for transmittal.
• Place the key component into pre-numbered tamper-evident packaging for transmittal
Removed
p. 65
• Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself.
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed:
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed:
Modified
p. 65
9-5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:
9-5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of cleartext key components and perform the following:
Modified
p. 65
• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package itself.
• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package itself
Modified
p. 65
• Examine logs to verify that procedures are followed.
• Examine logs to verify that procedures are followed Documented procedures examined: <Report Findings Here> Responsible personnel interviewed:
Modified
p. 65
<Report Findings Here> Describe how the observed method used 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> Describe how the observed method used to transport cleartext key components using tamper-evident mailers verified that details of the serial number of the package are transmitted separately from the package itself:
Removed
p. 66
9-6.a If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that:
Documented procedures reviewed: <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. 66 → 65
• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or within PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened.
• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or within PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened Documented procedures examined: <Report Findings Here>
Modified
p. 66
• The components are repackaged at receipt into separate tamper-evident and authenticable packages for storage at the receiving location.
• The components are repackaged at receipt into separate tamper-evident and authenticable packages for storage at the receiving location
Modified
p. 66
• Records reflect the receipt of the shipped bag and association with subsequent individual bags.
• Records reflect the receipt of the shipped bag and association with subsequent individual bags Personnel interviewed: <Report Findings Here> 9-6.b Examine logs to verify that procedures are followed.
Modified
p. 66
<Report Findings Here>
Removed
p. 67
Documented procedures reviewed: <Report Findings Here> 10-1.b Using the network schematic and the summary listing of cryptographic keys and through interview of personnel, identify keys that protect other keys for transmission. Consider keys manually transferred (e.g., cryptograms sent to an ESO) as well as those that are system-generated and transferred (e.g., KEK or TMK encrypting working keys).
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.
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. 67 → 66
• TDEA keys used for encrypting keys must be at least triple-length keys (have bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment.
• TDEA keys used for encrypting keys must be at least triple-length keys (have bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment
Modified
p. 67 → 66
• A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength.
• A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength
Modified
p. 67 → 66
• TDEA keys must not be used to protect AES keys.
• TDEA keys must not be used to protect AES keys
Modified
p. 67 → 66
• TDEA keys must not be used to encrypt keys greater in strength than 112 bits.
• TDEA keys must not be used to encrypt keys greater in strength than 112 bits
Modified
p. 67 → 66
• RSA keys encrypting keys greater in strength than 80 bits shall must have a bit strength of at least 112 bits.
• RSA keys encrypting keys greater in strength than 80 bits must have a bit strength of at least 112 bits 10-1.a Examine documented procedures to verify there is a requirement that all keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed, as delineated in Annex C. (except as noted for RSA keys).
Removed
p. 68
- RSA keys encrypting keys greater in strength than 80 bits have a bit strength at least 112 bits.
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.
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. 68 → 67
• 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.
• 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 …
Modified
p. 68 → 67
<Report Findings Here> 11-1 Written procedures must exist and be known to all affected parties.
<Report Findings Here> 10-2 to 10-5 Not used in P2PE 11-1 Written procedures must exist and be known to all affected parties.
Modified
p. 68 → 67
11-1.a Verify documented procedures exist for all key transmission and conveyance processing.
11-1.a Observe documented procedures exist for all key transmission and conveyance processing.
Modified
p. 68
Responsible personnel interviewed: <Report Findings Here>
Responsible personnel interviewed: <Report Findings Here> 11-2 Methods used for the conveyance or receipt of keys must be documented.
Removed
p. 69
12-1.a Using the summary of cryptographic keys, identify keys that are loaded from components and examine documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required.
Describe how the structured walk-through/demonstration verified that key-loading devices can only be accessed and used under dual control:
Describe how the structured walk-through/demonstration verified that key-loading devices can only be accessed and used under dual control:
Modified
p. 69 → 68
11-2.a Verify documented procedures include all methods used for the conveyance or receipt of keys.
11-2.a Observe documented procedures include all methods used for the conveyance or receipt of keys.
Modified
p. 69 → 68
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.
Documented procedures observed: <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. 69 → 68
Documented procedures reviewed: <Report Findings Here> 12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key.
Documented procedures examined: <Report Findings Here> 12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key.
Modified
p. 69 → 68
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.
Appropriate personnel interviewed: <Report Findings Here> 12-1.c Observe the 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. 69 → 68
Describe how the structured walk-through/demonstration verified that the number and length of the key components is consistent with information provided through verbal discussion and written documentation:
Describe how the observed key-loading processes verified that the number and length of the key components is consistent with information provided through verbal discussion and written documentation:
Modified
p. 69 → 68
<Report Findings Here> 12-1.d Verify that the process includes the entry of individual key components by the designated key custodians.
<Report Findings Here> 12-1.d Observe that the process includes the entry of individual key components by the designated key custodians.
Modified
p. 69 → 68
Describe how the structured walk-through/demonstration verified that the process includes the entry of individual key components by the designated key custodians:
Describe how observations verified that the process includes the entry of individual key components by the designated key custodians:
Modified
p. 69
Describe how observations verified that key-loading devices can only be accessed and used under dual control:
Modified
p. 71 → 70
12-3.a Identify instances where a key-loading device is used to load clear-text keys. Examine documented procedures for loading of clear-text cryptographic keys to verify that:
12-3.a Examine documented procedures for loading of cleartext cryptographic keys to verify that:
Modified
p. 71 → 70
• There is a requirement that if passwords/authentication codes or tokens are used, they be maintained separately.
• There is a requirement that if passwords/authentication codes or tokens are used, they be maintained separately Documented procedures examined:
Modified
p. 71
Documented procedures examined:
Documented records of key-loading processes examined:
Removed
p. 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 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:
Documented records of key-loading processes reviewed:
Documented records of key-loading processes reviewed:
Modified
p. 72 → 71
• Dual control is necessary to authorize the key-loading session.
• Dual control is necessary to authorize the key-loading session
Modified
p. 72 → 71
• Expected techniques are used.
• Expected techniques are used
Modified
p. 72 → 71
• Default passwords/authentications codes are reset.
• Default passwords/authentications codes are reset
Modified
p. 72 → 71
• Any passwords/authentication codes used are a minimum of five characters.
• Any passwords/authentication codes used are a minimum of five characters
Modified
p. 72 → 71
• Any passwords/authentication codes or tokens are maintained separately.
• Any passwords/authentication codes used are a minimum of five characters
Modified
p. 72 → 71
<Report Findings Here> 12-3.c Examine documented records of key-loading to verify the presence of two authorized persons during each type of key-loading activity.
• Any passwords/authentication codes or tokens are maintained separately <Report Findings Here> 12-3.c Examine documented records of key-loading to verify the presence of two authorized persons during each type of key- loading activity.
Modified
p. 72 → 71
<Report Findings Here> 12-3.d Ensure that any default dual-control mechanisms (e.g., default passwords/authentication codes
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
<Report Findings Here> 12-3.d Observe that any default dual-control mechanisms (e.g., default passwords/authentication codes
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
Modified
p. 72 → 71
Describe how default dual-control mechanisms were verified to have been disabled or changed:
Describe how the observed processes verified that default dual-control mechanisms have been disabled or changed:
Modified
p. 72 → 71
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.
Documented procedures examined: <Report Findings Here> 12-4.b 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. 73 → 72
Vendor documentation reviewed: <Report Findings Here> Identify the P2PE Assessor who corroborated how the HSM MFK is created:
Vendor documentation examined: <Report Findings Here> Identify the P2PE Assessor who corroborated how the HSM MFK is created:
Modified
p. 73 → 72
12-6.a Thorough examination of documented procedures, interviews, and observation, confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key.
12-6.a Examine documented procedures, interview personnel,, and observe processes as needed to confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key.
Modified
p. 73 → 72
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:
Documented procedures examined: <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. 73 → 72
• For AES DUKPT, using the option to derive a key-encryption key called the DUKPT Update Key so that the host can send a device a new initial key encrypted under that key. Note this also requires that a new initial key ID is also sent.
• For AES DUKPT, using the option to derive a key-encryption key called the DUKPT Update Key so that the host can send a device a new initial key encrypted under that key. Note this also requires that a new initial key ID is also sent Keys must not be reloaded by any methodology in the event of a compromised device and must be withdrawn from use.
Modified
p. 73 → 72
Documented procedures reviewed: <Report Findings Here>
Documented procedures examined: <Report Findings Here>
Modified
p. 74 → 73
• Use public and private key lengths that are in accordance with Annex C for the algorithm in question.
• Use public and private key lengths that are in accordance with Annex C for the algorithm in question
Modified
p. 74 → 73
• Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
• Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question
Modified
p. 74 → 73
• Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device has (or can compute) the session key, and that no entity other than the POI device specifically identified can possibly compute the session key.
• Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device has (or can compute) the session key, and that no entity other than the POI device specifically identified can possibly compute the session key 12-8.a For techniques involving public-key cryptography, examine documentation to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication …
Modified
p. 74 → 73
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:
Documented procedures examined: <Report Findings Here> 12-8.b If key-establishment protocols using public-key cryptography are used to remotely distribute secret keys, examine documented procedures, interview personnel, and observe processes as needed to verify that the applicable requirements detailed in this Domain are met, including:
Modified
p. 75 → 74
• Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to key injection such that the badge-access system enforces the presence of at least two authorized individuals at all times in the room so no one person can singly access the key-loading equipment. Access is restricted to only appropriate personnel involved in the key-loading process.
• Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to key injection such that the badge-access system enforces the presence of at least two authorized individuals at all times in the room so no one person can singly access the key-loading equipment. Access is restricted to only appropriate personnel involved in the key-loading process
Modified
p. 75 → 74
Documented key-injection procedures reviewed:
Documented key-injection procedures examined:
Modified
p. 75 → 74
<Report Findings Here> 12-9.b Interview responsible personnel and observe key- loading processes and controls to verify that dual control and split-knowledge controls are in place for the loading of keys into devices.
<Report Findings Here> 12-9.b Interview responsible personnel and observe key-loading processes and controls to verify that dual control and split- knowledge controls are in place for the loading of keys into devices.
Modified
p. 75 → 74
Records of key-loading processes and controls reviewed:
Records of key-loading processes and controls examined:
Removed
p. 76
13-1.a Observe key-loading environments, processes, and mechanisms (e.g., terminals, PIN pads, key guns, etc.) used to transfer keys and key components. Perform the following:
- The SCD is inspected to ensure it has not been subject to any prior tampering or unauthorized modification, which could lead to the disclosure of clear-text keying material.
- The SCD is inspected to ensure it has not been subject to any prior tampering or unauthorized modification, which could lead to the disclosure of clear-text keying material.
Modified
p. 76 → 75
• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of clear-text key components.
• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of cleartext key components
Modified
p. 76 → 75
• There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys.
• There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys
Modified
p. 76 → 75
• The sending and receiving SCDs must be inspected prior to key loading to ensure that they have not been subject to any prior tampering or unauthorized modification that could lead to the disclosure of clear-text keying material.
• The sending and receiving SCDs must be inspected prior to key loading to ensure that they have not been subject to any prior tampering or unauthorized modification that could lead to the disclosure of cleartext keying material.
Modified
p. 76 → 75
• SCDs must be inspected to detect evidence of monitoring and to ensure dual control procedures are not circumvented during key loading.
• SCDs must be inspected to detect evidence of monitoring and to ensure dual control procedures are not circumvented during key loading
Modified
p. 76 → 75
• An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are uniquely identified by the device.
• An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are uniquely identified by the device 13-1 Observe key-loading environments, processes, and mechanisms (e.g., terminals, PIN pads, key guns, etc.) used to transfer keys and key components. Perform the following:
Modified
p. 76 → 75
• Ensure cameras are positioned to ensure they cannot monitor the entering of clear-text key components.
• Observe cameras are positioned to ensure they cannot monitor the entering of cleartext key components
Modified
p. 76 → 75
• 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. - …
• 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. 76 → 75
• SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.
• SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading
Modified
p. 76 → 75
• An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device.
• An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device
Modified
p. 76 → 75
• There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys.
• There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys
Modified
p. 76 → 75
• The SCD is inspected to ensure it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying material.
• The SCD is inspected to ensure it has not been subject to any prior tampering that could lead to the disclosure of cleartext keying material <Report Findings Here>
Modified
p. 77 → 76
Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. If a PED that has been modified to perform these functions has not been validated and approved to the KLD approval class, they must be managed in accordance with Requirement 13-9.
Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. A PED that has been modified to perform these functions must be validated and approved to the KLD approval class.
Modified
p. 77 → 76
13-2.a Examine documentation to verify that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. For example, computer keyboards or keyboards attached to an HSM must never be used for the loading of clear-text secret or private keys or their components.
13-2.a Examine documentation to verify that only SCDs are used in the loading of cleartext secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. For example, computer keyboards or keyboards attached to an HSM must never be used for the loading of cleartext secret or private keys or their components.
Modified
p. 77 → 76
<Report Findings Here> 13-2.b Observe a demonstration of key loading to verify that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility.
<Report Findings Here> 13-2.b Observe a demonstration of key loading to verify that only SCDs are used in the loading of cleartext secret or private keys or their components outside of a secure key-loading facility.
Modified
p. 77 → 76
Describe how the observed demonstration verified that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility.
Describe how the observed demonstration verified that only SCDs are used in the loading of cleartext secret or private keys or their components outside of a secure key-loading facility.
Modified
p. 78 → 77
• All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement 24.
• All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement 24 13-3.a Examine documented procedures for the loading of secret or private key components from electronic medium to a cryptographic device. Verify that procedures define specific instructions to be followed as a result of key injection, including:
Modified
p. 78 → 77
• Instructions to erase or otherwise destroy all traces of the component from the electronic medium, including the method to use.
• Instructions to erase or otherwise destroy all traces of the component from the electronic medium, including the method to use Documented procedures examined:
Modified
p. 78 → 77
• All traces of the component are erased or otherwise destroyed from the electronic medium.
• All traces of the component are erased or otherwise destroyed from the electronic medium Describe how the observed key-loading processes verified that the injection process results in one of the following:
Modified
p. 78 → 77
• All traces of the component are erased or otherwise destroyed from the electronic medium.
• All traces of the component are erased or otherwise destroyed from the electronic medium <Report Findings Here> 13-3.c Examine records/logs of erasures to confirm that:
Modified
p. 79 → 78
13-4.1 Verify the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
13-4.1 Examine documented procedures, interview personnel, and observe processes as needed to verify the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
Modified
p. 79 → 78
13-4.2 Verify the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it.
13-4.2 Examine documented procedures, interview personnel, and observe processes as needed to verify the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it.
Modified
p. 80 → 79
13-4.3.a Verify the key-loading device is designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD.
13-4.3.a Examine documented procedures, interview personnel, and observe processes as needed to verify the key-loading device is designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD.
Modified
p. 80 → 79
<Report Findings Here> 13-4.3.b Verify that both authorized personnel involved in key- loading activity inspect the key-loading device prior to use to ensure that a key-recording device has not been inserted between the SCDs.
<Report Findings Here> 13-4.3.b Examine documented procedures, interview personnel, and observe processes as needed to verify that both authorized personnel involved in key-loading activity inspect the key- loading device prior to use to ensure that a key-recording device has not been inserted between the SCDs.
Modified
p. 80 → 79
13-4.4 Verify the key-loading device does not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred. For example, attempt to output the same value more than one time from the device or cause the device to display check values for its contents both before and after injection and compare.
13-4.4 Examine documented procedures, interview personnel, and observe processes as needed to verify the key-loading device does not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred. For example, attempt to output the same value more than one time from the device or cause the device to display check values for its contents both before and after injection and compare.
Modified
p. 81 → 80
• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process.
• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process Documented procedures examined:
Modified
p. 82 → 81
13-6 Validate through interview and observation that if components are in human-readable form, they are visible only to designated component custodians and only for the duration of time required for this person to privately enter the key component into an SCD.
13-6 If components are in human-readable form, examine documented procedures, interview personnel, and observe processes as needed to verify that they are visible only to designated component custodians and only for the duration of time required for this person to privately enter the key component into an SCD.
Removed
p. 83
<Report Findings Here> 13-9 Key-injection facilities that use PC-based key-loading software platforms or similar devices (e.g., modified PEDs) that allow clear-text secret and/or private keys and/or their components to exist in memory outside the secure boundary of an SCD must minimally implement the following additional controls:
Note: Effective 1 January 2021, entities engaged in key loading on behalf of others must not be allowed to use PC based key-loading methodologies where clear-text secret and/or private keying material appears in the clear in memory outside the secure boundary of an SCD.
Effective 1 January 2023, entities only performing key loading for devices for which they are the processor shall no longer have this option.
13-9 Interview appropriate personnel and examine documentation to determine the procedures for key loading to POIs, key-loading devices, and HSMs that are part of the key- loading platform. Examine any logs of key loading.
<Report Findings Here> Documented procedures reviewed:
<Report Findings …
Note: Effective 1 January 2021, entities engaged in key loading on behalf of others must not be allowed to use PC based key-loading methodologies where clear-text secret and/or private keying material appears in the clear in memory outside the secure boundary of an SCD.
Effective 1 January 2023, entities only performing key loading for devices for which they are the processor shall no longer have this option.
13-9 Interview appropriate personnel and examine documentation to determine the procedures for key loading to POIs, key-loading devices, and HSMs that are part of the key- loading platform. Examine any logs of key loading.
<Report Findings Here> Documented procedures reviewed:
<Report Findings …
Removed
p. 84
13-9.2 Verify through interviews and observation that:
• All hardware used in key loading (including the PC) is managed under dual control.
• All hardware used in key loading (including the PC) is managed under dual control.
• Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process. Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals.
Personnel interviewed: <Report Findings Here> Describe how observation of the facilities verified that:
• Key-injection cannot occur unless there are minimally two individuals in the key- injection room at all times during the process.
• Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals <Report Findings Here>
• All hardware used in key loading (including the PC) is managed under dual control.
• All hardware used in key loading (including the PC) is managed under dual control.
• Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process. Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals.
Personnel interviewed: <Report Findings Here> Describe how observation of the facilities verified that:
• Key-injection cannot occur unless there are minimally two individuals in the key- injection room at all times during the process.
• Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals <Report Findings Here>
Removed
p. 85
• Logs of access to the room from a badge-access system;
• Logs of access to the room from a manual sign-in sheet;
• User sign-on logs on the PC at the operating-system level;
• User sign-on logs on the PC at the application level;
• Logs of the device IDs and serial numbers that are loaded, along with the date and time and the individuals performing the key-injection;
• Video surveillance logs with a minimum retention period of 45 days.
13-9.3.a Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
• 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.
Personnel interviewed: <Report Findings Here> Logs of key-loading activities reviewed:
Personnel interviewed: <Report Findings Here> Logs of key-loading activities reviewed:
<Report Findings Here> 13-9.3.b Verify through interviews and observation that logs of …
• Logs of access to the room from a manual sign-in sheet;
• User sign-on logs on the PC at the operating-system level;
• User sign-on logs on the PC at the application level;
• Logs of the device IDs and serial numbers that are loaded, along with the date and time and the individuals performing the key-injection;
• Video surveillance logs with a minimum retention period of 45 days.
13-9.3.a Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
• 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.
Personnel interviewed: <Report Findings Here> Logs of key-loading activities reviewed:
Personnel interviewed: <Report Findings Here> Logs of key-loading activities reviewed:
<Report Findings Here> 13-9.3.b Verify through interviews and observation that logs of …
Removed
p. 86
13-9.4 Verify through interviews and observation that: Personnel interviewed for 13.9.4.x:
<Report Findings Here> 13-9.4.1 Cable attachments and the key-loading device must be examined before each use to ensure the equipment is free from tampering.
13-9.4.1 Cable attachments and the key-loading device are examined before each use to ensure the equipment is free from tampering.
Describe how it was verified that cable attachments and the key-loading device are examined before each use to ensure the equipment is free from tampering:
<Report Findings Here> 13-9.4.2 The key-loading device must be started from a powered-off position every time key-loading activities occur.
13-9.4.2 The key-loading device is started from a powered-off position every time key-loading activities occur.
Describe how it was verified that the key-loading device is started from a powered-off position every time key-loading activities occur:
<Report Findings Here> 13-9.4.3 The software application must load keys without recording any clear-text values on portable media or other unsecured devices.
13-9.4.3 The …
<Report Findings Here> 13-9.4.1 Cable attachments and the key-loading device must be examined before each use to ensure the equipment is free from tampering.
13-9.4.1 Cable attachments and the key-loading device are examined before each use to ensure the equipment is free from tampering.
Describe how it was verified that cable attachments and the key-loading device are examined before each use to ensure the equipment is free from tampering:
<Report Findings Here> 13-9.4.2 The key-loading device must be started from a powered-off position every time key-loading activities occur.
13-9.4.2 The key-loading device is started from a powered-off position every time key-loading activities occur.
Describe how it was verified that the key-loading device is started from a powered-off position every time key-loading activities occur:
<Report Findings Here> 13-9.4.3 The software application must load keys without recording any clear-text values on portable media or other unsecured devices.
13-9.4.3 The …
Removed
p. 87
13-9.4.5 Personnel responsible for the systems administration of the PC do not have authorized access into the room
•i.e., they are escorted by authorized key-injection personnel
•and do not have user IDs or passwords/authentication codes to operate the key-injection application.
Describe how it was verified that personnel responsible for the systems administration of the PC do not have authorized access into the room and do not have user IDs or passwords to operate the key-injection application:
<Report Findings Here> 13-9.4.6 The key-injection personnel must not have system-administration capability at either the O/S or the application level on the PC.
13-9.4.6 Key-injection personnel do not have system- administration capability at either the O/S or the application level on the PC.
Describe how it was verified that key-injection personnel do not have system- administration capability at either the O/S or the application level on the PC:
<Report Findings Here> 13-9.4.7 The PC must not be able to boot from …
•i.e., they are escorted by authorized key-injection personnel
•and do not have user IDs or passwords/authentication codes to operate the key-injection application.
Describe how it was verified that personnel responsible for the systems administration of the PC do not have authorized access into the room and do not have user IDs or passwords to operate the key-injection application:
<Report Findings Here> 13-9.4.6 The key-injection personnel must not have system-administration capability at either the O/S or the application level on the PC.
13-9.4.6 Key-injection personnel do not have system- administration capability at either the O/S or the application level on the PC.
Describe how it was verified that key-injection personnel do not have system- administration capability at either the O/S or the application level on the PC:
<Report Findings Here> 13-9.4.7 The PC must not be able to boot from …
Removed
p. 88
Note: For DUKPT implementations, the BDK must be loaded from components each time and this requires manual tracking of the device ID counter and serial numbers from the previous key-loading session. Key-injection facilities with PC applications that require passwords/authentication codes to be used to initiate decryption of keys on portable electronic media (e.g., smart cards) must ensure the passwords/authentication codes are maintained under dual control and split knowledge.
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.
Describe how it was verified that if the PC application reads or stores keys from portable electronic media:
• The media is secured as components under dual control …
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.
Describe how it was verified that if the PC application reads or stores keys from portable electronic media:
• The media is secured as components under dual control …
Modified
p. 89 → 82
Note: Where key-loading is performed for POI devices, the secure environment as defined in Requirement 32-9 must additionally be met.
Note: Where key-loading is performed for PTS POI devices, the secure environment as defined in Requirement 32-9 must additionally be met.
Modified
p. 89 → 82
• Any hardware used in the key-loading function or for the signing of authenticated applications must be controlled and maintained in a secure environment under dual control.
• Any hardware used in the key-loading function must be controlled and maintained in a secure environment under dual control
Modified
p. 89 → 82
• Any resources (e.g., passwords/authentication codes and associated hardware) used in the key-loading function or for the signing of authenticated applications must be controlled and managed such that no single individual has the capability to enable key loading of clear-text keys or their components.
• Any resources (e.g., passwords/authentication codes and associated hardware) used in the key-loading function must be controlled and managed such that no single individual has the capability to enable key loading of cleartext keys or their components Documented procedures examined:
Modified
p. 89 → 82
• All hardware used in the key-loading function or for the signing of authenticated applications is controlled and maintained in a secure environment under dual control.
• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control
Modified
p. 89 → 82
• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions and for the signing of authenticated applications are controlled and managed such that no single individual has the capability to enable key loading.
• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading Describe the observation of key-loading environments and controls and how they verified that:
Modified
p. 89 → 82
• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control.
• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control
Modified
p. 89 → 82
• All resources (e.g., passwords and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading.
• All resources (e.g., passwords and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading <Report Findings Here>
Modified
p. 90 → 83
14-2.a Examine documented procedures to ensure they require that cable attachments are examined at the beginning of an entity’s key-activity operations (system power on/authorization) or application signing operations.
14-2.a Examine documented procedures to ensure they require that cable attachments are examined at the beginning of an entity’s key-activity operations (system power on/authorization).
Modified
p. 90 → 83
<Report Findings Here> 14-2.b Observe key-loading processes to verify that all cable attachments are properly examined at the beginning of an entity’s key-activity operations (system power on/authorization) or application-signing operations.
<Report Findings Here> 14-2.b Observe key-loading processes to verify that all cable attachments are properly examined at the beginning of an entity’s key-activity operations (system power on/authorization).
Modified
p. 90 → 83
<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.
<Report Findings Here> 14-3 Key-loading equipment usage must be monitored, and a log of all key-loading activities maintained for audit purposes must contain, at a minimum, date, time, personnel involved, and number of devices keys are loaded to.
Modified
p. 90 → 83
14-3.a Observe key-loading and application-signing activities to verify that key-loading equipment usage is monitored.
14-3.a Observe key-loading activities to verify that key-loading equipment usage is monitored.
Modified
p. 90 → 83
<Report Findings Here> 14-3.b Verify logs of all key-loading and application-signing activities are maintained and contain all required information.
<Report Findings Here> 14-3.b Examine logs of all key-loading activities and verify that they are maintained and contain all required information.
Modified
p. 90 → 83
Logs of key-loading activities reviewed:
Logs of key-loading activities examined:
Removed
p. 91
<Report Findings Here> 14-4.b Inspect locations and controls for physical tokens to verify that tokens used to enable key loading or the signing of authenticated applications are not in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.
Access-control logs reviewed: <Report Findings Here>
Access-control logs reviewed: <Report Findings Here>
Modified
p. 91 → 83
14-4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key loading or the signing of authenticated applications. Verify procedures require that physical tokens must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.
14-4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key loading . Verify procedures require that physical tokens must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.
Modified
p. 91 → 84
<Report Findings Here> 14-4.d Verify that access-control logs exist and are in use including notation of tamper-evident, authenticable bag numbers.
<Report Findings Here> 14-4.d Examine access-control logs exist and are in use including notation of tamper-evident, authenticable bag numbers.
Removed
p. 92
<Report Findings Here> 14-5.b Verify that documented procedures exist to require that these passwords/authentication codes be changed when assigned personnel change.
Modified
p. 92 → 84
14-5.a Verify that documented procedures require default passwords/authentication codes used to enforce dual-control mechanisms are changed.
14-5.a Examine documented procedures to verify they require default passwords/authentication codes used to enforce dual- control mechanisms are changed.
Modified
p. 92 → 85
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 shall 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 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 shall 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 …
Modified
p. 93 → 86
Documented procedures reviewed: <Report Findings Here> 15-1.b Observe the key-loading processes to verify that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians.
Documented procedures examined: <Report Findings Here> 15-1.b Observe the key-loading processes to verify that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians.
Modified
p. 93 → 86
<Report Findings Here> 15-1.c Verify that the methods used for key validation are consistent with ISO 11568•e.g., when check values are used, they are in accordance with this requirement.
<Report Findings Here> 15-1.c Examine the methods used for key validation to verify they are consistent with ISO 11568•e.g., when check values are used, they are in accordance with this requirement.
Modified
p. 94 → 86
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.
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 15-2.a Interview personnel and review documented procedures to verify that all public keys exist only in an approved form.
Modified
p. 94 → 86
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.
Personnel interviewed: <Report Findings Here> Documented procedures examined: <Report Findings Here> 15-2.b Observe public-key stores and mechanisms to verify that public keys exist only in an approved form.
Modified
p. 94 → 87
• POI devices must validate authentication credentials of KDHs prior to any key transport, exchange, or establishment with that device.
• POI devices must validate authentication credentials of KDHs prior to any key transport, exchange, or establishment with that device
Modified
p. 94 → 87
• KDHs must validate authentication credentials of POIs prior to any key transport, exchange, or establishment with that device.
• KDHs must validate authentication credentials of POIs prior to any key transport, exchange, or establishment with that device Documented procedures examined:
Removed
p. 95
<Report Findings Here> 15-4 Key-establishment and distribution procedures must be designed such that:
System and process documentation reviewed:
System and process documentation reviewed:
Modified
p. 95 → 87
• POI devices validate authentication credentials of KDHs immediately prior to any key transport, exchange, or establishment with that device.
• POI devices validate authentication credentials of KDHs immediately prior to any key transport, exchange, or establishment with that device
Modified
p. 95 → 87
• KDHs validate authentication credentials of POIs immediately prior to any key transport, exchange, or establishment with that device.
• KDHs validate authentication credentials of POIs immediately prior to any key transport, exchange, or establishment with that device Applicable personnel interviewed:
Modified
p. 95 → 88
• Within an implementation design, there must be no means available for “man-in-the-middle” attacks
•e.g., through binding of the KDH certificate upon the initialcommunication.
•e.g., through binding of the KDH certificate upon the initial
• Within an implementation design, there must be no means available for “man-in-the-middle” attacks
•e.g., through binding of the KDH certificate upon the initial communication
•e.g., through binding of the KDH certificate upon the initial communication
Modified
p. 95 → 88
• System implementations must be designed and implemented to prevent replay attacks
•e.g., through the use of random nonces and time stamps as noted in ANSITR-34.
•e.g., through the use of random nonces and time stamps as noted in ANSI
• System implementations must be designed and implemented to prevent replay attacks
•e.g., through the use of random nonces and time stamps as noted in ANSI TR-34 15-4 Examine system and process documentation to verify that key-establishment and distribution procedures are designed such that:
•e.g., through the use of random nonces and time stamps as noted in ANSI TR-34 15-4 Examine system and process documentation to verify that key-establishment and distribution procedures are designed such that:
Modified
p. 95 → 88
• There are no means available in the implementation design for “man-in-the-middle” attacks.
• There are no means available in the implementation design for “man-in-the-middle” attacks
Modified
p. 95 → 88
• System implementations are designed to prevent replay attacks.
• System implementations are designed to prevent replay attacks System and process documentation examined:
Modified
p. 96 → 89
• Examine documented procedures to verify that controls are defined to ensure the secrecy of private keys and the integrity of public keys during key transfer and loading.
• Examine documented procedures to verify that controls are defined to ensure the secrecy of private keys and the integrity of public keys during key transfer and loading
Modified
p. 96 → 89
• Observe key transfer and loading operations to verify that the secrecy of private keys and the integrity of the public keys are ensured.
• Observe key transfer and loading operations to verify that the secrecy of private keys and the integrity of the public keys are ensured
Modified
p. 96 → 89
• Verify the process ensures that key pairs are unique per POI device.
• Observe the process to verify it ensures that key pairs are unique per PTS POI device Documented procedures examine:
Modified
p. 96 → 89
<Report Findings Here> Describe how key transfer and loading operations verified that the process ensures that key pairs are unique per POI device:
<Report Findings Here> Describe how the observed key transfer and loading operation process verified that key pairs are unique per PTS POI device:
Modified
p. 96 → 89
16-1.a Verify documented procedures exist for all key-loading operations.
16-1.a Examine documented procedures and verify they exist for all key-loading operations.
Removed
p. 98
• Compare key check values against those for known or default keys to verify that known or default key values are not used.
Modified
p. 98 → 91
• Not be given to any other entity or logically separate systems.
• Not be given to any other entity or logically separate systems
Modified
p. 98 → 91
Documented key matrix reviewed:
Documented key matrix examined:
Modified
p. 98 → 91
• 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 …
• Observe and/or test to 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. …
Modified
p. 98 → 91
• If a remote key-establishment and distribution scheme is implemented between networks, examine public keys and/or hash values and/or fingerprints of the keys to verify key uniqueness of the asymmetric-key pairs.
• If a remote key-establishment and distribution scheme is implemented between networks, examine public keys and/or hash values and/or fingerprints of the keys to verify key uniqueness of the asymmetric-key pairs
Modified
p. 98 → 91
Describe how the generation of (or otherwise obtaining) key check values for any key- encipherment keys (KEKs), public keys, and/or hash values and/or fingerprints (where a remote key-establishment and distribution scheme is implemented) verified key uniqueness between the two organizations:
• Observe key check values against those for known or default keys to verify that known or default key values are not used Describe how the generation of (or otherwise obtaining) key check values for any key- encipherment keys (KEKs), public keys, and/or hash values and/or fingerprints (where a remote key-establishment and distribution scheme is implemented) verified key uniqueness between the two organizations:
Modified
p. 99 → 92
18-1.a Verify procedures have been implemented for monitoring and alerting to the presence of multiple cryptographic synchronization errors.
18-1.a Examine documented procedures to verify they have been implemented for monitoring and alerting to the presence of multiple cryptographic synchronization errors.
Modified
p. 99 → 92
<Report Findings Here> 18-1.b Verify that implemented procedures include:
<Report Findings Here> 18-1.b Examine and/or observe the implemented procedures include:
Modified
p. 99 → 92
• Specific actions that determine whether the legitimate value of the cryptographic key has changed. (For example, encryption of a known value to determine whether the resulting cryptogram matches the expected result.)
• Specific actions that determine whether the legitimate value of the cryptographic key has changed. (For example, encryption of a known value to determine whether the resulting cryptogram matches the expected result)
Modified
p. 99 → 92
• Proactive safeguards that shut down the source of any synchronization errors and start an investigative process to determine the true cause of the event.
• Proactive safeguards that shut down the source of any synchronization errors and start an investigative process to determine the true cause of the event Documented procedures examined:
Modified
p. 100 → 93
18-2.a Verify that documented procedures require that key- component packaging/containers showing signs of tampering indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
18-2.a Examine the documented procedures to verify they require that key-component packaging/containers showing signs of tampering indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
Modified
p. 101 → 94
• this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019 (past).
• this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019 (past)
Modified
p. 101 → 94
• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 January 2023.
• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 January 2023 (past)
Modified
p. 101 → 94
• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 January 2025.
• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 January 2025 (past) Acceptable methods of implementing the integrity requirements include, but are not limited to:
Modified
p. 101 → 94
• A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself⎯e.g. TR-31;
• A MAC computed over the concatenation of the cleartext attributes and the enciphered portion of the key block, which includes the key itself
Modified
p. 101 → 94
• A digital signature computed over that same data, e.g., TR-34;
• A digital signature computed over that same data, e.g., TR-34
Modified
p. 101 → 94
• An integrity check that is an implicit part of the key-encryption process such as that which is used in the AES key-wrap process specified in ANSI X9.102.
• An integrity check that is an implicit part of the key-encryption process such as that which is used in the AES key- wrap process specified in ANSI X9.102 18-3 Using the cryptographic-key summary to identify secret keys conveyed or stored, examine documented procedures and observe key operations to verify that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or …
Modified
p. 101 → 94
Describe how the documented procedures examined and the key operations observed verified that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or an equivalent.
Documented procedures examined: <Report Findings Here> Describe how the documented procedures examined and the key operations observed verified that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or an equivalent.
Modified
p. 102 → 95
• 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;
• PTS 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. 102 → 95
• POI devices only communicate with KDHs for key management, normal transaction processing, and certificate (entity) status checking.
• POI devices only communicate with KDHs for key management, normal transaction processing, and certificate (entity) status checking Documented procedures examined:
Modified
p. 102 → 95
<Report Findings Here> 18-4.b Interview responsible personnel and observe POI configurations to verify that:
<Report Findings Here> 18-4.b Interview responsible personnel and observe PTS POI configurations to verify that:
Modified
p. 102 → 95
• 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;
• PTS 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. 102 → 95
• POI devices only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking.
• PTS POI devices only communicate with KDHs for key management, normal transaction processing, and certificate (entity) status checking Responsible personnel interviewed:
Modified
p. 102 → 95
<Report Findings Here> Describe how the POI configurations observed verified that POIs 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:
<Report Findings Here> Describe how the PTS POI configurations observed verified that PTS 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. 102 → 95
<Report Findings Here> Describe how the POI configurations observed verified that POIs only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking:
<Report Findings Here> Describe how the PTS POI configurations observed verified that PTS POI devices only communicate with KDHs for key management, normal transaction processing, and certificate (entity) status checking:
Modified
p. 103 → 96
• KDHs only communicate with POI devices for the purpose of key management and normal transaction processing;
• KDHs only communicate with PTS POI devices for the purpose of key management and normal transaction processing
Modified
p. 103 → 96
• KDHs only to communicate with CAs for the purpose of certificate signing and certificate (entity) status checking.
• KDHs only to communicate with CAs for the purpose of certificate signing and certificate (entity) status checking Documented procedures examined:
Modified
p. 103 → 96
• KDHs only communicate with POIs for the purpose of key management and normal transaction processing;
• KDHs only communicate with POIs for the purpose of key management and normal transaction processing
Modified
p. 103 → 96
• KDHs only communicate with CAs for the purpose of certificate signing and certificate (entity) status checking.
• KDHs only communicate with CAs for the purpose of certificate signing and certificate (entity) status checking Responsible personnel interviewed:
Modified
p. 103 → 96
<Report Findings Here> Describe how the KDH configurations observed verified that KDHs only communicate with POIs for the purpose of key management and normal transaction processing:
<Report Findings Here> Describe how the KDH configurations observed verified that KDHs only communicate with PTS POI devices for the purpose of key management and normal transaction processing:
Modified
p. 103 → 96
<Report Findings Here> 18-6.b Interview responsible personnel and observe key- loading processes and controls to verify that controls
•e.g., viewing CCTV images
•are implemented to prevent and detect the loading of keys by any one single person.
•e.g.,
•are
<Report Findings Here> 18-6.b Interview responsible personnel and observe key-loading processes and controls to verify that controls, e.g., viewing CCTV images•are implemented to prevent and detect the loading of keys by any one single person.
Modified
p. 104 → 97
• All devices loaded with keys must be tracked at each key-loading session by serial number.
• All devices loaded with keys must be tracked at each key-loading session by serial number
Modified
p. 104 → 97
• Key-injection facilities must use something unique about the POI (e.g., logical identifiers) when deriving the key (e.g., DUKPT, TMK) injected into it.
• Key-injection facilities must use something unique about the POI (e.g., logical identifiers) when deriving the key (e.g., DUKPT, TMK) injected into it 18-7.a Examine documented procedures to verify they include:
Modified
p. 104 → 97
• Controls to prevent the operation of devices without legitimate keys.
• Controls to prevent the operation of devices without legitimate keys Documented procedures examined:
Modified
p. 104 → 97
<Report Findings Here> 18-7.b Interview responsible personnel and observe key- loading processes and controls to verify that:
<Report Findings Here> 18-7.b Interview responsible personnel and observe key-loading processes and controls to verify that:
Modified
p. 104 → 97
• Controls are implemented that prevent the operation of devices without legitimate keys.
• Controls are implemented that prevent the operation of devices without legitimate keys Responsible personnel interviewed:
Modified
p. 104 → 97
• Controls are implemented that prevent the operation of devices without legitimate keys.
• Controls are implemented that prevent the operation of devices without legitimate keys <Report Findings Here>
Modified
p. 105 → 98
<Report Findings Here> 19-1.b Using a sample of device types, validate via examination of check values, terminal definition files, etc. that keys used for key encipherment or PIN encipherment are not used for any other purpose.
<Report Findings Here> 19-1.b Using a sample of device types, examine/observe check values, terminal definition files, etc. to verify that keys used for key encipherment are not used for any other purpose.
Modified
p. 105 → 98
Sample of device types reviewed:
Sample of device types examined:
Modified
p. 106 → 99
• 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 POIdevices).
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI
• Must be used only for a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices)
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices)
Modified
p. 106 → 99
• Must never be used to encrypt other keys.
• Must never be used to encrypt other keys
Modified
p. 106 → 99
• When used for remote key distribution, must not be used in connection with any other purpose.
• When used for remote key distribution, must not be used in connection with any other purpose
Modified
p. 106 → 99
• Used only to create digital signatures or to perform decryption operations.
• Used only to create digital signatures or to perform decryption operations
Modified
p. 106 → 99
• Used only for a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but notboth.
•a private key must only be used for either decryption or for creating digital signatures, but not
• Used only for a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both
•a private key must only be used for either decryption or for creating digital signatures, but not both
Modified
p. 106 → 99
• Never used to encrypt other keys.
• Never used to encrypt other keys
Modified
p. 106 → 99
• Not used in connection with any other purpose when used for remote key distribution.
• Not used in connection with any other purpose when used for remote key distribution Key-management documentation examined:
Modified
p. 106 → 99
• To perform encryption operations or to verify digital signatures.
• To perform encryption operations or to verify digital signatures
Modified
p. 106 → 99
• For a single purpose
•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POIdevices).
•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI
• For a single purpose
•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI devices) Key-management documentation examined:
•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI devices) Key-management documentation examined:
Modified
p. 107 → 100
<Report Findings Here> 19-4.d Compare check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.
<Report Findings Here> 19-4.d Examine/observe check, hash, cryptogram, or fingerprint values for production and test/development keys with higher- level keys (MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.
Modified
p. 108 → 101
• All keying material is deleted from the HSM(s) and the server /computer platforms prior to testing.
• All keying material is deleted from the HSM(s) and the server /computer platforms prior to testing
Modified
p. 108 → 101
• Subsequent to completion of testing, all keying materials must be deleted and the server/computer platforms must be wiped and rebuilt from read-only media.
• Subsequent to completion of testing, all keying materials must be deleted and the server/computer platforms must be wiped and rebuilt from read-only media
Modified
p. 108 → 101
• Prior to reuse for production purposes, the HSM is returned to factory state.
• Prior to reuse for production purposes, the HSM is returned to factory state
Modified
p. 108 → 101
• The relevant production keying material is restored using the principles of dual control and split knowledge as stated in these requirements.
• The relevant production keying material is restored using the principles of dual control and split knowledge as stated in these requirements Personnel interviewed: <Report Findings Here> Documented procedures examined:
Modified
p. 109 → 102
<Report Findings Here> 19-8 POI device private keys must not be shared between POI devices.
<Report Findings Here> 19-8 PTS POI device private keys must not be shared between PTS POI devices.
Modified
p. 109 → 102
<Report Findings Here> 19-8.b Inspect public key certificates on the host processing system to confirm that a unique certificate exists for each connected POI device.
<Report Findings Here> 19-8.b Examine public key certificates on the host processing system to confirm that a unique certificate exists for each connected POI device.
Modified
p. 110 → 103
• Self-signed root certificates.
• Self-signed root certificates Certificate policy and documented procedures examined:
Modified
p. 110 → 103
• Self-signed root certificates.
• Self-signed root certificates Responsible personnel interviewed:
Modified
p. 110 → 103
• Self-signed root certificates.
• Self-signed root certificates <Report Findings Here>
Modified
p. 112 → 105
• Certificates associated with encryption for remote key distribution functions must not be used for any other purpose.
• Certificates associated with encryption for remote key distribution functions must not be used for any other purpose
Modified
p. 112 → 105
• Certificates associated with authentication of the KDH must not be used for any other purpose.
• Certificates associated with authentication of the KDH must not be used for any other purpose
Modified
p. 112 → 105
• Certificates associated with authentication of the POI must not be used for any other purpose.
• Certificates associated with authentication of the POI must not be used for any other purpose
Modified
p. 112 → 105
• Certificates associated with authentication of POI firmware and POI applications must not be used for any other purpose.
• Certificates associated with authentication of POI firmware and POI applications must not be used for any other purpose If CA separation is used to ensure certificate segmentation:
Modified
p. 112 → 105
• Sub-CAs used to produce certificates used for remote key delivery functions must not be used to produce certificates used for any other purpose.
• Sub-CAs used to produce certificates used for remote key delivery functions must not be used to produce certificates used for any other purpose
Modified
p. 112 → 105
• Sub-CAs used to produce certificates for POI firmware and POI application authentication must not be used for any other purpose.
• Sub-CAs used to produce certificates for POI firmware and POI application authentication must not be used for any other purpose If policy-based certificate segmentation is used to achieve unique purpose certificates:
Modified
p. 112 → 105
• The method of segmentation between certificates must be reflected in the certificate practice statement (CPS) for the CA.
• The method of segmentation between certificates must be reflected in the certificate practice statement (CPS) for the CA
Modified
p. 112 → 105
• Certificates issued for remote key-distribution purposes must include a mechanism to identify designation for this purpose.
• Certificates issued for remote key-distribution purposes must include a mechanism to identify designation for this purpose
Modified
p. 112 → 105
• Each SCD using a certificate in a remote key-delivery function must ensure there is a designation included in the certificate indicating that it is for use in the remote key-delivery function for which it is being used.
• Each SCD using a certificate in a remote key-delivery function must ensure there is a designation included in the certificate indicating that it is for use in the remote key-delivery function for which it is being used
Modified
p. 112 → 105
• Each SCD using a certificate in a remote key-delivery function must ensure that if there is a designation included in a certificate that indicates it is for use in a remote key-delivery function, the SCD does not use it for any other purpose.
• Each SCD using a certificate in a remote key-delivery function must ensure that if there is a designation included in a certificate that indicates it is for use in a remote key-delivery function, the SCD does not use it for any other purpose 19-12.a Examine implementation schematics and other relevant documentation to identify PKI architecture and where certificates are used in the implementation.
Modified
p. 112 → 105
• Policy-based certificate segmentation that depends upon a characteristic of the certificate.
• Policy-based certificate segmentation that depends upon a characteristic of the certificate Describe the identified mechanisms used to restrict certificates to a single-purpose:
Modified
p. 113 → 106
• The designation of each Sub-CA is documented.
• The designation of each Sub-CA is documented
Modified
p. 113 → 106
• The designation of each Sub-CA is documented.
• The designation of each Sub-CA is documented
Modified
p. 113 → 106
• Policies and procedures are in place to support and require appropriate use of each Sub-CA.
• Policies and procedures are in place to support and require appropriate use of each Sub-CA
Modified
p. 113 → 106
• Policies and procedures are in place to support and require appropriate use of each Sub-CA.
• Policies and procedures are in place to support and require appropriate use of each Sub-CA
Modified
p. 113 → 106
• Any Sub-CA used to produce certificates used for remote key-delivery functions (i.e. encryption, POI authentication, or KDH authentication) is not used to produce certificates used for any other purpose.
• Any Sub-CA used to produce certificates used for remote key-delivery functions (i.e. encryption, POI authentication, or KDH authentication) is not used to produce certificates used for any other purpose
Modified
p. 113 → 106
• Any Sub-CA used to produce certificates used for remote key-delivery functions (i.e. encryption, POI authentication, or KDH authentication) is not used to produce certificates used for any other purpose.
• Any Sub-CA used to produce certificates used for remote key-delivery functions (i.e. encryption, POI authentication, or KDH authentication) is not used to produce certificates used for any other purpose
Modified
p. 113 → 106
• Any Sub-CA used to produce certificates for POI firmware and POI application authentication is not used for any other purpose.
• Any Sub-CA used to produce certificates for POI firmware and POI application authentication is not used for any other purpose <Report Findings Here>
Modified
p. 113 → 106
If CA separation is used to ensure certificate segmentation, identify the P2PE Assessor who confirms that:
• Any Sub-CA used to produce certificates for POI firmware and POI application authentication is not used for any other purpose If CA separation is used to ensure certificate segmentation, identify the P2PE Assessor who confirms that:
Modified
p. 113 → 108
• Any Sub-CA used to produce certificates for POI firmware and POI application authentication is not used for any other purpose.
• Certificates associated with authentication of the KDH are not used for any other purpose
Modified
p. 114 → 107
• The method of segmentation between certificates is clearly stated in the certificate practice statement (CPS) for the CA.
• The method of segmentation between certificates is clearly stated in the certificate practice statement (CPS) for the CA
Modified
p. 114 → 107
• The method of segmentation between certificates is clearly stated in the certificate practice statement (CPS) for the CA.
• The method of segmentation between certificates is clearly stated in the certificate practice statement (CPS) for the CA
Modified
p. 114 → 107
• 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. 114 → 107
• Policies and procedures are in place to support and require specific function designation for each certificate issued, and there is evidence that such procedures are followed.
• Policies and procedures are in place to support and require specific function designation for each certificate issued, and there is evidence that such procedures are followed
Modified
p. 114 → 107
• Policies and procedures are in place to support and require specific function designation for each certificate issued, and there is evidence that such procedures are followed.
• Policies and procedures are in place to support and require specific function designation for each certificate issued, and there is evidence that such procedures are followed
Modified
p. 114 → 107
• The SCDs involved in the remote key-delivery functions ensure that the certificates used for these functions are designated for the purpose for which they are being used.
• The SCDs involved in the remote key-delivery functions ensure that the certificates used for these functions are designated for the purpose for which they are being used
Modified
p. 114 → 107
• The SCDs involved in the remote key-delivery functions ensure that the certificates used for these functions are designated for the purpose for which they are being used.
• The SCDs involved in the remote key-delivery functions ensure that the certificates used for these functions are designated for the purpose for which they are being used
Modified
p. 114 → 107
• The SCDs involved in remote key delivery ensure that certificates with remote key-delivery designation are not used for some other purpose.
• The SCDs involved in remote key delivery ensure that certificates with remote key-delivery designation are not used for some other purpose <Report Findings Here>
Modified
p. 114 → 107
If policy-based certificate separation is used to ensure certificate segmentation, identify the P2PE Assessor who confirms that:
• The SCDs involved in remote key delivery ensure that certificates with remote key-delivery designation are not used for some other purpose If policy-based certificate separation is used to ensure certificate segmentation, identify the P2PE Assessor who confirms that:
Modified
p. 114 → 107
• 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. 114 → 108
• The SCDs involved in remote key delivery ensure that certificates with remote key-delivery designation are not used for some other purpose.
• Certificates associated with encryption for remote key-distribution functions are not used for any other purpose
Removed
p. 115
• Certificates associated with encryption for remote key-distribution functions are not used for any other purpose.
• Certificates associated with authentication of the KDH are not used for any other purpose.
• Certificates associated with authentication of the POI are not used for any other purpose.
<Report Findings Here> 20-1 POI devices must each implement unique secret and private keys for any function directly or indirectly related to account-data protection. These keys must be known only in that device and in hardware security modules (HSMs) at the minimum number of facilities consistent with effective system operations.
• Certificates associated with authentication of the KDH are not used for any other purpose.
• Certificates associated with authentication of the POI are not used for any other purpose.
<Report Findings Here> 20-1 POI devices must each implement unique secret and private keys for any function directly or indirectly related to account-data protection. These keys must be known only in that device and in hardware security modules (HSMs) at the minimum number of facilities consistent with effective system operations.
Modified
p. 115 → 108
• Certificates associated with encryption for remote key- distribution functions are not used for any other purpose.
• Certificates associated with encryption for remote key- distribution functions are not used for any other purpose
Modified
p. 115 → 108
• Certificates associated with authentication of the KDH are not used for any other purpose.
• Certificates associated with authentication of the POI are not used for any other purpose
Modified
p. 115 → 108
• Certificates associated with authentication of the POI are not used for any other purpose.
• Certificates associated with authentication of the KDH are not used for any other purpose
Modified
p. 115 → 108
• Certificates associated with authentication of POI firmware and POI applications are not used for any other purpose.
• Certificates associated with authentication of the POI are not used for any other purpose
Modified
p. 115 → 108
Describe how the mechanisms in place are effective in restricting the certificates to a single purpose use as follows:
• Certificates associated with authentication of POI firmware and POI applications are not used for any other purpose Describe how the mechanisms in place are effective in restricting the certificates to a single purpose use as follows:
Modified
p. 115 → 108
• Certificates associated with authentication of POI firmware and POI applications are not used for any other purpose.
• Certificates associated with authentication of POI firmware and POI applications are not used for any other purpose <Report Findings Here> 20-1 PTS POI devices must each implement unique secret and private keys for any function directly or indirectly related to account-data protection. These keys must be known only in that device and in hardware security modules (HSMs) at the minimum number of facilities consistent with effective system operations.
Modified
p. 115 → 108
• Known only to HSMs at the minimum number of facilities consistent with effective system operations.
• Known only to HSMs at the minimum number of facilities consistent with effective system operations Documented procedures examined:
Removed
p. 116
<Report Findings Here> 20-2 If a POI device directly interfaces with more than one entity for decryption of account data (e.g., different acquiring organizations), the POI device must have a completely different and unique key or set of keys for each acquirer. These different keys, or sets of keys, must be totally independent and not variants of one another.
20-2.a Examine documented procedures for generating all types of keys and verify procedures exist to ensure that unique keys or sets of keys are used for each acquiring organization and totally independent and are not variants of one another.
<Report Findings Here> 20-2.b Interview personnel and observe key-generation processes to verify that unique keys or sets of keys will be generated for each acquiring organization when required.
Personnel interviewed: <Report Findings Here> Describe how the key-generation processes observed verified that unique keys or sets of keys are generated for each acquiring organization:
20-2.a Examine documented procedures for generating all types of keys and verify procedures exist to ensure that unique keys or sets of keys are used for each acquiring organization and totally independent and are not variants of one another.
<Report Findings Here> 20-2.b Interview personnel and observe key-generation processes to verify that unique keys or sets of keys will be generated for each acquiring organization when required.
Personnel interviewed: <Report Findings Here> Describe how the key-generation processes observed verified that unique keys or sets of keys are generated for each acquiring organization:
Modified
p. 116 → 109
Describe how the examined check values, hash, or fingerprint values for asample of cryptographic keys from different POI devices verified that private and secret keys are unique for each POI device:
Describe how the examined check values, hash, or fingerprint values for a sample of cryptographic keys from different POI devices verified that private and secret keys are unique for each POI device:
Removed
p. 117
• Unique data is used for the derivation process such that all transaction-originating POI devices receive unique secret keys.
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device.
• Examine key-generation/injection logs to ensure that sequential values included in unique key derivation are not repeated.
Describe how the processes observed for generating master keys verified that derivation keys used to generate keys for multiple devices are never loaded into a POI device:
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device.
• Examine key-generation/injection logs to ensure that sequential values included in unique key derivation are not repeated.
Describe how the processes observed for generating master keys verified that derivation keys used to generate keys for multiple devices are never loaded into a POI device:
Modified
p. 117 → 109
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 PTS 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. 117 → 110
• Examine key-generation/injection logs to ensure that sequential values included in unique key derivation are not repeated Describe how the processes observed for generating master keys verified that the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:
Modified
p. 117 → 110
• Unique data is used for the derivation process such that all transaction-originating POI devices receive unique secret keys.
• Unique data is used for the derivation process such that all transaction-originating PTS POI devices receive unique secret keys
Modified
p. 117 → 110
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating PTS POI device
Modified
p. 117 → 110
Describe how the processes observed for generating master keys verified that derivation keys used to generate keys for multiple devices are never loaded into a PTS POI device:
Modified
p. 118 → 110
• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model
• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model Documented procedures examined:
Modified
p. 119 → 112
<Report Findings Here> Describe how the key-loading processes observed verified that separate BDKs are used for each terminal type:
<Report Findings Here> Describe how the key-loading processes observed verified that unique BDKs are used for each terminal type:
Modified
p. 119 → 112
• Keys must be uniquely identifiable in all hosts and POI Devices⎯e.g., EPPs/PEDs. Keys must be identifiable via cryptographically verifiable means⎯e.g., through the use of digital signatures or key check values.
• Keys must be uniquely identifiable in all hosts and PTS POI Devices. Keys must be identifiable via cryptographically verifiable means e.g., through the use of digital signatures or key check values.
Modified
p. 119 → 112
20-6.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including:
Modified
p. 119 → 112
• The mechanisms utilized for mutual device authentication for both the host and the POI device.
• The mechanisms utilized for mutual device authentication for both the host and the PTS POI device Documented procedures examined:
Modified
p. 119 → 112
<Report Findings Here> 20-6.b If key-establishment protocols using public-key cryptography are used to distribute secret keys, verify that:
<Report Findings Here> 20-6.b If key-establishment protocols using public-key cryptography are used to distribute secret keys, examine/observe to verify that:
Modified
p. 119 → 112
• Cryptographic mechanisms exist to uniquely identify the keys.
• Cryptographic mechanisms exist to uniquely identify the keys
Modified
p. 119 → 112
• Key pairs used by POI devices are unique per device.
• Key pairs used by PTS POI devices are unique per device Documented procedures examined:
Removed
p. 120
<Report Findings Here> 21-2.2 Construction of the cryptographic key must require the use of at least two key components/shares.
Modified
p. 120 → 113
Note: Key-injection facilities may have clear-text keying material outside of a SCD when used within a secure room in accordance with Requirement 32.
Note: Key-injection facilities may have cleartext keying material outside of a SCD when used within a secure room in accordance with Requirement 32.
Modified
p. 120 → 113
Note for hybrid decryption solutions: Clear-text Data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data.
Note for hybrid decryption solutions: Cleartext Data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data.
Modified
p. 121 → 115
Documented procedures examined:
Modified
p. 122 → 116
<Report Findings Here> 21-3.1.b Inspect any tamper-evident packaging used to secure key components
•e.g., is the package sufficiently opaque to prevent reading of a component
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
•e.g., is the package sufficiently opaque to prevent reading of a component
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
<Report Findings Here> 21-3.1.b Examine tamper-evident packaging used to secure key components
•e.g., is the package sufficiently opaque to prevent reading of a component
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
•e.g., is the package sufficiently opaque to prevent reading of a component
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
Modified
p. 122 → 116
<Report Findings Here> 21-3.1.c Ensure clear-text key components do not exist in non- secure containers, such as databases or in software programs.
<Report Findings Here> 21-3.1.c Examine/observe cleartext key components to verify they do not exist in non-secure containers, such as databases or in software programs.
Removed
p. 123
• Each secure container is accessible only by the custodian and/or designated backup(s).
Modified
p. 123 → 117
21-3.2 Inspect each key component/share storage container and verify the following:
21-3.2 Examine/observe each key component/share storage container and verify the following:
Modified
p. 123 → 117
• Key components/shares for different custodians are stored in separate secure containers.
• Key components/shares for different custodians are stored in separate secure containers
Modified
p. 123 → 117
• Each secure container is accessible only by the custodian and/or designated backup(s).
• Each secure container is accessible only by the custodian and/or designated backup(s) <Report Findings Here>
Modified
p. 123 → 117
Identify the P2PE Assessor who confirms that for each key component storage container:
• Each secure container is accessible only by the custodian and/or designated backup(s) Identify the P2PE Assessor who confirms that for each key component storage container:
Modified
p. 123 → 117
• Key components for different custodians are stored in separate secure containers.
• Key components for different custodians are stored in separate secure containers
Modified
p. 124 → 118
• 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,
• 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. 124 → 118
• As components using a recognized secret-sharing scheme (e.g., Shamir) that are at all times managed under dual control and split knowledge.
• As components using a recognized secret-sharing scheme (e.g., Shamir) that are at all times managed under dual control and split knowledge 21-4.a Examine documented key-management procedures to verify that private keys used to sign certificates, certificate- status lists, messages, or for key protection must exist only in one or more of the approved forms at all times.
Modified
p. 125 → 119
22-1 Verify documented procedures exist for replacing known or suspected compromised keys that includes all of the following (22-1.1 through 22-1.5 below):
22-1 Examine documented procedures for replacing known or suspected compromised keys to verify they include all of the following (22-1.1 through 22-1.5 below):
Modified
p. 125 → 119
<Report Findings Here> Describe how the implemented processes observed verified that key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised:
<Report Findings Here> Identify the P2PE Assessor who confirms that key components/shares are never reloaded when there is a suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised.
Modified
p. 126 → 120
• Processing with that key is halted, and the key is replaced with a new unique key.
• Processing with that key is halted, and the key is replaced with a new unique key
Modified
p. 126 → 120
• Processing with that key is halted, and the key is replaced with a new unique key.
• Processing with that key is halted, and the key is replaced with a new unique key
Modified
p. 126 → 120
• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key-replacement process.
• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key-replacement process
Modified
p. 126 → 120
• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key-replacement process.
• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key-replacement process
Modified
p. 126 → 120
• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key.
• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key Responsible personnel interviewed:
Modified
p. 126 → 120
• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key.
• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key <Report Findings Here>
Removed
p. 127
• Identification of key personnel
Modified
p. 127 → 121
<Report Findings Here> 22-1.4.b A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including:
<Report Findings Here> 22-1.4.b Examine/observe notifications to verify they include the following:
Modified
p. 127 → 121
• Specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
• Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Modified
p. 129 → 123
22-3 Through the examination of documented procedures, interviews, and observation, confirm that Root CAs provide for segmentation of risk to address key compromise.
22-3 Examine documented procedures, interview personnel, and observe processes to confirm that Root CAs provide for segmentation of risk to address key compromise.
Modified
p. 129 → 123
• Notify affected entities.
• Notify affected entities Documented procedures examined:
Modified
p. 130 → 124
• The CA will cease issuance of certificates.
• The CA will cease issuance of certificates
Modified
p. 130 → 124
• The CA will cease issuance of certificates.
• The CA will cease issuance of certificates
Modified
p. 130 → 124
• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.
• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred Documented procedures examined:
Modified
p. 130 → 124
• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.
• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred Responsible personnel interviewed:
Removed
p. 131
• Reissue and distribute certificates to affected parties, or
• Notify the affected parties to apply for new certificates.
• Notify the affected parties to apply for new certificates.
Modified
p. 131 → 125
• The CA will notify any superior CAs. The CA will notify any subordinate CAs.
• The CA will notify any superior CAs. The CA will notify any subordinate CAs
Modified
p. 131 → 125
• The CA will perform a damage assessment to determine the need to either:
• The CA will perform a damage assessment to determine the need to either: - Reissue and distribute certificates to affected parties, or - Notify the affected parties to apply for new certificates Documented procedures examined:
Modified
p. 131 → 125
• The CA notifies any superior CAs.
• The CA notifies any superior CAs
Modified
p. 131 → 125
• The CA notifies any subordinate CAs.
• The CA notifies any subordinate CAs
Modified
p. 131 → 125
• 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.
• 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 Responsible personnel interviewed:
Modified
p. 132 → 126
• Root and subordinate CAs have a minimum RSA 2048 bits or equivalent;
• Root and subordinate CAs have a minimum RSA 2048 bits or equivalent
Modified
p. 132 → 126
• POI devices and KDHs have a minimum RSA 2048 bits or equivalent.
• POI devices and KDHs have a minimum RSA 2048 bits or equivalent 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.
Modified
p. 132 → 126
<Report Findings Here> 22-5.b Verify that the following minimum key sizes exist for RSA keys or the equivalent for the algorithm used as defined in Annex C:
<Report Findings Here> 22-5.b Examine/observe as needed to verify that the following minimum key sizes exist for RSA keys or the equivalent for the algorithm used as defined in Annex C:
Modified
p. 132 → 126
<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.
<Report Findings Here> 22-5.c Examine/observe as needed to verify that KDH keys expire every five years unless another mechanism exists to prevent the use of a compromised KDH private key.
Modified
p. 133 → 127
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 23-1.b Observe processes to verify that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge.
Documented procedures examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 23-1.b Observe processes to verify that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge.
Modified
p. 134 → 128
Note: Using transformations of keys across different levels of a key hierarchy
•e.g., generating a DEK from akey-encrypting key
•increases the risk of exposure of each of those keys.
•e.g., generating a DEK from a
•increases the risk of exposure of each of those keys.
Note: Using transformations of keys across different levels of a key hierarchy
•e.g., generating a DEK from a key- encrypting key
•increases the risk of exposure of each of those keys.
•e.g., generating a DEK from a key- encrypting key
•increases the risk of exposure of each of those keys.
Modified
p. 134 → 128
• Variants of working keys must only be calculated from other working keys.
• Variants of working keys must only be calculated from other working keys Documented procedures examined:
Modified
p. 134 → 128
• Variants of working keys must only be calculated from other working keys.
• Variants of working keys must only be calculated from other working keys <Report Findings Here>
Modified
p. 135 → 129
24-1.a Verify documented procedures are in place for destroying secret or private keys, and their key components that are no longer used or that have been replaced by a new key.
24-1.a Examine documented procedures to verify they are in place for destroying secret or private keys, and their key components that are no longer used or that have been replaced by a new key.
Modified
p. 135 → 129
<Report Findings Here> 24-1.b Identify a sample of keys and key components that are no longer used or have been replaced. For each item in the sample, interview responsible personnel and examine key- history logs and key-destruction logs to verify that all keys have been destroyed.
<Report Findings Here> 24-1.b Observe a sample of keys and key components to verify that they are no longer used or have been replaced. For each item in the sample, interview responsible personnel and examine key-history logs and key-destruction logs to verify that all keys have been destroyed.
Modified
p. 137 → 131
<Report Findings Here> 24-2.2.b Inspect key-destruction logs and verify that a third- party, non-key-custodian witness signs an affidavit as a witness to the key destruction process.
<Report Findings Here> 24-2.2.b Examine key-destruction logs and verify that a third- party, non-key-custodian witness signs an affidavit as a witness to the key destruction process.
Modified
p. 137 → 131
Key-destruction logs inspected: <Report Findings Here> 24-2.3 Key components for keys other than the HSM or KLD MFKs that have been successfully loaded and confirmed as operational must also be destroyed, unless the HSM does not store the encrypted values on a database but only stores the subordinate keys internal to the HSM. BDKs used in KLDs may also be stored as components where necessary to reload the KLD.
Key-destruction logs examined: <Report Findings Here> 24-2.3 Key components for keys other than the HSM or KLD MFKs that have been successfully loaded and confirmed as operational must also be destroyed, unless the HSM does not store the encrypted values on a database but only stores the subordinate keys internal to the HSM. BDKs used in KLDs may also be stored as components where necessary to reload the KLD.
Modified
p. 137 → 131
24-2.3.a Verify documented procedures exist for destroying key components of keys once the keys are successfully loaded and validated as operational.
24-2.3.a Examine documented procedures to verify they include destroying key components of keys once the keys are successfully loaded and validated as operational.
Modified
p. 140 → 134
• Ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian);
• Ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian)
Modified
p. 140 → 134
• Receive explicit training to instruct them from sharing key components with their direct manager;
• Receive explicit training to instruct them from sharing key components with their direct manager
Modified
p. 140 → 134
• Receive training that includes procedures to report any violations.
• Receive training that includes procedures to report any violations 25-1.4.a Examine key-custodian assignments and organization charts to confirm the following:
Modified
p. 140 → 134
• Key custodians that form the necessary threshold to create a key do not directly report to the same individual.
• Key custodians that form the necessary threshold to create a key do not directly report to the same individual
Modified
p. 140 → 134
• Neither direct reports nor the direct reports in combination with their immediate supervisors possess the necessary threshold of key components sufficient to form any given key.
• Neither direct reports nor the direct reports in combination with their immediate supervisors possess the necessary threshold of key components sufficient to form any given key
Modified
p. 140 → 134
• Key custodians are not and have not been a custodian for another component/share of a key where that collectively would constitute a quorum to form the actual key.
• Key custodians are not and have not been a custodian for another component/share of a key where that collectively would constitute a quorum to form the actual key Documented key-custodian assignments examined:
Modified
p. 141 → 135
• Ensure key custodians do not report to each other.
• Ensure key custodians do not report to each other
Modified
p. 141 → 135
• Receive explicit training to instruct them from sharing key components with their direct manager.
• Receive explicit training to instruct them from sharing key components with their direct manager
Modified
p. 141 → 135
• Sign key-custodian agreement that includes an attestation to the requirement.
• Sign key-custodian agreement that includes an attestation to the requirement
Modified
p. 141 → 135
• Ensure training includes procedures to report any violations.
• Ensure training includes procedures to report any violations Documented procedures examined:
Modified
p. 141 → 135
<Report Findings Here> 25-2.1.b Observe user role assignments and access-control mechanisms to verify that access to material that can be used to construct secret and private keys is restricted to actions authorized for that role.
<Report Findings Here> 25-2.1.b Observe user role assignments and access-control mechanisms to verify that access to material that can be used to Describe how the user role assignments and access-control mechanisms observed verified that access to material that can be used to construct secret and private keys is restricted to actions authorized for that role:
Modified
p. 142 → 136
• The network must only be used for certificate issuance and/or revocation.
• The network must only be used for certificate issuance and/or revocation
Modified
p. 142 → 136
• Outside network access (e.g., using a separate platform in the DMZ) must exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
• Outside network access (e.g., using a separate platform in the DMZ) must exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs) 25-3.1 Examine network diagrams and observe network and system configurations to verify:
Modified
p. 142 → 136
• CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment).
• CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment)
Modified
p. 142 → 136
• CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment).
• CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment)
Modified
p. 142 → 136
• The network is only used for certificate issuance, revocation, or both certificate issuance and revocation.
• The network is only used for certificate issuance, revocation, or both certificate issuance and revocation
Modified
p. 142 → 136
• The network is only used for certificate issuance, revocation, or both certificate issuance and revocation.
• The network is only used for certificate issuance, revocation, or both certificate issuance and revocation
Modified
p. 142 → 136
• Outside network access must exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
• Outside network access must exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs) Network diagrams examined <Report Findings Here> Describe how the network diagrams and network and system configurations observed verified that:
Modified
p. 143 → 137
Describe how observation of the authorized CA personnel’s attempted nonconsole access to the host platform using valid CA credentials without using an authenticated encrypted session verified that non-console access is not permitted:
Describe how observation of the authorized CA personnel’s attempted non console access to the host platform using valid CA credentials without using an authenticated encrypted session verified that non-console access is not permitted:
Removed
p. 145
• There is documentation to support all active services and ports.
Modified
p. 145 → 139
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, etc., commands in UNIX) must be removed or disabled.
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, etc., commands in UNIX) must be removed or disabled
Modified
p. 145 → 139
• Unnecessary ports must also be disabled.
• Unnecessary ports must also be disabled
Modified
p. 145 → 139
• Documentation must exist to support the enablement of all active services and ports.
• Documentation must exist to support the enablement of all active services and ports System documentation examined:
Modified
p. 145 → 139
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, etc., commands in UNIX) are removed or disabled.
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, etc., commands in UNIX) are removed or disabled
Modified
p. 145 → 139
• Unnecessary ports are disabled.
• Unnecessary ports are disabled
Modified
p. 145 → 139
• Unnecessary ports are disabled.
• Unnecessary ports are disabled
Modified
p. 145 → 139
• There is documentation to support all active services and ports.
• There is documentation to support all active services and ports <Report Findings Here>
Modified
p. 145 → 139
Sample of systems reviewed: <Report Findings Here> Documentation examined: <Report Findings Here> Describe how the observed system configurations observed verified that:
• There is documentation to support all active services and ports Sample of systems reviewed: <Report Findings Here> Documentation examined: <Report Findings Here> Describe how the observed system configurations observed verified that:
Modified
p. 145 → 139
• Services that are not necessary or that allow non-secure access (e.g.,rlogin, rshell, etc., commands in UNIX) are removed or disabled.
• Services that are not necessary or that allow non-secure access (e.g.,rlogin, rshell, etc., commands in UNIX) are removed or disabled
Modified
p. 146 → 140
• Vendor-default IDs are changed, removed, or disabled unless necessary for a documented and specific business reason.
• Vendor-default IDs are changed, removed, or disabled unless necessary for a documented and specific business reason
Modified
p. 146 → 140
• Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades are only be enabled when required and otherwise must be disabled from login.
• Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades are only be enabled when required and otherwise must be disabled from login Documented procedures examined:
Modified
p. 146 → 140
• Vendor-default IDs are changed, removed or disabled unless necessary for a documented and specific business reason.
• Vendor-default IDs are changed, removed or disabled unless necessary for a documented and specific business reason
Modified
p. 146 → 140
• Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades are only be enabled when required and otherwise must be disabled from login.
• Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades are only be enabled when required and otherwise must be disabled from login Responsible personnel interviewed:
Modified
p. 148 → 142
• Mechanisms exist to protect logs from alteration and destruction Sample of key-management operations <Report Findings Here> Describe how the examined audit trails for a sample of key-managementoperations verified they include:
• Mechanisms exist to protect logs from alteration and destruction Sample of key-management operations examined:
Modified
p. 149 → 143
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:
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:
Modified
p. 149 → 143
Sample of operating-system logs <Report Findings Here>
• Success or failure of the event Sample of operating-system logs <Report Findings Here>
Modified
p. 149 → 144
• Success or failure of the event.
• Success or failure of the event Sample of application logs examined:
Removed
p. 150
• Success or failure of the event.
Modified
p. 150 → 144
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. 151 → 145
• 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. 151 → 145
• 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. 151 → 145
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled.
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled 25-7.1.a Examine network and system configurations to verify that certificate-processing system components operated online are protected from unauthorized access by firewall(s).
Modified
p. 151 → 145
• Fail to a configuration that denies all services and require a firewall administrator to re-enable services after a failure.
• Fail to a configuration that denies all services and require a firewall administrator to re-enable services after a failure
Modified
p. 151 → 145
• 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. 151 → 145
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled.
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled <Report Findings Here>
Modified
p. 151 → 145
• Fail to a configuration that denies all services, and require a firewall administrator to re-enable services after a failure.
• Fail to a configuration that denies all services, and require a firewall administrator to re-enable services after a failure
Modified
p. 151 → 145
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled.
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled Describe how the observed firewall configurations verified they are configured to:
Modified
p. 152 → 146
<Report Findings Here> 25-7.2.b Verify that IDS coverage includes all database servers, RA application servers and web servers, as well as the intervening segments.
<Report Findings Here> 25-7.2.b Examine/observe that IDS coverage includes all database servers, RA application servers and web servers, as well as the intervening segments.
Modified
p. 152 → 146
<Report Findings Here> 25.8.2 Use of group, shared, or generic accounts and passwords, or other authentication methods is prohibited.
<Report Findings Here> 25-8.2 Use of group, shared, or generic accounts and passwords, or other authentication methods is prohibited.
Modified
p. 152 → 146
25-8.2.a For a sample of system components, examine user ID lists to verify the following:
Modified
p. 152 → 146
• Generic user IDs and accounts are disabled or removed.
• Generic user IDs and accounts are disabled or removed
Modified
p. 152 → 146
• Generic user IDs and accounts are disabled or removed.
• Generic user IDs and accounts are disabled or removed
Modified
p. 152 → 146
• Shared user IDs for system administration activities and other critical functions do not exist.
• Shared user IDs for system administration activities and other critical functions do not exist
Modified
p. 152 → 146
• Shared user IDs for system administration activities and other critical functions do not exist.
• Shared user IDs for system administration activities and other critical functions do not exist
Modified
p. 152 → 146
• Shared and generic user IDs are not used.
• Shared and generic user IDs are not used Sample of system components examined:
Modified
p. 152 → 146
• Shared and generic user IDs are not used.
• Shared and generic user IDs are not used <Report Findings Here>
Modified
p. 153 → 147
<Report Findings Here> 25.8.2.c Interview system administrators to verify that group and shared passwords or other authentication methods are not distributed•even if requested.
<Report Findings Here> 25-8.2.c Interview system administrators to verify that group and shared passwords or other authentication methods are not distributed•even if requested.
Modified
p. 153 → 147
<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.
<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.
Modified
p. 153 → 147
<Report Findings Here> 25.8.4 Passwords must have a minimum length of eight characters using a mix of alphabetic, numeric, and special characters or equivalent strength as defined in NIST SP 800-63B.
<Report Findings Here> 25-8.4 Passwords must have a minimum length of eight characters using a mix of alphabetic, numeric, and special characters or equivalent strength as defined in NIST SP 800-63B.
Modified
p. 153 → 147
<Report Findings Here> 25.8.5 Limit repeated access attempts by locking out the user ID after not more than five attempts.
<Report Findings Here> 25-8.5 Limit repeated access attempts by locking out the user ID after not more than five attempts.
Modified
p. 154 → 148
<Report Findings Here> 25.8.7 Passwords are not stored on any of the systems except in encrypted form or as part of a proprietary one-way transformation process, such as those used in UNIX systems.
<Report Findings Here> 25-8.7 Passwords are not stored on any of the systems except in encrypted form or as part of a proprietary one-way transformation process, such as those used in UNIX systems.
Modified
p. 154 → 148
<Report Findings Here> 25.8.8 The embedding of passwords in shell scripts, command files, communication scripts, etc. is strictly prohibited.
<Report Findings Here> 25-8.8 The embedding of passwords in shell scripts, command files, communication scripts, etc. is strictly prohibited.
Modified
p. 154 → 148
25-8.8.a Examine policies and procedures and interview personnel to determine that the embedding of passwords in shell scripts, command files, communication scripts, etc. is strictly prohibited.
Modified
p. 154 → 148
<Report Findings Here> Personnel interviewed: <Report Findings Here> 25.8.8.b Inspect a sample of shell scripts, command files, communication scripts, etc. to verify that passwords are not embedded in shell scripts, command files, or communication scripts.
<Report Findings Here> Personnel interviewed: <Report Findings Here> 25-8.8.b Examine a sample of shell scripts, command files, communication scripts, etc. to verify that passwords are not embedded in shell scripts, command files, or communication scripts.
Modified
p. 154 → 148
Sample of shell scripts, command files, communication scripts, etc. inspected:
Sample of shell scripts, command files, communication scripts, etc. examined:
Modified
p. 155 → 149
25-8.9.a If log-on security tokens are used, observe devices in use to verify that the security tokens have an associated usage- authentication mechanism, such as a biometric or associated PIN/passphrase to enable their usage.
Modified
p. 155 → 149
<Report Findings Here> 25.8.9.b Examine token-configuration settings to verify parameters are set to require that PINs/passwords be at least eight decimal digits in length, or equivalent.
<Report Findings Here> 25-8.9.b Examine token-configuration settings to verify parameters are set to require that PINs/passwords be at least eight decimal digits in length, or equivalent.
Modified
p. 155 → 149
<Report Findings Here> 25.9 Implement a method to synchronize all critical system clocks and times for all systems involved in key-management operations.
<Report Findings Here> 25-9 Implement a method to synchronize all critical system clocks and times for all systems involved in key-management operations.
Modified
p. 155 → 149
25-9.a Examine documented procedures and system configuration standards to verify a method is defined to synchronize all critical system clocks and times for all systems involved in key-management operations.
Modified
p. 155 → 149
<Report Findings Here> 25.9.b For a sample of critical systems, examine the time- related system parameters to verify that system clocks and times are synchronized for all systems involved in key- management operations.
<Report Findings Here> 25-9.b For a sample of critical systems, examine the time- related system parameters to verify that system clocks and times are synchronized for all systems involved in key- management operations.
Modified
p. 155 → 149
<Report Findings Here> CA/RA 25.9.c If a manual process is defined, verify that the documented procedures require that it occur at least quarterly.
<Report Findings Here> CA/RA 25-9.c If a manual process is defined, examine documented procedures require that it occur at least quarterly.
Modified
p. 156 → 150
• Logs must be archived for a minimum of two years subsequent to key destruction Personnel interviewed: <Report Findings Here> Documented procedures reviewed:
• Logs must be archived for a minimum of two years subsequent to key destruction Personnel interviewed: <Report Findings Here> Documented procedures examined:
Modified
p. 158 → 152
<Report Findings Here> Personnel interviewed: <Report Findings Here> OR Describe how backup storage locations verified that backups are maintained as follows:
<Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how backup storage locations verified that backups are maintained as follows:
Modified
p. 160 → 154
• CA operations must be dedicated to certificate issuance and management.
• CA operations must be dedicated to certificate issuance and management
Modified
p. 160 → 154
• All physical and logical CA system components must be separated from key-distribution systems.
• All physical and logical CA system components must be separated from key-distribution systems Documented procedures examined:
Modified
p. 161 → 155
• The CPS must be consistent with the requirements described within this document.
• The CPS must be consistent with the requirements described within this document
Modified
p. 161 → 155
• The CA must operate in accordance with its CPS.
• The CA must operate in accordance with its CPS
Removed
p. 162
• Determination that the organization exists by using at least one third-party identity-proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization;
Modified
p. 162 → 156
Documented certificate policy reviewed:
Documented certificate policy examined:
Modified
p. 162 → 156
• Verification of the certificate applicant’s possession of the associated private key through the use of a digitally signed certificate request pursuant to PKCS #10 or another cryptographically-equivalent demonstration;
• Verification of the certificate applicant’s possession of the associated private key through the use of a digitally signed certificate request pursuant to PKCS #10 or another cryptographically-equivalent demonstration
Modified
p. 162 → 156
• Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the certificate applicant to confirm that the organization has authorized the certificate application, confirmation of the employment of the representative submitting the certificate application on behalf of the certificate applicant, and confirmation of the authority of the representative to act on behalf of the certificate applicant;
• Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the certificate applicant to confirm that the organization has authorized the certificate application, confirmation of the employment of the representative submitting the certificate application on behalf of the certificate applicant, and confirmation of the authority of the representative to act on behalf of the certificate applicant
Modified
p. 162 → 156
• Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the certificate applicant’s representative to confirm that the person named as representative has submitted the certificate application.
• Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the certificate applicant’s representative to confirm that the person named as representative has submitted the certificate application 28-5.a Examine documented procedures to verify that unless the certificate request is generated within the same secure room meeting the requirements of the Level 3 environment, they include validating the identity of the certificate requestor and recipient before issuing a digital certificate for the recipient’s associated public key.
Modified
p. 163 → 157
• The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner.
• The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner Documented procedures examined:
Modified
p. 163 → 157
28-5.1.a Examine documented procedures to verify that certificate-signing requests, including certificate or key-validity status changes, require validation that:
• The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner 28-5.1.a Examine documented procedures to verify that certificate-signing requests, including certificate or key-validity status changes, require validation that:
Modified
p. 163 → 158
• The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner.
• The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner Certificate-signing requests reviewed:
Removed
p. 164
• The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner.
Removed
p. 165
• POI devices have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 165 → 159
Note: This applies to SCDs used for key injection or code signing, including display prompts.
Note: This also applies to SCDs used for key injection.
Modified
p. 165 → 159
• POI devices have not been substituted or subjected to unauthorized modifications or tampering.
• PTS POI devices have not been substituted or subjected to unauthorized modifications or tampering
Modified
p. 165 → 159
• POI devices have not been substituted or subjected to unauthorized modifications or tampering.
• PTS POI devices have not been substituted or subjected to unauthorized modifications or tampering
Modified
p. 165 → 159
• SCDs used for key injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
• SCDs used for key injection/loading have not been substituted or subjected to unauthorized modifications or tampering Documented procedures examined:
Modified
p. 165 → 159
• SCDs used for key injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
• PTS POI devices have not been substituted or subjected to unauthorized modifications or tampering
Modified
p. 165 → 159
Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that processes are followed to provide the following assurances prior to the loading of cryptographic keys:
• SCDs used for key injection/loading have not been substituted or subjected to unauthorized modifications or tampering Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that processes are followed to provide the following assurances prior to the loading of cryptographic keys:
Modified
p. 165 → 159
• SCDs used for key injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
• SCDs used for key injection/loading have not been substituted or subjected to unauthorized modifications or tampering 29-1.1 All POI devices and other SCDs must be protected against compromise. Any compromise must be detected. Loading and use of any financial keys after the compromise must be prevented. Controls must include the following:
Modified
p. 166 → 160
29-1.1.1.a Examine access-control documentation and device configurations to verify that access to all POI devices and key injection/loading devices is defined and documented.
29-1.1.1.a Examine access-control documentation and device configurations to verify that access to all PTS POI devices and key injection/loading devices is defined and documented.
Modified
p. 166 → 160
Access-control documentation reviewed:
Access-control documentation examined:
Modified
p. 166 → 160
<Report Findings Here> Describe how access-control documentation and device configurations observed verified that access to all POI devices and key injection/loading devices is defined and documented:
<Report Findings Here> Describe how access-control documentation and device configurations observed verified that access to all PTS POI devices and key injection/loading devices is defined and documented:
Modified
p. 166 → 160
<Report Findings Here> 29-1.1.1.b For a sample of POI device types and other SCDs, observe authorized personnel accessing devices and examine access logs to verify that access to all POI devices and other SCDs is logged.
<Report Findings Here> 29-1.1.1.b For a sample of PTS POI device types and other SCDs, observe authorized personnel accessing devices and examine access logs to verify that access to all PTS POI devices and other SCDs is logged.
Modified
p. 166 → 160
<Report Findings Here> Access logs reviewed: <Report Findings Here> Describe how observation of authorized personnel accessing devices and access logs verified that access to all POI devices and other SCDs is logged:
<Report Findings Here> Access logs examined: <Report Findings Here> Describe how observation of authorized personnel accessing devices and access logs verified that access to all PTS POI devices and other SCDs is logged:
Modified
p. 166 → 160
<Report Findings Here> 29-1.1.1.c Examine implemented access controls to verify that unauthorized individuals cannot access, modify, or substitute any POI device or other SCD.
<Report Findings Here> 29-1.1.1.c Examine implemented access controls to verify that unauthorized individuals cannot access, modify, or substitute any PTS POI device or other SCD.
Modified
p. 166 → 160
Describe how the implemented access controls examined verified that unauthorized individuals cannot access, modify, or substitute any POI device or other SCD:
Describe how the implemented access controls examined verified that unauthorized individuals cannot access, modify, or substitute any PTS POI device or other SCD:
Removed
p. 167
Documented authorizations reviewed:
Modified
p. 167 → 160
Note: “Prior to deployment” for this requirement means prior to the solution provider (or component provider) sending POI devices to either a distribution channel or the end merchant who will use the POI device to process payment transactions.
Note: “Prior to deployment” for this requirement means prior to the solution provider (or component provider) sending PTS POI devices to either a distribution channel or the end merchant who will use the POI device to process payment transactions.
Modified
p. 167 → 161
• All personnel with access to POI devices and other SCDs are documented in a formal list authorized by management in an auditable manner.
• All personnel with access to PTS POI devices and other SCDs are documented in a formal list authorized by management in an auditable manner
Modified
p. 167 → 161
• The authorizations are reviewed annually.
• The authorizations are reviewed annually Documented authorizations examined :
Modified
p. 167 → 161
<Report Findings Here> 29-1.1.2.b For a sample of POI device types and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in an auditable manner have access to devices.
<Report Findings Here> 29-1.1.2.b For a sample of PTS POI device types and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in an auditable manner have access to devices.
Modified
p. 167 → 161
<Report Findings Here> Describe how the implemented access controls for the sample of POI device types and other SCDs examined verified that only personnel documented and authorized in an auditable manner have access to devices:
<Report Findings Here> Describe how the implemented access controls for the sample of PTS POI device types and other SCDs examined verified that only personnel documented and authorized in an auditable manner have access to devices:
Modified
p. 167 → 161
<Report Findings Here> 29-1.2 POI devices and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords/authentication codes.
<Report Findings Here> 29-1.2 PTS POI devices and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords/authentication codes.
Removed
p. 168
Documented records reviewed: <Report Findings Here>
Modified
p. 168 → 161
Note: Chain of custody includes procedures, as stated in Requirement 29-1, that ensure that access to all POI devices and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
Note: Chain of custody includes procedures, as stated in Requirement 29-1, that ensure that access to all PTS POI devices and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
Modified
p. 168 → 162
<Report Findings Here> Documented records reviewed: <Report Findings Here> Responsible personnel interviewed:
<Report Findings Here> Documented records examined: <Report Findings Here> Responsible personnel interviewed:
Modified
p. 168 → 162
<Report Findings Here> 29-2.c Verify that the chain-of-custody records identify responsible personnel for each interaction with the device.
<Report Findings Here> 29-2.c Examine the chain-of-custody records to verify they identify responsible personnel for each interaction with the device.
Removed
p. 169
(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.
Modified
p. 169 → 162
• 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. 169 → 162
• Physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging) is used. The devices are then stored in such packaging, or in secure storage, until key-insertion occurs.
• Physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging) is used. The devices are then stored in such packaging, or in secure storage, until key-insertion occurs
Modified
p. 169 → 162
• Upon tamper of the device it becomes infeasible to load any keying material.
• Upon tamper of the device it becomes infeasible to load any keying material
Modified
p. 169 → 162
• 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 …
• 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 …
• 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 …
• 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 …
Modified
p. 169 → 162
Note: Unauthorized access includes that by customs officials. o Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised.
Note: Unauthorized access includes that by customs officials. o Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised (Note: this 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
Modified
p. 170 → 163
•both in service and spare or back-up devices
<Report Findings Here> Identify the P2PE Assessor who physically verified the dual- control mechanism used to prevent substitution or tampering of HSMs
•both in service and spare or back-up devices
•both in service and spare or back-up devices
Modified
p. 170 → 164
Sample of received devices: <Report Findings Here> Sender documentation/record of serial number validations reviewed:
Sample of received devices: <Report Findings Here> Sender documentation/record of serial number validations examined:
Removed
p. 171
<Report Findings Here> 29-4.2.c For a sample of HSMs, examine the configuration settings to determine that only authorized functions are enabled.
Modified
p. 171 → 164
29-4.2.a Obtain and examine the defined security policy to be enforced by the HSM.
29-4.2.a Examine the defined security policy to be enforced by the HSM.
Modified
p. 171 → 165
• Configuration settings are defined, signed and dated by personnel responsible for implementation.
• Configuration settings are defined, signed and dated by personnel responsible for implementation
Modified
p. 171 → 165
• It includes identifying information for the HSM, such as serial number and/or asset identifiers.
• It includes identifying information for the HSM, such as serial number and/or asset identifiers
Modified
p. 171 → 165
• The documentation is retained and updated anytime configuration setting impacting security occur for each affected HSM.
• The documentation is retained and updated anytime configuration setting impacting security occur for each affected HSM Documentation examined: <Report Findings Here> 29-4.3 When HSMs are connected to online systems, controls are in place to prevent the use of an HSM to perform privileged or sensitive functions that are not available during routine HSM operations.
Removed
p. 172
<Report Findings Here> 29-4.4.1 Running self-tests to ensure the correct operation of the device.
Modified
p. 172 → 165
Note: Examples of sensitive functions include but are not limited to: loading of key components, outputting clear-text key components, and altering HSM configuration.
Note: Examples of sensitive functions include but are not limited to: loading of key components, outputting cleartext key components, and altering HSM configuration.
Removed
p. 173
<Report Findings Here> 29-4.4.4.b Examine records of inspections to verify records are retained for at least one year.
Modified
p. 174 → 167
• Each production run must be associated with a predefined inventory of identified POI devices to be injected or initialized with keys.
• Each production run must be associated with a predefined inventory of identified POI devices to be injected or initialized with keys
Modified
p. 174 → 167
• Unauthorized personnel must not be able to modify this inventory without detection.
• Unauthorized personnel must not be able to modify this inventory without detection
Modified
p. 174 → 167
• All POI devices to be initialized with keys on a production run must be identified and accounted for against the inventory.
• All POI devices to be initialized with keys on a production run must be identified and accounted for against the inventory
Modified
p. 174 → 167
• Unauthorized POI devices submitted for injection or initialized must be rejected by the injection platform and investigated.
• Unauthorized POI devices submitted for injection or initialized must be rejected by the injection platform and investigated
Modified
p. 174 → 167
• Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices must be identified and accounted for against the inventory.
• Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices must be identified and accounted for against the inventory
Modified
p. 174 → 168
• Each production run is associated with a predefined inventory of identified POI devices to be injected or initialized with keys.
• Each production run is associated with a predefined inventory of identified POI devices to be injected or initialized with keys
Modified
p. 174 → 168
• Unauthorized personnel are not able to modify this inventory without detection.
• Unauthorized personnel are not able to modify this inventory without detection
Modified
p. 174 → 168
• All POI devices to be initialized with keys on a production run are identified and accounted for against the inventory.
• All POI devices to be initialized with keys on a production run are identified and accounted for against the inventory
Modified
p. 174 → 168
• Unauthorized POI devices submitted for injection or initialized are rejected by the injection platform and investigated.
• Unauthorized POI devices submitted for injection or initialized are rejected by the injection platform and investigated
Modified
p. 174 → 168
• Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices are identified and accounted for against the inventory.
• Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices are identified and accounted for against the inventory Documented procedures examined:
Removed
p. 175
• 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. 175 → 169
• Procedures require that all secret and private keys, key material, and all account data stored within the device be securely destroyed.
• Procedures require that all secret and private keys, key material, and all account data stored within the device be securely destroyed
Modified
p. 175 → 169
• Procedures cover all devices removed from service permanently or for repair.
• Procedures cover all devices removed from service permanently or for repair
Modified
p. 175 → 169
• Procedures cover requirements at 31-1.1 through 31-1.6 below.
• Procedures cover requirements at 31-1.1 through 31-1.6 below Documented procedures examined:
Modified
p. 177 → 171
Personnel interviewed: <Report Findings Here> Records of testing examined: <Report Findings Here> 32-1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, or for signing applications and/or whitelists to be loaded into POI devices, procedures must be documented and implemented to protect against unauthorized access and use.
Personnel interviewed: <Report Findings Here> Records of testing examined: <Report Findings Here> 32-1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, , procedures must be documented and implemented to protect against unauthorized access and use.
Modified
p. 177 → 171
32-1.a Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices, or for signing applications and/or whitelists to be loaded into POI devices.
32-1.a Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices.
Modified
p. 178 → 171
32-1.1 Observe dual-control mechanisms and device- authorization processes to confirm that logical and/or physical characteristics are in place that prevent the device being authorized for use except under the dual control of at least two authorized people.
32-1.1 Observe dual-control mechanisms and device- authorization processes to confirm that logical and/or physical characteristics are in place that prevent the device being Describe how the dual-control mechanisms and device-authorization processes observed verified that logical and/or physical characteristics are in place that prevent the device being authorized for use except under the dual control of at least two authorized people:
Modified
p. 179 → 173
• To enable any manual key-encryption functions and any key-encryption functions that occur outside of normal transaction processing;
• To enable any manual key-encryption functions and any key-encryption functions that occur outside of normal transaction processing
Modified
p. 179 → 173
• To enable application-signing functions;
• To enable application-signing functions
Modified
p. 179 → 173
• To place the device into a state that allows for the input or output of clear-text key components;
• To place the device into a state that allows for the input or output of cleartext key components
Modified
p. 179 → 173
• For all access to key-loading devices (KLDs) and authenticated application-signing devices.
• For all access to key-loading devices (KLDs) and authenticated application-signing devices 32-1.3 Examine dual-control mechanisms and observe authorized personnel performing the defined activities to confirm that dual control is implemented for the following:
Modified
p. 179 → 173
• To place the device into a state that allows for the input or output of clear-text key components
• To place the device into a state that allows for the input or output of cleartext key components
Modified
p. 179 → 173
• To place the device into a state that allows for the input or output of clear-text key components
• To place the device into a state that allows for the input or output of cleartext key components
Modified
p. 179 → 173
Documented procedures and password policies reviewed:
Documented procedures and password policies examined:
Modified
p. 180 → 174
• Under the continuous supervision of at least two authorized people who ensure that any unauthorized use of the device would be detected.
• Under the continuous supervision of at least two authorized people who ensure that any unauthorized use of the device would be detected
Modified
p. 180 → 174
• Under the continuous supervision of at least two authorized people at all times.
• Under the continuous supervision of at least two authorized people at all times Documented procedures examined:
Modified
p. 180 → 174
• Under the continuous supervision of at least two authorized people at all times.
• Under the continuous supervision of at least two authorized people at all times Responsible personnel interviewed:
Modified
p. 182 → 176
Documented physical-security procedures and policies reviewed:
Documented physical-security procedures and policies examined:
Modified
p. 182 → 176
Documented physical-security procedures and policies reviewed:
Documented physical-security procedures and policies examined:
Modified
p. 184 → 178
Sample of recorded footage reviewed:
Sample of recorded footage examined:
Modified
p. 185 → 179
32-2.5.2.a Examine physical security documentation for the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as have true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars Physical security documentation reviewed:
32-2.5.2.a Examine physical security documentation for the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as have true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars Physical security documentation examined:
Removed
p. 186
• Be assigned resources of the CA operator with defined business needs and duties.
Modified
p. 186 → 180
• Have successfully completed a background security check.
• Have successfully completed a background security check
Modified
p. 186 → 180
Documented policies and procedures <Report Findings Here> 32-2.6.1.b Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws) on CA personnel prior such personnel being authorized for access through the Level 3 barrier.
• Be assigned resources of the CA operator with defined business needs and duties Documented policies and procedures <Report Findings Here> 32-2.6.1.b Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws) on CA personnel prior such personnel being authorized for access through the Level 3 barrier.
Modified
p. 188 → 182
Sample of audit events reviewed:
Sample of audit events examined:
Removed
p. 189
• A minimum of five frames are recorded every three seconds.
Modified
p. 189 → 183
• The system records to time-lapse VCRs or similar mechanisms.
• The system records to time-lapse VCRs or similar mechanisms
Modified
p. 189 → 183
• The system records to time-lapse VCRs or similar mechanisms.
• The system records to time-lapse VCRs or similar mechanisms
Modified
p. 189 → 183
• A minimum of five frames are recorded every three seconds.
• A minimum of five frames are recorded every three seconds <Report Findings Here>
Modified
p. 189 → 183
Describe how the monitoring system configurations observed verified that:
• A minimum of five frames are recorded every three seconds Describe how the monitoring system configurations observed verified that:
Modified
p. 190 → 184
Identify the P2PE Assessor who confirms that continuous or motionactivated lighting is provided for each camera monitoring the Level 3 physical environment:
Identify the P2PE Assessor who confirms that continuous or motion activated lighting is provided for each camera monitoring the Level 3 physical environment:
Modified
p. 190 → 184
Sample of captured footage reviewed:
Sample of captured footage examined:
Modified
p. 190 → 184
Sample of captured footage reviewed:
Sample of captured footage examined:
Removed
p. 191
• Ensure that segregation is maintained between users and administrators of the system.
Modified
p. 191 → 185
Describe how the system configurations observed verified that where digitalrecording mechanisms are in use, the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period:
Describe how the system configurations observed verified that where digital recording mechanisms are in use, the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period:
Modified
p. 191 → 185
• Backups are securely stored in a separate location from the primary.
• Backups are securely stored in a separate location from the primary
Modified
p. 191 → 185
• Backups are securely stored in a separate location from the primary.
• Backups are securely stored in a separate location from the primary
Modified
p. 191 → 185
• Ensure that segregation is maintained between users and administrators of the system.
• Ensure that segregation is maintained between users and administrators of the system <Report Findings Here>
Modified
p. 191 → 185
Describe how the observed backup techniques verified that:
• Ensure that segregation is maintained between users and administrators of the system Describe how the observed backup techniques verified that:
Modified
p. 192 → 186
• Motion detectors must be active when the environment is unoccupied.
• Motion detectors must be active when the environment is unoccupied Documented security policies and procedures examined:
Modified
p. 192 → 186
• Motion detectors are active when the environment is unoccupied.
• Motion detectors are active when the environment is unoccupied Describe how the observed intrusion-detection system configurations verified that:
Modified
p. 192 → 186
• Continuous (24/7) intrusion-detection monitoring of the Level 3 environment is in place.
• Continuous (24/7) intrusion-detection monitoring of the Level 3 environment is in place
Removed
p. 193
<Report Findings Here> 32-3.3.b Verify the IDS and alarms function correctly via:
Modified
p. 193 → 187
• The intrusion-detection system(s) is connected to the alarm system.
• The intrusion-detection system(s) is connected to the alarm system
Modified
p. 193 → 187
• The intrusion-detection system(s) is connected to the alarm system.
• The intrusion-detection system(s) is connected to the alarm system
Modified
p. 193 → 187
• The intrusion-detection system(s) is automatically activated every time all authorized personnel have exited the secure room.
• The intrusion-detection system(s) is automatically activated every time all authorized personnel have exited the secure room Describe how the observed security system configurations verified that:
Modified
p. 193 → 187
• The intrusion-detection system(s) is automatically activated every time all authorized personnel have exited the secure area.
• The intrusion-detection system(s) is automatically activated every time all authorized personnel have exited the secure area <Report Findings Here> 32-3.3.b Observe the IDS and alarms function correctly by:
Modified
p. 193 → 187
• Having all but one authorized person who badged or otherwise authenticated into the system badge out and exit.
• Having all but one authorized person who badged or otherwise authenticated into the system badge out and exit Describe how observing all authorized personnel who badged or otherwise authenticated into the area exit and one person remain behind even though they have badged out verified that IDS and alarms function correctly:
Modified
p. 194 → 188
Documented security policies and procedures reviewed:
Documented security policies and procedures examined:
Modified
p. 195 → 189
32-5 Inspect uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems, including intrusion-detection systems, are powered through the UPS.
32-5 Examine uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems, including intrusion-detection systems, are powered through the UPS.
Modified
p. 195 → 189
Documented alarm events reviewed:
Documented alarm events examined:
Modified
p. 195 → 189
<Report Findings Here> 32-6.1.b Determine who is authorized to sign off on alarm events.
<Report Findings Here> 32-6.1.b Observe who is authorized to sign off on alarm events. Identify the P2PE Assessor who determined who is authorized to sign off on alarm events:
Modified
p. 195 → 189
<Report Findings Here> Alarm event records reviewed: <Report Findings Here>
<Report Findings Here> Alarm event records examined: <Report Findings Here>
Modified
p. 196 → 190
<Report Findings Here> 32-6.2.b Conduct a test to verify the mechanisms work appropriately.
<Report Findings Here> 32-6.2.b Test to verify the mechanisms work appropriately. Describe the testing performed that verified the mechanisms work appropriately:
Modified
p. 196 → 190
Sample of alarm events reviewed:
Sample of alarm events examined:
Modified
p. 196 → 190
<Report Findings Here> 32-6.3.c Conduct a test to verify the appropriate response occurs.
<Report Findings Here> 32-6.3.c Test to verify the appropriate response occurs. Describe the testing performed that verified the appropriate response occurs:
Modified
p. 197 → 191
32-7.a Examine documented procedures to verify that mechanisms are defined (may be automated or manual) for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems to ensure accuracy of logs.
32-7.a Examine documented procedures to verify that mechanisms are defined (may be automated or manual) for synchronizing the time and date stamps of the access, intrusion- detection, and monitoring (camera) systems to ensure accuracy of logs.
Modified
p. 197 → 191
Describe how the observed system configurations for access, intrusiondetection, and monitoring (camera) systems verified that time and date stamps are synchronized:
Describe how the observed system configurations for access, intrusion detection, and monitoring (camera) systems verified that time and date stamps are synchronized:
Modified
p. 197 → 191
Sample of logs from the access, intrusion-detection, and monitoring (camera) systems reviewed:
Sample of logs from the access, intrusion-detection, and monitoring (camera) systems examined:
Modified
p. 198 → 192
<Report Findings Here> 32-8.2 The KIF must implement mutually authenticated channels for communication between distributed KIF functions•e.g., between a host used to generate keys and a host used to distribute keys.
<Report Findings Here> 32-8.2 The KIF must implement mutually authenticated channels for communication between distributed KIF functions• e.g., between a host used to generate keys and a host used to distribute keys.
Removed
p. 200
• When a KLD is used as an intermediate device to establish keys between POI devices and a KIF HSM, it is not possible to insert an unauthorized SCD into the flow without detection.
Modified
p. 200 → 194
• POI devices must validate authentication credentials of KDHs prior to any key transport, exchange, or establishment with that device.
• POI devices must validate authentication credentials of KDHs prior to any key transport, exchange, or establishment with that device
Modified
p. 200 → 194
• KIFs must validate authentication credentials of a POI device prior to any key transport, exchange, or establishment with that device.
• KIFs must validate authentication credentials of a POI device prior to any key transport, exchange, or establishment with that device
Modified
p. 200 → 194
• When a KLD is used as an intermediate device to establish keys between POI devices and a KIF HSM it must not be possible to insert an unauthorized SCD into the flow without detection.
• When a KLD is used as an intermediate device to establish keys between POI devices and a KIF HSM, it is not possible to insert an unauthorized SCD into the flow without detection Responsible personnel interviewed:
Modified
p. 200 → 194
32-8.6 Interview responsible personnel and observe processes for establishment of enciphered secret or private keys between sending and receiving devices to verify:
• When a KLD is used as an intermediate device to establish keys between POI devices and a KIF HSM it must not be possible to insert an unauthorized SCD into the flow without detection 32-8.6 Interview responsible personnel and observe processes for establishment of enciphered secret or private keys between sending and receiving devices to verify:
Modified
p. 200 → 194
• KIFs validate authentication credentials of a POI device prior to any key transport, exchange, or establishment with that device.
• KIFs validate authentication credentials of a POI device prior to any key transport, exchange, or establishment with that device
Modified
p. 200 → 194
• POI devices validate authentication credentials of KLDs prior to any key transport, exchange, or establishment with that device.
• POI devices validate authentication credentials of KLDs prior to any key transport, exchange, or establishment with that device
Modified
p. 200 → 194
• POI devices validate authentication credentials of KLDs prior to any key transport, exchange, or establishment with that device.
• POI devices validate authentication credentials of KLDs prior to any key transport, exchange, or establishment with that device
Modified
p. 200 → 194
• KIFs validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
• KIFs validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device
Modified
p. 200 → 194
• When a KLD is used as an intermediate device to establish keys between POIs and a KIF HSM, it is not possible to insert an unauthorized SCD into the flow without detection.
• When a KLD is used as an intermediate device to establish keys between POIs and a KIF HSM, it is not possible to insert an unauthorized SCD into the flow without detection <Report Findings Here> 32-8.7 Mechanisms must exist to prevent a non-authorized host from injecting keys into POI devices or an unauthorized POI device from establishing a key with a legitimate KIF component.
Modified
p. 201 → 195
• Effective 1 January 2024, the injection of clear-text secret or private keying material shall not be allowed for entities engaged in key injection on behalf of others. This applies to new deployments of POI v5 and higher devices. Subsequent to that date, only encrypted key injection shall be allowed for POI v5 and higher devices.
• Effective 1 January 2024, the injection of cleartext secret or private keying material shall not be allowed for entities engaged in key injection on behalf of others. This applies to new deployments of POI v5 and higher devices. Subsequent to that date, only encrypted key injection shall be allowed for POI v5 and higher devices. (past)
Modified
p. 201 → 195
• Effective 1 January 2026, the same restriction applies to entities engaged in key injection of devices for which they are the processors. Note: This does not apply to key components entered into the keypad of a secure cryptographic device, such as a device approved against the PCI PTS POI Security Requirements. It does apply to all other methods of loading of clear-text keying material for POI v5 and higher devices.
• Effective 1 January 2026, the same restriction applies to entities engaged in key injection of devices for which they are the processors Note: This does not apply to key components entered into the keypad of a secure cryptographic device, such as a device approved against the PCI PTS POI Security Requirements. It does apply to all other methods of loading of cleartext keying material for PTS POI v5 and higher devices.
Modified
p. 201 → 195
Note: In KIF environments where Level 1 and Level 2 physical barrier controls are in place and confirmed, the secure room may be implemented within a “caged” environment. A caged environment is an enclosed secure room that meets the criteria of Requirement 32 but is not made of solid walls. Refer to applicable requirements within this Domain for additional information on Level 1 and Level 2 physical barrier controls. All other criteria stated in Requirements 13-9 and 32-9 relating to …
Note: In KIF environments where Level 1 and Level 2 physical barrier controls are in place and confirmed, the secure room may be implemented within a “caged” environment. A caged environment is an enclosed secure room that meets the criteria of Requirement 32 but is not made of solid walls. Refer to applicable requirements within this Domain for additional information on Level 1 and Level 2 physical barrier controls. All other criteria stated in and 32-9 relating to cleartext secret …
Modified
p. 204 → 198
32-9.9.a Inspect location of the CCTV server and digital- storage to verify they are located in a secure location that is separate from the key-injection secure room.
32-9.9.a Inspect location of the CCTV server and digital-storage to verify they are located in a secure location that is separate from the key-injection secure room.
Modified
p. 204 → 198
Identify the P2PE Assessor who confirms the location of the CCTV server and digital-storage are located in a secure area that is separate from the key-injection area:
Identify the P2PE Assessor who confirms the location of the CCTV server and digital-storage are located in a secure area that is separate from the key- injection area:
Modified
p. 204 → 198
Identify the P2PE Assessor who identified all personnel with access to the CCTV server/storage area and the key- injection area, and who confrms that personnel with access to the keyinjection area do not have access to the CCTV server/storage area:
Identify the P2PE Assessor who identified all personnel with access to the CCTV server/storage area and the key- injection area, and who confrms that personnel with access to the key injection area do not have access to the CCTV server/storage area:
Removed
p. 205
• The equipment used for key injection.
Modified
p. 205 → 199
• SCDs, both pre and post key injection,
• SCDs, both pre and post key injection
Modified
p. 205 → 199
Sample of recordings reviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that CCTV cameras are positioned to monitor the entrance door, SCDs (both pre and post key injection), any safes that are present, and the equipment used for key injection:
• The equipment used for key injection Sample of recordings reviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that CCTV cameras are positioned to monitor the entrance door, SCDs (both pre and post key injection), any safes that are present, and the equipment used for key injection:
Modified
p. 206 → 200
<Report Findings Here> 33-1.b Verify that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.
<Report Findings Here> 33-1.b Examine/observe that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.
Modified
p. 206 → 200
Documented records reviewed: <Report Findings Here>
Documented records examined: <Report Findings Here>
Removed
p. 207
Documented key-management procedures reviewed:
<Report Findings Here> 5A-1.2.b Through observation of key-management operations and inspection of SCDs, verify that crypto-periods are defined for every type of key in use.
SCDs inspected: <Report Findings Here> Describe how the observed key-management operations and the inspected SCDs verified that crypto-periods are defined for every type of key in use:
<Report Findings Here> 5A-1.2.b Through observation of key-management operations and inspection of SCDs, verify that crypto-periods are defined for every type of key in use.
SCDs inspected: <Report Findings Here> Describe how the observed key-management operations and the inspected SCDs verified that crypto-periods are defined for every type of key in use:
Modified
p. 207 → 201
• Crypto-periods are defined for every type of key in use.
• Crypto-periods are defined for every type of key in use
Modified
p. 207 → 201
• Crypto-periods are based on industry best practices and guidelines (e.g., NIST Special Publication 800-57).
• Crypto-periods are based on industry best practices and guidelines (e.g., NIST Special Publication 800-57)
Modified
p. 207 → 201
• A process/methodology is in place to determine when the crypto-period is reached for each cryptographic key.
• A process/methodology is in place to determine when the crypto-period is reached for each cryptographic key
Modified
p. 207 → 201
• Cryptographic key changes are implemented whenever a key reaches the end of its defined crypto-period.
• Cryptographic key changes are implemented whenever a key reaches the end of its defined crypto-period Documented key-management procedures examined:
Modified
p. 207 → 201
<Report Findings Here>
<Report Findings Here> 5A-1.2.b REMOVED
Modified
p. 208 → 202
5A-1.3.a Verify documentation exists describing the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key- management solution.
5A-1.3.a Examine documentation to verify it describes the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key- management solution.
Modified
p. 208 → 202
Documentation reviewed: <Report Findings Here> 5A-1.3.b Observe architecture and key-management operations to verify that the documentation reviewed in 5A- 1.3.a is demonstrably in use for all key-management processes.
Documentation examined: <Report Findings Here> 5A-1.3.b Observe architecture and key-management operations to verify that the documentation reviewed in 5A-1.3.a is demonstrably in use for all key-management processes.
Modified
p. 210 → 204
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documented key-management policies and procedures reviewed:
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documented key-management policies and procedures examined:
Modified
p. 210 → 204
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here>
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 5H-1 Not used in KMS
Removed
p. 211
• Type of key(s) injected
Removed
p. 211
• 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.
5I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel to confirm that the following processes are documented and implemented:
• Types/models of POIs and/or HSMs for which keys have been injected
• Type of key injected
5I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel to confirm that the following processes are documented and implemented:
• Types/models of POIs and/or HSMs for which keys have been injected
• Type of key injected
Modified
p. 211 → 205
Note: This section (5I-1.1) is ONLY applicable for P2PE component providers undergoing an assessment for subsequent PCI listing of the component provider’s Key Management Services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include key-management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).
Note: This section (5I-1.1) is ONLY applicable for P2PE component providers undergoing an assessment for subsequent PCI listing of the component provider’s Encryption Management Services. This section is not applicable to, and does not need to be completed by, P2PE solution providers.
Modified
p. 211 → 205
5I-1.1 Track status of the deployed key-management services for POIs and HSMs, and provide reports to solution provider annually and upon significant changes, including at least the following:
5I-1.1 Track status of the deployed key-management services for PTS POI devices and HSMs, and provide reports to solution provider annually and upon significant changes, including at least the following:
Modified
p. 211 → 205
• Details of any known or suspected compromised keys, per 22-1 Documented component provider procedures reviewed:
• For each type/model of POI and/or HSM: o Number of devices o Type of key injected o Key-distribution method
• Details of any known or suspected compromised keys, per 22-1 Documented component provider procedures examined:
• Details of any known or suspected compromised keys, per 22-1 Documented component provider procedures examined:
Removed
p. 212
• Type of key injected
• Number of POI devices
• Number of POI devices
Modified
p. 212 → 206
• Details of any known or suspected compromised keys, per 22-1 Solution provider reports reviewed:
• For each type/model of POI: o Number of POI devices o Type of key injected o Key-distribution method
• Details of any known or suspected compromised keys, per 22-1 Solution provider reports reviewed:
• Details of any known or suspected compromised keys, per 22-1 Solution provider reports reviewed: