Document Comparison
P2PE_RT_Component_v2.0.pdf
→
P2PE_v2.0_r1.2_Component_P-ROV_Template.pdf
63% similar
254 → 254
Pages
120148 → 120799
Words
668
Content Changes
From Revision History
- March 2020 For use with P2PE v2.0, Revision 1.2
- March 2020 © 2020 PCI Security Standards Council, LLC. All Rights Reserved. Page iii
Content Changes
668 content changes. 299 administrative changes (dates, page numbers) hidden.
Added
p. 2
Clarify domain applicability for CA/RAs.
Added
p. 7
• 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.
• 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.
Added
p. 17
• Key Distribution / Loading / Injection onto POI devices
• Other Key Distribution / Loading / Injection activities
• Other Key Distribution / Loading / Injection activities
Added
p. 23
• Disabling all capture mechanisms that are not SRED validated, or
• Link Layer Protocols
• Confirmed per 1A-1.1 as a PTS-approved device(s)
• Confirmed per 1A-1.1 as a PTS-approved device(s)
• Only view transaction-related data
• Cannot view or access cryptographic keys
• Cannot view or access clear-text PAN
• Cannot view or access SAD.
• The solution provider must document which payment application(s) facilitates printing of PANs for merchants.
• All personnel with access to devices are authorized by management.
• The list of authorized personnel is reviewed at least annually.
• Link Layer Protocols
• Confirmed per 1A-1.1 as a PTS-approved device(s)
• Confirmed per 1A-1.1 as a PTS-approved device(s)
• Only view transaction-related data
• Cannot view or access cryptographic keys
• Cannot view or access clear-text PAN
• Cannot view or access SAD.
• The solution provider must document which payment application(s) facilitates printing of PANs for merchants.
• All personnel with access to devices are authorized by management.
• The list of authorized personnel is reviewed at least annually.
Added
p. 30
• Integrity check of update
• Integrity checks of update
• The integrity of the update is checked
• The inventory includes all POI device system builds.
• The inventory includes all POI device system builds.
• At least annually and
• At least annually and
• PAN and/or SAD is never output to merchant environments
• Collection of PAN and/or SAD only when needed to solve a specific
• Storage of such data in a specific, known location with limited access
• Collection of only a limited amount of data needed to solve a specific
• Encryption of PAN and/or SAD while stored
• Secure deletion of such data immediately after use Documented solution provider’s procedures for troubleshooting customer problems reviewed:
• Integrity checks of update
• The integrity of the update is checked
• The inventory includes all POI device system builds.
• The inventory includes all POI device system builds.
• At least annually and
• At least annually and
• PAN and/or SAD is never output to merchant environments
• Collection of PAN and/or SAD only when needed to solve a specific
• Storage of such data in a specific, known location with limited access
• Collection of only a limited amount of data needed to solve a specific
• Encryption of PAN and/or SAD while stored
• Secure deletion of such data immediately after use Documented solution provider’s procedures for troubleshooting customer problems reviewed:
Added
p. 34
• Documentation for all new installations and updates to whitelist functionality that includes the following: - Description and justification for the functionality - The identity of the authorized person who approved the new installation or updated functionality prior to release - Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Documented policies and procedures reviewed:
• Cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
• Coverage for both new installations and updates to such functionality.
• Coverage for both new installations and updates to such functionality.
• Description and justification for the functionality.
• Description and justification for the functionality.
• The identity of the person who approved the new installation or update prior to release.
• Is cryptographically authenticated by the POI device’s firmware.
• Requires dual control for the application-signing process.
• Authentication of the application by the POI device’s …
• Cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
• Coverage for both new installations and updates to such functionality.
• Coverage for both new installations and updates to such functionality.
• Description and justification for the functionality.
• Description and justification for the functionality.
• The identity of the person who approved the new installation or update prior to release.
• Is cryptographically authenticated by the POI device’s firmware.
• Requires dual control for the application-signing process.
• Authentication of the application by the POI device’s …
Added
p. 39
• Number of devices deployed and any change in numbers since last report.
Added
p. 39
• Number of devices deployed and change since last report.
• Number of devices deployed and changed since last report.
• Number of devices deployed and changed since last report.
Added
p. 46
• FIPS140-2 Level 3 (overall) or higher certified, or
• Device firmware version number
• Device firmware version number
• Description of why the HSM is operated in non-FIPS mode
• Description of why the HSM is operated in non-FIPS mode
• A statement that nothing has been
• Device firmware version number
• Device firmware version number
• Description of why the HSM is operated in non-FIPS mode
• Description of why the HSM is operated in non-FIPS mode
• A statement that nothing has been
Added
p. 48
• Console and non-console administration
Added
p. 48
• Use of HSM commands
• Assigning administrative roles and responsibilities only to specific, authorized personnel
• Assigning administrative roles and responsibilities only to specific, authorized personnel
Added
p. 49
• Use of HSM commands Documented procedures reviewed:
Added
p. 52
• Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
• Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
• Cryptographic authentication by the HSM
• Cryptographic authentication by the HSM
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
• Documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Documented policies and procedures reviewed:
• Changes to the applications
• Changes to the applications
• Changes to the firmware
• Changes to the firmware
• Changes to any security-sensitive configurations Describe how system configurations and correlating log files verified …
• Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
• Cryptographic authentication by the HSM
• Cryptographic authentication by the HSM
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
• Documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Documented policies and procedures reviewed:
• Changes to the applications
• Changes to the applications
• Changes to the firmware
• Changes to the firmware
• Changes to any security-sensitive configurations Describe how system configurations and correlating log files verified …
Added
p. 54
• Unauthorized logical alterations (e.g., configurations, access controls)
• Unauthorized logical alterations (e.g., configurations, access controls)
• Unauthorized use of sensitive functions (e.g., key-management functions)
• Unauthorized use of sensitive functions (e.g., key-management functions)
• Unauthorized logical alterations (e.g., configurations, access controls)
• Unauthorized use of sensitive functions (e.g., key-management functions)
• Unauthorized use of sensitive functions (e.g., key-management functions)
Added
p. 54
• Unauthorized use of the HSM API 5C-1.2.a Examine documented procedures to verify mechanisms are defined to detect and respond to potential security incidents, including:
• Unauthorized use of the HSM API Documented procedures reviewed:
• Unauthorized logical alterations (configuration, access controls)
• Unauthorized use of sensitive functions (e.g., key management functions)
• Identification of affected device(s), including make, model, and serial number
• Identification of affected merchant, including specific sites/locations if applicable
• Unauthorized use of the HSM API Documented procedures reviewed:
• Unauthorized logical alterations (configuration, access controls)
• Unauthorized use of sensitive functions (e.g., key management functions)
• Identification of affected device(s), including make, model, and serial number
• Identification of affected merchant, including specific sites/locations if applicable
Added
p. 56
• Details of whether any account data was transmitted from the POI device during any identified time that encryption was malfunctioning or disabled
• Identification of affected device(s), including make, model, and serial number
• Identification of affected merchant, including specific sites/locations if applicable
• Identification of affected device(s), including make, model, and serial number
• Identification of affected merchant, including specific sites/locations if applicable
• Identification of affected device(s), including make, model, and serial number
• Identification of affected merchant, including specific sites/locations if applicable
• Identification of affected device(s), including make, model, and serial number
• Identification of affected merchant, including specific sites/locations if applicable
Added
p. 59
• Testing integrity of firmware.
• Testing integrity of software/firmware.
• Testing integrity of software/firmware.
• Testing integrity of software/firmware.
• Testing integrity of software/firmware.
Added
p. 60
• Failure of a system self-test, as described in Requirements 5D-1.6 and 5D-1.7
• While in an error state, as described in Requirement 5D-1.8
• During self-tests, as described in Requirements 5D-1.6 and 5D-1.7.
• While in an error state, as described in Requirement 5D-1.8
• During self-tests, as described in Requirements 5D-1.6 and 5D-1.7.
Added
p. 64
• Memory ‘swap/page’ files must be securely
• Memory ‘swap/page’ files must be securely
• Memory ‘swap/page’ files must be securely
Added
p. 65
• Consist of a combination of numeric, alphabetic, and special characters, or
• Consist of a combination of numeric, alphabetic, and special characters, or
• Have equivalent strength/complexity.
• Have equivalent strength/complexity.
• Host System administrator role
• Cryptographic administrator role
• Host System security role
• Using a formal change-control procedure.
• Meet all applicable PCI DSS requirements.
• Meet all applicable PCI DSS requirements.
• Logs must be retained for a minimum of three years.
• Log reviews must be documented.
• Logs must include but not be limited to:
• Logs are retained for a minimum of three years.
• Log reviews are documented.
• Log reviews are documented.
• Logs include at a minimum:
• Logs include at a minimum:
• Logs are regularly reviewed.
• Consist of a combination of numeric, alphabetic, and special characters, or
• Have equivalent strength/complexity.
• Have equivalent strength/complexity.
• Host System administrator role
• Cryptographic administrator role
• Host System security role
• Using a formal change-control procedure.
• Meet all applicable PCI DSS requirements.
• Meet all applicable PCI DSS requirements.
• Logs must be retained for a minimum of three years.
• Log reviews must be documented.
• Logs must include but not be limited to:
• Logs are retained for a minimum of three years.
• Log reviews are documented.
• Log reviews are documented.
• Logs include at a minimum:
• Logs include at a minimum:
• Logs are regularly reviewed.
Added
p. 75
• Provides continuous (24/7) monitoring of the secure room.
• Provides continuous (24/7) monitoring of the secure room.
• A door that is contact monitored and fitted with automatic closing or locking devices.
• Provides continuous (24/7) monitoring of the secure room.
• A door that is contact monitored and fitted with automatic closing or locking devices.
Added
p. 78
• Number of HSMs deployed and any change in numbers since last report
Added
p. 78
• Providing reports annually and upon significant changes
• Number of HSMs deployed and description of any changes since last
• Number of HSMs deployed and description of any changes since last
• Details of any suspicious activity that occurred, per 5C-1.2 Component provider’s documented procedures reviewed:
• Addition and/or removal of HSM types.
• Critical infrastructure changes, including to the PCI DSS environment
• Changes to PCI DSS compliance status Note that adding or removing HSM types 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.
• Critical infrastructure changes, including to the PCI DSS environment
• Changes to PCI DSS compliance status
• Changes to PCI DSS compliance status
• Additions and/or removal of HSM types.
• Number of HSMs deployed and description of any changes since last
• Number of HSMs deployed and description of any changes since last
• Details of any suspicious activity that occurred, per 5C-1.2 Component provider’s documented procedures reviewed:
• Addition and/or removal of HSM types.
• Critical infrastructure changes, including to the PCI DSS environment
• Changes to PCI DSS compliance status Note that adding or removing HSM types 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.
• Critical infrastructure changes, including to the PCI DSS environment
• Changes to PCI DSS compliance status
• Changes to PCI DSS compliance status
• Additions and/or removal of HSM types.
Added
p. 84
Approved Hardware Approved Firmware
Note: Domain 6 requirements that additionally apply when performing CA/RA assessments are identified by “[Applies to CA/RA assessments]”.
• Crypto-periods are defined for every type of key in use.
• Key type/description
• Description of level in the key hierarchy
• Purpose/function of the key (including type of devices using key)
• Key-creation method
• Key-distribution method (e.g., manually via courier, remote key distribution)
• Type of media used for key storage
Note: Domain 6 requirements that additionally apply when performing CA/RA assessments are identified by “[Applies to CA/RA assessments]”.
• Crypto-periods are defined for every type of key in use.
• Key type/description
• Description of level in the key hierarchy
• Purpose/function of the key (including type of devices using key)
• Key-creation method
• Key-distribution method (e.g., manually via courier, remote key distribution)
• Type of media used for key storage
Added
p. 87
• An approved key-generation function of a PCI
•approved HSM or POI device;
• An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM; or
•approved HSM or POI device;
• An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM; or
Added
p. 90
<Report Findings Here> 6B-2.1.4.b Observe key-generation set-up processes for all key types to verify that key-generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering.
• Tampering can be visually detected. Printers used for this purpose must not be used for other purposes. [Applies to CA/RA assessments] 6B-2.3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed immediately after printing such that:
• Tampering can be visually detected. Printers used for this purpose must not be used for other purposes. [Applies to CA/RA assessments] 6B-2.3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed immediately after printing such that:
Added
p. 91
• Tampering can be visually detected.
• Printing material, including ribbons and paper waste
• Memory storage of a key-loading device, after loading the key to a different device or system
• Generated by the device that will use the key pair; or
• Printing material, including ribbons and paper waste
• Memory storage of a key-loading device, after loading the key to a different device or system
• Generated by the device that will use the key pair; or
Added
p. 93
• Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
• Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
• Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
Added
p. 93
• Writing key or component values in procedure manual Describe how the key-management processes observed verified that key components are not transmitted across insecure channels, including but not limited to:
Added
p. 95
<Report Findings Here> 6C-1.1.b If key components are ever transmitted in clear-text using pre- numbered, tamper-evident, authenticable mailers, perform the following:
• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A
• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A
Added
p. 97
• Using a MAC (message authentication code) created using the algorithm defined in ISO 16609
• Use of public-key certificates created by a trusted CA that meets the requirements of Annex A
• Under the continuous supervision of a person with authorized access to this component, or
• Use of public-key certificates created by a trusted CA that meets the requirements of Annex A
• Under the continuous supervision of a person with authorized access to this component, or
Added
p. 100
• Place key components into pre-numbered tamper-evident, authenticable packaging for transmittal.
• Check tamper-evident packaging upon receipt for signs of tamper prior to opening tamper-evident authenticable packaging containing key components.
• Check the serial number of the tamper-evident packaging upon receipt of a component package. [Applies to CA/RA assessments] 6C-2.4.a Verify that a list(s) of key custodians authorized to perform the following activities is defined and documented:
• 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.
• A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength.
• TDEA keys shall not be used to protect AES keys.
• TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
- TDEA keys used for encrypting keys must be at least triple-length keys (have …
• Check tamper-evident packaging upon receipt for signs of tamper prior to opening tamper-evident authenticable packaging containing key components.
• Check the serial number of the tamper-evident packaging upon receipt of a component package. [Applies to CA/RA assessments] 6C-2.4.a Verify that a list(s) of key custodians authorized to perform the following activities is defined and documented:
• 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.
• A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength.
• TDEA keys shall not be used to protect AES keys.
• TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
- TDEA keys used for encrypting keys must be at least triple-length keys (have …
Added
p. 104
• Asymmetric techniques
• Use public and private key lengths that are in accordance with Annex C for the algorithm in question.
• Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of clear-text key components.
• There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys.
• The SCD must be inspected prior to use to ensure that it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying material.
• SCDs must be inspected to detect evidence of monitoring and to ensure dual control procedures are not circumvented during key loading.
• An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are uniquely identified by …
• Use public and private key lengths that are in accordance with Annex C for the algorithm in question.
• Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of clear-text key components.
• There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys.
• The SCD must be inspected prior to use to ensure that it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying material.
• SCDs must be inspected to detect evidence of monitoring and to ensure dual control procedures are not circumvented during key loading.
• An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are uniquely identified by …
Added
p. 112
Documented procedures reviewed: <Report Findings Here> 6D-4.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.
• Be within a certificate as defined in Annex A, or
• Be within a PKCS#10, or
• Be within an SCD, or
• Be unique to those two entities or logically separate systems and
• To create digital signatures or to perform decryption operations.
• To perform encryption operations or to verify digital signatures.
• Keys used for production must never be present or used in a test/development system, and
• Prior to reuse for production purposes the HSM is returned to factory state.
• Be within a certificate as defined in Annex A, or
• Be within a PKCS#10, or
• Be within an SCD, or
• Be unique to those two entities or logically separate systems and
• To create digital signatures or to perform decryption operations.
• To perform encryption operations or to verify digital signatures.
• Keys used for production must never be present or used in a test/development system, and
• Prior to reuse for production purposes the HSM is returned to factory state.
Added
p. 117
• Known only to a single POI device, and
Documented procedures reviewed: <Report Findings Here> 6E-4.1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POI devices to verify that unique keys are generated and used for each POI device.
• Different BDKs for each financial institution
• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model
• At least two separate key shares or full-length components
• Encrypted with a key of equal or greater strength as delineated in Annex C
• Contained within a secure cryptographic device Note for hybrid decryption solutions: Clear-text Data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data. [Applies to CA/RA assessments]
Documented procedures reviewed: <Report Findings Here> 6E-4.1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POI devices to verify that unique keys are generated and used for each POI device.
• Different BDKs for each financial institution
• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model
• At least two separate key shares or full-length components
• Encrypted with a key of equal or greater strength as delineated in Annex C
• Contained within a secure cryptographic device Note for hybrid decryption solutions: Clear-text Data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data. [Applies to CA/RA assessments]
Added
p. 123
• Identification of key personnel
• A damage assessment including, where necessary, the engagement of outside consultants
• Missing secure cryptographic devices
• Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries
• Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate
• Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation
• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions 6F-2.1.5 Interview responsible personnel and review documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
• replaced by a new key.
Documented procedures reviewed: <Report Findings Here> 6F-4.3.b Observe key-conveyance/loading …
• A damage assessment including, where necessary, the engagement of outside consultants
• Missing secure cryptographic devices
• Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries
• Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate
• Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation
• Host System tamper-detection mechanism has been activated, for hybrid decryption solutions 6F-2.1.5 Interview responsible personnel and review documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
• replaced by a new key.
Documented procedures reviewed: <Report Findings Here> 6F-4.3.b Observe key-conveyance/loading …
Added
p. 130
• Tamper-evident package number (if applicable) [Applies to CA/RA assessments] 6F-6.1.a Review log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:
• Key component identifier
• Key component identifier
• Key component identifier
• Key component identifier
Added
p. 131
• All requirements applicable for the original keys also apply to any backup copies of keys and their components. [Applies to CA/RA assessments] 6F-7.2 Interview responsible personnel and observe backup processes to verify the following:
Added
p. 131
• Management of personnel changes, including revocation of access control and other privileges when personnel move [Applies to CA/RA assessments]
Added
p. 139
• To enable application-signing functions;
• To place the device into a state that allows for the input or output of clear-text key components;
• For all access to key-loading devices (KLDs) and authenticated application-signing devices.
• To enable application-signing functions;
• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;
• Locked in a secure cabinet and/or sealed in tamper-evident packaging, or
• A one-way derivation process must be used.
• A one-way derivation process must be used.
• The DDK must never be generated as a variant of the HSM master file key.
• The DDK must never be generated as a variant of the HSM master file key.
• A one-way derivation process is used.
• A one-way derivation process is used.
• The DDK is never generated as a variant of the HSM master file key.
• The DDK is never generated as a variant of the HSM master file key.
• To place the device into a state that allows for the input or output of clear-text key components;
• For all access to key-loading devices (KLDs) and authenticated application-signing devices.
• To enable application-signing functions;
• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;
• Locked in a secure cabinet and/or sealed in tamper-evident packaging, or
• A one-way derivation process must be used.
• A one-way derivation process must be used.
• The DDK must never be generated as a variant of the HSM master file key.
• The DDK must never be generated as a variant of the HSM master file key.
• A one-way derivation process is used.
• A one-way derivation process is used.
• The DDK is never generated as a variant of the HSM master file key.
• The DDK is never generated as a variant of the HSM master file key.
Added
p. 145
• For each type/model of POI:
Added
p. 148
• System implementations must be designed and implemented to prevent replay attacks
•e.g., through the use of random nonces. 6D-4.4 Examine system and process documentation to verify that key- establishment and distribution procedures are designed such that:
• New certificate issue request
• Certificate replacement request
•e.g., through the use of random nonces. 6D-4.4 Examine system and process documentation to verify that key- establishment and distribution procedures are designed such that:
• New certificate issue request
• Certificate replacement request
Added
p. 150
• Within a secure cryptographic device that meets applicable PCI requirements for such a device,
• Encrypted using an algorithm and key size of equivalent or greater strength, or
• Encrypted using an algorithm and key size of equivalent or greater strength, or
Added
p. 152
Note: Domain 6: P2PE Cryptographic Key Operations and Device Management requirements that apply when performing CA/RA assessments are identified by “[Applies to CA/RA assessments]” in the main body of Domain 6.
• Prior to reuse for production purposes the HSM is returned to factory state.
• New certificate issue request
• Certificate replacement request
• Certificate signature keys,
• Status checking (e.g., Certificate Revocation Lists) signature keys, or
• Subordinate entity certificate requests,
• Certificate status checking, and/or
• Within a secure cryptographic device that meets applicable PCI requirements for such a device,
• Encrypted using an algorithm and key size of equivalent or greater strength, or
• Notify affected entities.
• Notify affected entities.
• Prior to reuse for production purposes the HSM is returned to factory state.
• New certificate issue request
• Certificate replacement request
• Certificate signature keys,
• Status checking (e.g., Certificate Revocation Lists) signature keys, or
• Subordinate entity certificate requests,
• Certificate status checking, and/or
• Within a secure cryptographic device that meets applicable PCI requirements for such a device,
• Encrypted using an algorithm and key size of equivalent or greater strength, or
• Notify affected entities.
• Notify affected entities.
Added
p. 157
• The CA will notify any superior CAs.
• The CA will notify any subordinate CAs.
• The CA notifies any superior CAs.
• The CA notifies any subordinate CAs.
• Root and subordinate CAs have a minimum RSA 2048 bits or equivalent;
• The network must only be used for certificate issuance and/or revocation.
• The CA will notify any subordinate CAs.
• The CA notifies any superior CAs.
• The CA notifies any subordinate CAs.
• Root and subordinate CAs have a minimum RSA 2048 bits or equivalent;
• The network must only be used for certificate issuance and/or revocation.
Added
p. 160
• Separation of duties to prevent one person from maliciously using a CA system without detection
• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) Responsible personnel interviewed: <Report Findings Here> Describe how the CA operations observed verified:
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, telnet, ftp, etc.) must be removed or disabled.
• Unnecessary ports must also be disabled.
• Unnecessary ports must also be disabled.
• Documentation must exist to support the enablement of all active services and ports.
• Unnecessary ports are disabled.
• Unnecessary ports are disabled.
• There is documentation to support all active services and ports.
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, etc., commands in UNIX) are removed or disabled.
• The identity of the person authorizing the operation
• The identity of the person authorizing the operation
• The identities …
• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) Responsible personnel interviewed: <Report Findings Here> Describe how the CA operations observed verified:
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, telnet, ftp, etc.) must be removed or disabled.
• Unnecessary ports must also be disabled.
• Unnecessary ports must also be disabled.
• Documentation must exist to support the enablement of all active services and ports.
• Unnecessary ports are disabled.
• Unnecessary ports are disabled.
• There is documentation to support all active services and ports.
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, etc., commands in UNIX) are removed or disabled.
• The identity of the person authorizing the operation
• The identity of the person authorizing the operation
• The identities …
Added
p. 163
• Identity of the entity and/or user that caused the event,
• Success or failure of the event.
• Success or failure of the event.
• Success or failure of the event.
• Success or failure of the event.
Added
p. 164
• Not accept traffic on its external interfaces that appears to be coming from internal network addresses.
• Generic user IDs and accounts are disabled or removed.
• Generic user IDs and accounts are disabled or removed.
• CA operations must be dedicated to certificate issuance and management.
• The CPS must be consistent with the requirements described within this document.
• The CA shall operate in accordance with its CPS. Note: This may take the form of a declaration by the CA operator of the details of its trustworthy system and the practices it employs in its operations and in support of the issuance of certificates. A CPS may take the form of either a specific, single document or a collection of specific documents. The CPS must be consistent with the requirements described within this document. The CA shall operate in accordance with its CPS. 6F-8.3.a Examine documented certification practice statement (CPS) to verify …
• Generic user IDs and accounts are disabled or removed.
• Generic user IDs and accounts are disabled or removed.
• CA operations must be dedicated to certificate issuance and management.
• The CPS must be consistent with the requirements described within this document.
• The CA shall operate in accordance with its CPS. Note: This may take the form of a declaration by the CA operator of the details of its trustworthy system and the practices it employs in its operations and in support of the issuance of certificates. A CPS may take the form of either a specific, single document or a collection of specific documents. The CPS must be consistent with the requirements described within this document. The CA shall operate in accordance with its CPS. 6F-8.3.a Examine documented certification practice statement (CPS) to verify …
Added
p. 174
• Granting, revocation, and review of access privileges by an authorized officer of the entity operating the CA
• Have successfully completed a background security check.
• Have successfully completed a background security check.
• The system records to time-lapse VCRs or similar mechanisms.
• The system records to time-lapse VCRs or similar mechanisms.
• A minimum of five frames are recorded every three seconds.
• Backups are securely stored in a separate location from the primary.
• Backups are securely stored in a separate location from the primary.
• The intrusion-detection system(s) is connected to the alarm system.
• The intrusion-detection system(s) is connected to the alarm system.
• Unauthorized entry attempts
• Unauthorized entry attempts
• Have successfully completed a background security check.
• Have successfully completed a background security check.
• The system records to time-lapse VCRs or similar mechanisms.
• The system records to time-lapse VCRs or similar mechanisms.
• A minimum of five frames are recorded every three seconds.
• Backups are securely stored in a separate location from the primary.
• Backups are securely stored in a separate location from the primary.
• The intrusion-detection system(s) is connected to the alarm system.
• The intrusion-detection system(s) is connected to the alarm system.
• Unauthorized entry attempts
• Unauthorized entry attempts
Added
p. 181
• Reason for access or purpose of visit
• Reason for access or purpose of visit
• Reason for access or purpose of visit
Added
p. 188
• FIPS140-2 Level 3 or higher certified, or
Added
p. 189
• The PCI PTS or FIPS 140 Approval Number
• The PCI PTS or FIPS 140 Approval Number
• Maintain current documentation that describes or illustrates the architecture of the KIF, including all distributed KIF functionality.
• An approved key-generation function of a PCI-approved HSM or POI
• An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM
• An approved key-generation function of a PCI-approved HSM
• An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM or
• An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.
• An approved key-generation function of a PCI
•approved HSM
• An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM or
• An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 Certification letters/technical documentation reviewed:
• The PCI PTS or FIPS 140 Approval Number
• Maintain current documentation that describes or illustrates the architecture of the KIF, including all distributed KIF functionality.
• An approved key-generation function of a PCI-approved HSM or POI
• An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM
• An approved key-generation function of a PCI-approved HSM
• An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM or
• An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.
• An approved key-generation function of a PCI
•approved HSM
• An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM or
• An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 Certification letters/technical documentation reviewed:
Added
p. 194
• Printing material, including ribbons and paper waste
• Memory storage of a key-loading device, after loading the key to a different device or system
• Generated by the device that will use the key pair; or
• Writing key or component values in procedure manual Describe how the key-management processes observed verified that key components are not transmitted across insecure channels, including but not limited to:
• Faxing, e-mailing, or otherwise conveying clear-text keys or components
• Faxing, e-mailing, or otherwise conveying clear-text keys or components
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
• Memory storage of a key-loading device, after loading the key to a different device or system
• Generated by the device that will use the key pair; or
• Writing key or component values in procedure manual Describe how the key-management processes observed verified that key components are not transmitted across insecure channels, including but not limited to:
• Faxing, e-mailing, or otherwise conveying clear-text keys or components
• Faxing, e-mailing, or otherwise conveying clear-text keys or components
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
Added
p. 200
• Using a MAC (message authentication code) created using the algorithm defined in ISO 16609
• Under the continuous supervision of a person with authorized access to this component, or
• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A.
• Be within an SCD Note: Self-signed certificates must not be used as the sole method of authentication. 6C-1.4 For all methods used to convey public keys, perform the following:
• Locked in a security container (including tamper-evident, authenticable packaging) in such a way that unauthorized access to it would be detected, or
• Place key components into pre-numbered tamper-evident, authenticable packaging for transmittal.
• Check tamper-evident packaging upon receipt for signs of tamper prior to opening the tamper-evident, authenticable packaging containing key components.
• TDEA keys used for encrypting keys must be at least triple-length keys (have bit strength of 112 bits) …
• Under the continuous supervision of a person with authorized access to this component, or
• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A.
• Be within an SCD Note: Self-signed certificates must not be used as the sole method of authentication. 6C-1.4 For all methods used to convey public keys, perform the following:
• Locked in a security container (including tamper-evident, authenticable packaging) in such a way that unauthorized access to it would be detected, or
• Place key components into pre-numbered tamper-evident, authenticable packaging for transmittal.
• Check tamper-evident packaging upon receipt for signs of tamper prior to opening the tamper-evident, authenticable packaging containing key components.
• TDEA keys used for encrypting keys must be at least triple-length keys (have bit strength of 112 bits) …
Added
p. 213
• Standalone (i.e., without modems, not connected to a LAN or WAN, not capable of wireless connections, etc.);
• Dedicated to only the key-loading function (e.g., there must not be any other application software installed); and
• Dedicated to only key loading
• 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. 6D-2.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.
• Retained for a minimum of three years.
• The reviews are documented.
• …
• Dedicated to only the key-loading function (e.g., there must not be any other application software installed); and
• Dedicated to only key loading
• 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. 6D-2.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.
• Retained for a minimum of three years.
• The reviews are documented.
• …
Added
p. 231
• Identification of key personnel
• A damage assessment including, where necessary, the engagement of outside consultants
• Missing secure cryptographic devices
• Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries
• Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate
• Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities
• A damage assessment including, where necessary, the engagement of outside consultants
• Missing secure cryptographic devices
• Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries
• Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate
• Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities
Added
p. 236
• Ensure key custodians do not report to each other.
• Creation (including cloning) must require a minimum of two authorized individuals to enable the process.
• Security awareness training
• Background checks for personnel (within the constraints of local laws
• Creation (including cloning) must require a minimum of two authorized individuals to enable the process.
• Security awareness training
• Background checks for personnel (within the constraints of local laws
Added
p. 242
• Transportation using a trusted courier service (e.g., via bonded carrier). The devices are then securely stored until key-insertion and deployment occurs.
Added
p. 245
• Each production run must be associated with a predefined inventory of identified POI devices to be injected or initialized with keys.
• Unauthorized personnel must not be able to modify this inventory without detection.
• All POI devices to be initialized with keys on a production run must be identified and accounted for against the inventory.
• Unauthorized POI devices submitted for injection or initialized must be rejected by the injection platform and investigated.
• Procedures cover all devices removed from service or for repair.
• Procedures cover requirements at 6G-3.1.1 through 6G-3.1.6 below.
• To place the device into a state that allows for the input or output of clear-text key components;
• For all access to key-loading devices KLDs
• Locked in a secure cabinet and/or sealed in tamper-evident packaging, or
• KIFs must validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
• POI devices must validate authentication …
• Unauthorized personnel must not be able to modify this inventory without detection.
• All POI devices to be initialized with keys on a production run must be identified and accounted for against the inventory.
• Unauthorized POI devices submitted for injection or initialized must be rejected by the injection platform and investigated.
• Procedures cover all devices removed from service or for repair.
• Procedures cover requirements at 6G-3.1.1 through 6G-3.1.6 below.
• To place the device into a state that allows for the input or output of clear-text key components;
• For all access to key-loading devices KLDs
• Locked in a secure cabinet and/or sealed in tamper-evident packaging, or
• KIFs must validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
• POI devices must validate authentication …
Modified
p. 1
Payment Card Industry (PCI) Point-to-Point Encryption Template for Report on Validation for use with P2PE v2.0 (Revision 1.1) for P2PE Component Revision 1.1
Payment Card Industry (PCI) Point-to-Point Encryption Template for Report on Validation for use with P2PE v2.0 (Revision 1.2) for P2PE Component Revision 1.2
Modified
p. 7
• “Identify the P2PE Assessor who confirms…” Indicates only an affirmative response where further reporting is deemed unnecessary by PCI SSC. The P2PE Assessor’s name or a Not Applicable response are the two appropriate responses here. A Not Applicable response will require brief reporting to explain how this was confirmed via testing.
Modified
p. 7
• Document name or interviewee reference At 3.7 Documentation Reviewed and 3.8 Individuals Interviewed, there is a space for a reference number and it is the P2PE Assessor’s choice to use the document name/interviewee job title or the reference number in responses. A listing is sufficient here, no further detail required.
Modified
p. 7
• Sample reviewed Brief list is expected or sample identifier. Again, where applicable, it is the P2PE Assessor’s choice to list out each sample within reporting or to utilize sample identifiers from the sampling summary table.
Modified
p. 7
• “Describe how…” These are the only reporting instructions that will stretch across half of the table; the above are all a quarter-table’s width to serve as a visual indicator of detail expected in response. These responses must be a narrative response that provides explanation as to the observation•both a summary of what was witnessed and how that verified the criteria of the testing procedure.
• “Describe how…” These are the only reporting instructions that will stretch across half of the table; the above are all a quarter-table’s width to serve as a visual indicator of detail expected in response. These responses must be a narrative response that provides explanation as to the observation•both a summary of what was witnessed and how that verified the criteria of the testing procedure.
Modified
p. 8
• Use the corresponding Reporting Template for v2.0 of the P2PE Standard.
Modified
p. 8
• Complete all sections in the order specified, with concise detail.
Modified
p. 8
• Read and understand the intent of each Requirement and Testing Procedure.
Modified
p. 8
• Provide a response for every Testing Procedure, even if N/A.
Modified
p. 8
• Describe how a Requirement was verified as the Reporting Instruction directs, not just that it was verified.
Modified
p. 8
• Ensure all parts of the Testing Procedure are addressed.
Modified
p. 8
• Ensure the response covers all applicable application and/or system components.
Modified
p. 8
• Perform an internal quality assurance review of the P-ROV for clarity, accuracy, and quality.
Modified
p. 8
• Provide useful, meaningful diagrams, as directed.
Modified
p. 8
• Don’t report items in the “In Place” column unless they have been verified as being “in place.”
Modified
p. 8
• Don’t simply repeat or echo the Testing Procedure in the response.
Modified
p. 8
• Don’t copy responses from one Testing Procedure to another.
Modified
p. 8
• Don’t copy responses from previous assessments.
Modified
p. 8
• Don’t include information irrelevant to the assessment.
Modified
p. 14
• Domains 1 & 6, including Annex A as applicable
• Domains 5 & 6, including Annex A as applicable
• Annex B of Domain 6
•
• Encryption-management services
• Domains 1 & 6, including Annex A as applicable • Decryption-management services
• Domains 5 & 6, including Annex A as applicable • Key-injection facility services
• Annex B of Domain 6 • Certification Authority/Registration Authority services
• Domain 6 and Annex A Part A2 (in addition to Annex A Part A1, as applicable) P2PE Domain Compliant Comments (optional):
• Domains 1 & 6, including Annex A as applicable • Decryption-management services
• Domains 5 & 6, including Annex A as applicable • Key-injection facility services
• Annex B of Domain 6 • Certification Authority/Registration Authority services
• Domain 6 and Annex A Part A2 (in addition to Annex A Part A1, as applicable) P2PE Domain Compliant Comments (optional):
Modified
p. 15
• Describe the methods or processes used to identify all elements in scope of the P2PE component assessment:
Modified
p. 15
• Describe how the P2PE assessor confirmed that the scope of the assessment is accurate and covers all components and facilities for the P2PE component:
Modified
p. 16
• Locations of critical facilities, including the Component provider’s decryption environment, key-injection and loading facilities, etc.
Modified
p. 16
• Other necessary components, as applicable to the particular Component <Insert P2PE Component network diagram(s)> 3.4 Overview of P2PE Component data flow Provide a high-level data flow diagram of the Component that illustrates:
Modified
p. 16
• Location of critical components within the P2PE decryption environment, such as the Host System, HSMs and other SCDs, cryptographic key stores, etc., as applicable
• Location of systems performing key management functions
• Connections into and out of the decryption environment
• Flows and locations of P2PE-encrypted account data • Flows and locations of clear-text account data • Location of critical system components (e.g., HSMs, Host System) • All entities the Component connects to for payment transmission or processing, including processors/acquirers. Note: …
• Location of systems performing key management functions
• Connections into and out of the decryption environment
• Flows and locations of P2PE-encrypted account data • Flows and locations of clear-text account data • Location of critical system components (e.g., HSMs, Host System) • All entities the Component connects to for payment transmission or processing, including processors/acquirers. Note: …
Modified
p. 17
• Key Archiving (if applicable) Note: include both logical and physical components
•e.g., network traffic flows, locations of safes, use of secure couriers, etc.
•e.g., network traffic flows, locations of safes, use of secure couriers, etc.
Modified
p. 22
• SRED listed as a function provided 1A-1.1 For each POI device type used in the solution, examine the POI device configurations and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
Modified
p. 22
• SRED listed as a function provided For each POI device type used in the solution, describe how the POI device configurations and PCI SSC list of Approved PTS Devices verified that all of the POI device characteristics at 1A-1.1 match the PTS listing:
Removed
p. 23
Link Layer Protocols IP Protocols Security Protocols IP Services
Modified
p. 23
• Implementing configurations that prevent all non-SRED validated capture mechanisms from being used for P2PE transactions.
Modified
p. 23
• All non-validated capture mechanisms are either disabled or configured to prevent their use for P2PE transactions, prior to devices being deployed to merchant encryption environments. • Disabled capture mechanisms cannot be enabled by the merchant, and/or the configurations that prevent capture mechanisms from being used for P2PE transactions cannot be enabled by the merchant.
Removed
p. 24
Application name Version number
Modified
p. 24
• Version number 1A-2.1.a For applications on the PCI SSC list of Validated P2PE Applications, review the list and compare to applications used in the solution to verify that the applications match the P2PE application listing in the following characteristics:
Modified
p. 24
• Version number Refer to Section 2.3 “Listed P2PE Applications used in the P2PE Solution” in the Summary Overview for this documentation. No further reporting required here.
Modified
p. 24
• Version number Identify application P-ROV(s) reviewed:
Removed
p. 25
Be read-only Only view transaction-related data Cannot view or access cryptographic keys Cannot view or access clear-text PAN Cannot view or access SAD Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD Cannot enable disabled device interfaces or disabled data-capture mechanisms 1B-1.1.a Examine documented POI device configuration procedures and account privilege assignments to verify that merchant logical access to POI devices is restricted as follows:
Be read-only Only view transaction-related data Cannot view or access cryptographic keys Cannot view or access clear-text PAN Cannot view or access SAD. Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD Cannot enable disabled device …
Be read-only Only view transaction-related data Cannot view or access cryptographic keys Cannot view or access clear-text PAN Cannot view or access SAD. Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD Cannot enable disabled device …
Modified
p. 25
• Explicitly included in that application’s listing Refer to Section 2.3 “Listed P2PE Applications used in the P2PE Solution” and Section 2.5 “PTS Devices Supported” in the Summary Overview for this documentation. No further reporting required here.
Modified
p. 25
• Explicitly included in that P-ROV as assessed for that application.
Modified
p. 25
• Only view transaction-related data • Cannot view or access cryptographic keys • Cannot view or access clear-text PAN • Cannot view or access SAD
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD • Cannot enable disabled device interfaces or disabled data-capture mechanisms 1B-1.1.a Examine documented POI device configuration procedures and account privilege assignments to verify that merchant logical access to …
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD • Cannot enable disabled device interfaces or disabled data-capture mechanisms 1B-1.1.a Examine documented POI device configuration procedures and account privilege assignments to verify that merchant logical access to …
Modified
p. 26 → 25
• Only view transaction-related data • Cannot view or access cryptographic keys • Cannot view or access clear-text PAN • Cannot view or access SAD. • Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD • Cannot enable disabled device interfaces or disabled data-capture mechanisms <Report Findings Here>
• Only view transaction-related data
• Cannot view or access cryptographic keys
• Cannot view or access …
• Only view transaction-related data
• Cannot view or access cryptographic keys
• Cannot view or access …
Modified
p. 26
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD • Cannot enable disabled device interfaces or disabled data-capture mechanisms <Report Findings Here> 1B-1.1.c Observe a sample of POI device configurations and interview responsible personnel to verify that the defined merchant-access requirements are configured for all devices used in the solution.
Modified
p. 26
• The P2PE application that facilitates this is confirmed per 1A-2.1 as assessed to Domain 2 and on PCI SSC’s list of Validated P2PE Applications. Note that Domain 2 (at 2A-3.1.2) and Domain 3 (at 3A-1.3) also include requirements that must be met for any P2PE application and P2PE solution provider, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so. 1B-1.1.1.a Review solution provider’s documentation about the legal/regulatory obligation that …
Modified
p. 27
• All personnel with access to devices are documented in a formal list.
Modified
p. 30
• Authentication of origin of the update 1B-3.1.a Examine documented procedures to verify secure update processes are defined for all firmware and software updates, and include:
Modified
p. 30
• Authentication of origin of the update Documented procedures reviewed:
Modified
p. 30
• The origin of the update is authenticated Identify sample of firmware and software updates observed:
Modified
p. 30
• Procedures for maintaining an up-to-date inventory of POI device system builds • Procedures for confirming all builds at least annually and upon any changes to the build Documented procedures reviewed:
Modified
p. 30
• The inventory of POI device system builds is up-to-date.
Modified
p. 30
• The inventory of POI device system builds is up-to-date. <Report Findings Here> 1B-3.2.c Observe results of vulnerability assessments and interview responsible personnel to verify vulnerability assessments are performed against all POI device system builds:
Modified
p. 30
• Upon any changes to the build Responsible personnel interviewed:
Modified
p. 30
• Upon any changes to the build <Report Findings Here> 1B-3.3 Critical software security updates must be deployed to POI devices in the field within 30 days of receipt from device vendors or application vendors. Note: A “critical software security update” is one that addresses an imminent risk to account data, either directly or indirectly. Note: These security patches can be deployed via “push” from the solution provider or vendor, or via “pull” from the POI device or merchant. In …
Removed
p. 32
PAN and/or SAD is never output to merchant environments Collection of PAN and/or SAD only when needed to solve a specific problem Storage of such data in a specific, known location with limited access Collection of only a limited amount of data needed to solve a specific problem Encryption of PAN and/or SAD while stored Secure deletion of such data immediately after use Documented solution provider’s procedures for troubleshooting customer problems reviewed:
Modified
p. 32
• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) Describe how the device and/or system configurations observed verified that any changes to the critical functions of the POI devices are logged, including:
Modified
p. 32
• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) <Report Findings Here>
Modified
p. 33
• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) Describe how observation of authorized personnel performing authorized changes on POI devices, as follows, and examination of log files verified that all such activities result in a correlating log file:
Modified
p. 33
• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) <Report Findings Here> 1C-1.1 Applications with access to account data must be installed and configured to only use external communication methods specified in the application’s Implementation Guide. Aligns with 2A-3.3 1C-1.1.a Observe application and device configurations and interview personnel to verify that applications with access to account data are installed and configured to only use approved external communication methods, by following guidance in the application’s …
Modified
p. 33
• Implementing whitelisting functionality in accordance with the device vendor's security guidance or the application’s Implementation Guide. • Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control. • Cryptographic authentication by the POI device’s firmware • Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data. • Approval of functionality by authorized personnel prior to implementation • Documentation for all new installations or updates to whitelist functionality that …
Modified
p. 34
• Following the device vendor's security guidance or the application’s Implementation Guide • Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control. • Cryptographic authentication of whitelisting functionality by the POI device’s firmware • Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 34
• Cryptographically authenticated by the POI device’s firmware in accordance with the device vendor's security guidance or the application’s Implementation Guide.
Modified
p. 35
• Cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control. • Cryptographically authenticated by the POI device firmware, in accordance with the device vendor's security guidance or the application’s Implementation Guide.
Modified
p. 35
• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data. 1C-1.2.3 Review records of both new installations and updated whitelisting functionality, and confirm they include the following:
Modified
p. 35
• The identity of the person who approved the new installation or update prior to release. • Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
Modified
p. 35
• Does not have any logical interfaces (e.g., application programming interfaces (APIs)) that allow for the storing, processing, or transmitting of account data.
Modified
p. 36
• Review of the application vendor’s documentation to determine all logical interfaces used by the application/software. • Documenting how the solution provider confirmed that the application has no logical interfaces that allow for storing, processing, or transmitting account data
Modified
p. 37
• Following vendor guidance in the application’s Implementation Guide. • Documented approval for all changes by appropriate personnel. • Documented reason and impact for all changes. • Functionality testing of all changes on the intended device(s). • Documented back-out procedures for application installations/updates. Note that adding a
Modified
p. 37
• All changes to applications include documented approval by appropriate authorized solution-provider personnel. • All changes to applications are documented as to reason and impact of the change.
Modified
p. 37
• All Implementation Guide requirements were followed. • Approval of the change by appropriate parties is documented. • The documentation includes reason and impact of the change. • The documentation describes functionality testing that was performed. • Documentation includes back-out procedures for application installations/updates.
Modified
p. 38
• Cryptographic signing processes for applications are followed as specified in the Implementation Guide. • Cryptographic signing (or similar) is performed prior to installation only by authorized personnel using dual control. • All new installations and updates to applications are signed prior to installation on the device. • Cryptographic signing for new installations and updates to applications is done under dual control.
Modified
p. 38
• Cryptographic signing processes for applications are followed as specified in the Implementation Guide. • Cryptographic signing (or similar) is performed prior to installation only by authorized personnel using dual control. • All new installations and updates to applications are signed prior to installation on the device. • Cryptographic signing for new installations and updates to applications is done under dual control. <Report Findings Here> 1D-1.3 The application must be configured to securely integrate with any device resources that may …
Modified
p. 39
• The solution provider distributes the Implementation Guide to any outsourced integrators/resellers the solution provider uses for the P2PE solution upon obtaining updates from the application vendor.
Modified
p. 39
• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated. 1E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel, and to confirm that the following processes are documented and implemented:
Modified
p. 39
• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated.
Modified
p. 40
• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated.
Modified
p. 40
• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software. Note that adding, changing, or removing POI device types, P2PE applications, and/or P2PE non-payment software 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. 1E-1.2.a Review component provider’s documented procedures and interview responsible component-provider personnel, and confirm that processes include notifying the solution …
Modified
p. 40
• Critical software security updates deployed to POI devices. • Addition and/or removal of POI device types. • Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change. • Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change. • Critical software security updates deployed to POI devices.
• Addition and/or removal of POI device types.
• Adding, changing, and/or removing P2PE applications …
• Addition and/or removal of POI device types.
• Adding, changing, and/or removing P2PE applications …
Modified
p. 41
• Critical software security updates deployed to POI devices. • Addition and/or removal of POI device types. • Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change. • Adding, changing, and/or removing P2PE non-payment software (without access to clear-text account data), including description of change. • Updated list of POI devices, P2PE applications, and/or P2PE non-payment software.
Modified
p. 46
• PCI PTS HSM approved. 5A-1.1.a For all HSMs used in the decryption environment, examine approval documentation (e.g., FIPS certification or PTS approval) and review the list of approved devices to verify that all HSMs used in the solution are either:
Modified
p. 46
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 Level 3 (overall), or higher. Refer to http://csrc.nist.gov. • Listed on the PCI SSC website, with a valid PCI SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Approval documentation reviewed:
Modified
p. 46
• 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 provider has applied a vendor security patch resulting in an
Modified
p. 46
• Any applications, including application version number, resident within the device which were included in the PTS assessment For each PCI-approved HSM used in the solution, describe how the HSM device configurations observed verified that all of the device characteristics at 5A-1.1.1.a match the PTS listing: <Report Findings Here>
Modified
p. 47
• Firmware version number For each FIPS-approved HSM used in the solution, describe how the HSM device configurations observed verified that all of the device characteristics at 5A-1.1.1.b match the FIPS140-2 Level 3 (or higher) approval listing: <Report Findings Here> 5A-1.1.1.c If the solution provider has applied a vendor security patch that resulted in an
Modified
p. 47
• Purpose and description of any non-FIPS validated software
Modified
p. 47
• added to the HSM A statement that nothing has been
• A statement that nothing has been
Modified
p. 47
• Purpose and description of any non-FIPs validated software added to the
Removed
p. 48
Assigning administrative roles and responsibilities only to specific, authorized personnel Management of user interface Password/smart card management Console and non-console administration Access to physical keys Use of HSM commands
Modified
p. 49 → 48
• Assigning administrative roles and responsibilities only to specific, authorized personnel
Modified
p. 49
• Use of HSM commands Describe how the observation verified that secure administration procedures are implemented for the following:
Modified
p. 49
• Use of HSM commands <Report Findings Here> 5B-1.2.c Observe personnel performing decryption-device administration and examine files/records that assign administrative roles and responsibilities to verify that only authorized and assigned personnel perform decryption-device administration operations.
Modified
p. 50
• Procedures and/or mechanisms for authenticating POI devices upon connection to the decryption environment • Procedures and/or mechanisms for authenticating POI devices upon request by the solution provider Documented policies and procedures reviewed:
Modified
p. 50
• POI devices are authenticated upon connection to the decryption environment. • POI devices are authenticated upon request by the solution provider.
Modified
p. 50
• Physically connected devices 5B-1.5.a Examine documented procedure to verify that physical inspection of devices is required at least quarterly to detect signs of tampering or modification, and that inspection procedures include:
Modified
p. 50
• Physically connected devices Documented procedures reviewed:
Modified
p. 50
• Physically connected devices Personnel interviewed: <Report Findings Here> Describe how the inspection processes observed verified that inspections include the device itself, cabling/connection points and physically connected devices: <Report Findings Here> 5B-1.5.c Interview personnel performing inspections and review supporting documentation to verify that physical inspections are performed at least quarterly.
Modified
p. 51
• Performed within the previous 12 months
Removed
p. 52
Cryptographic signing (or similar) prior to installation by authorized personnel using dual control. Cryptographic authentication by the HSM Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data. Approval of functionality by authorized personnel prior to implementation Documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Documented policies and procedures reviewed:
Modified
p. 52
• Documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 5B-1.9 Review documented policies and procedures to verify that that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment ensures the that the …
Modified
p. 53
• Cryptographically authenticated by the HSM 5B-1.9.2 Observe the process for new installations or updates to whitelisting functionality and interview personnel to verify that additions or updates to whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment are performed as follows:
Modified
p. 53
• Cryptographically signed (or similar) prior to installation only by authorized personnel using dual control • Cryptographically authenticated by the HSM Personnel interviewed: <Report Findings Here> Describe how the observed process verified that additions or updates to whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment are performed as follows:
Modified
p. 53
• Cryptographically signed (or similar) prior to installation only by authorized personnel using dual control • Cryptographically authenticated by the HSM <Report Findings Here> 5B-1.9.3 Any new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must follow change-control procedures that include:
Modified
p. 53
• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data. 5B-1.9.3 Review records of both new and updated whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment, and confirm the following:
Modified
p. 53
• Cryptographically signed (or similar) prior to installation only by authorized personnel using dual control
• Coverage for both new installations and updates to such functionality
• Description and justification for the functionality
• Who approved the new installation or update prior to release
• Both new installations and updates to whitelisting functionality are documented. • The documentation includes description and justification. • The documentation includes who approved it prior to implementation. • The documentation includes confirmation that it was reviewed prior to release …
• Coverage for both new installations and updates to such functionality
• Description and justification for the functionality
• Who approved the new installation or update prior to release
• Both new installations and updates to whitelisting functionality are documented. • The documentation includes description and justification. • The documentation includes who approved it prior to implementation. • The documentation includes confirmation that it was reviewed prior to release …
Removed
p. 54
Changes to the applications Changes to the firmware Changes to any security-sensitive configurations Describe how system configurations and correlating log files verified that any changes to the critical functions of decryption devices are logged, including:
Physical breach Tampered, missing, or substituted devices Unauthorized logical alterations (e.g., configurations, access controls) Unauthorized use of sensitive functions (e.g., key-management functions) Disconnect/reconnect of devices Failure of any device security control Encryption/decryption failures Unauthorized use of the HSM API 5C-1.2.a Examine documented procedures to verify mechanisms are defined to detect and respond to potential security incidents, including:
Physical breach Tampered, missing, or substituted devices Unauthorized logical alterations (e.g., configurations, access controls) Unauthorized use of sensitive functions (e.g., key-management functions) Disconnect/reconnect of devices Failure of any device security control Encryption/decryption failures Unauthorized use of the HSM API Documented procedures …
Physical breach Tampered, missing, or substituted devices Unauthorized logical alterations (e.g., configurations, access controls) Unauthorized use of sensitive functions (e.g., key-management functions) Disconnect/reconnect of devices Failure of any device security control Encryption/decryption failures Unauthorized use of the HSM API 5C-1.2.a Examine documented procedures to verify mechanisms are defined to detect and respond to potential security incidents, including:
Physical breach Tampered, missing, or substituted devices Unauthorized logical alterations (e.g., configurations, access controls) Unauthorized use of sensitive functions (e.g., key-management functions) Disconnect/reconnect of devices Failure of any device security control Encryption/decryption failures Unauthorized use of the HSM API Documented procedures …
Modified
p. 54
• Changes to any security-sensitive configurations <Report Findings Here> 5C-1.2 Mechanisms must be implemented to detect and respond to suspicious activity, including but not limited to:
Modified
p. 54
• Unauthorized use of the HSM API Personnel interviewed: <Report Findings Here> Describe the implemented mechanisms that were observed to be implemented to detect and respond to suspicious activity: <Report Findings Here>
Modified
p. 55
• Procedures are defined to detect encryption failures, and include 5C-1.3.1 through 5C-1.3.4 below. • Procedures include immediate notification upon detection of a cryptographic failure, for each 5C-1.3.1 through 5C-1.3.4 below.
Modified
p. 56 → 57
• Identification of affected device(s), including make, model, and serial number • Identification of affected merchant, including specific sites/locations if applicable
Modified
p. 57
• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled Documented procedures reviewed:
Modified
p. 57
• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled Responsible personnel interviewed:
Modified
p. 57
• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled <Report Findings Here> 5C-1.5 Implement mechanisms to provide immediate notification of suspicious activity to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers). 5C-1.5.a Examine documented procedures to verify mechanisms are defined to provide immediate notification of suspicious activity to applicable parties, including …
Modified
p. 58
• The necessary services, protocols, daemons etc. must be documented and justified, including description of the enabled security features for these services etc. • Functions not related to transaction processing must be disabled, or isolated (e.g., using logical partitions), from transaction processing. Note: “Isolated” means that the Host System must not be accessed, modified or intercepted by other processes. 5D-1.2.a Inspect network and system configuration settings to verify the host processing system is isolated, or dedicated, to transaction processing, with …
Modified
p. 59
• Testing integrity of any security functions critical to the secure operation of the Host System.
Modified
p. 60
• Testing integrity of any security functions critical to the secure operation of the Host System.
Modified
p. 60
• Testing integrity of any security functions critical to the secure operation of the Host System. <Report Findings Here> 5D-1.6.b Review logs/audit trails from when the Host System has previously been powered-up and interview personnel, to verify that the Host System performs a self-test to ensure its integrity before use. Verify the self-tests included the tests described in 5D-1.6.a.
Modified
p. 60
• Failure of a security function or mechanism Note: An “error state” identifies the Host System has encountered an issue that requires a response action. To prevent potential damage or compromise, the system must cease cryptographic operations until the issue is resolved and the host is returned to a normal processing state.
Removed
p. 61
While in an error state, as described in Requirement 5D-1.8 During self-tests, as described in Requirements 5D-1.6 and 5D-1.7 During diagnostics of cryptographic operations.
Modified
p. 61
• Failure of a system self-test, as described in Requirements 5D-1.6 and 5D- 1.7 • Failure of a security function or mechanism Vendor/solution provider documentation reviewed:
Modified
p. 61
• Failure of a system self-test, as described in Requirements 5D-1.6 and 5D- 1.7 • Failure of a security function or mechanism <Report Findings Here> 5D-1.8.b Interview personnel and examine logs/records of actual or test alerts to verify that alerts are generated and received when the Host System enters an error state under one of the following conditions:
Modified
p. 61
• Failure of a system self-test, as described in Requirements 5D-1.6 and 5D- 1.7 • Failure of a security function or mechanism Personnel interviewed: <Report Findings Here> Logs/records of actual or test alerts examined:
Modified
p. 62 → 61
• While in an error state, as described in Requirement 5D-1.8 • During self-tests, as described in Requirements 5D-1.6 and 5D-1.7
• During diagnostics of cryptographic operations.
• While in an error state, as described in Requirement 5D-1.8
• During self-tests, as described in Requirements 5D-1.6 and 5D-1.7. • During diagnostics of cryptographic operations.
• During diagnostics of cryptographic operations.
• While in an error state, as described in Requirement 5D-1.8
• During self-tests, as described in Requirements 5D-1.6 and 5D-1.7. • During diagnostics of cryptographic operations.
Modified
p. 62
• While in an error state, as described in Requirement 5D-1.8 • During self-tests, as described in Requirements 5D-1.6 and 5D-1.7. • During diagnostics of cryptographic operations.
Modified
p. 62
• During diagnostics of cryptographic operations <Report Findings Here> 5D-1.11 All source code and executable code for cryptographic software and firmware on the Host System must be protected from unauthorized disclosure and unauthorized modification. 5D-1.11.a Inspect configuration documentation to verify that access controls are defined to ensure all source code and executable code for cryptographic software and firmware is protected from unauthorized disclosure and unauthorized modification.
Modified
p. 63
• ‘Core dumps’ of memory required for troubleshooting. In the above circumstances, the following conditions apply: 5D-1.14.a Examine documented configuration procedures to verify that the Host System must not write clear-text cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:
Modified
p. 63
• Core dumps’ of memory required for trouble-shooting.
Modified
p. 63
• ‘Core dumps’ of memory required for trouble-shooting.
Modified
p. 63
• ‘Core dumps’ of memory required for trouble-shooting. <Report Findings Here> 5D-1.14.c Verify documented procedures include Requirements 5D-1.14.1 through 5D-1.14.5 below.
Modified
p. 64
• Core dumps must be securely
Modified
p. 64
• Core dumps must be securely
Modified
p. 64
• deleted immediately after analysis. Memory ‘swap/page’ files must be securely
• deleted immediately after analysis.
Modified
p. 64
• deleted immediately after analysis. Memory ‘swap/page’ files must be securely
• deleted immediately after analysis.
Modified
p. 65
• Have equivalent strength/complexity. 5D-2.2.a Examine documented policies and procedures to verify that user passwords must:
Modified
p. 65
• Consist of a combination of numeric, alphabetic, and special characters, or
Modified
p. 65
• Consist of a combination of numeric, alphabetic, and special characters, or
Modified
p. 65
• Have equivalent strength/complexity. <Report Findings Here> 5D-2.3 Where log-on security tokens (e.g., smart cards) are used to access the Host System, the security tokens must have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage. The PIN or password/passphrase must be at least ten alphanumeric characters in length, or equivalent. 5D-2.3.a If log-on security tokens are used, observe the security tokens in use to verify that they have an associated usage-authentication …
Modified
p. 66
• Host System operator role
Modified
p. 66
• for day-to-day non-sensitive operations of the Host System. Host System administrator role
• for day-to-day non-sensitive operations of the Host System.
Modified
p. 66
• configuration of host OS, security controls, software and user accounts. Cryptographic administrator role
• configuration of host OS, security controls, software and user accounts.
Modified
p. 66
• configuration of cryptographic management functions Host System security role
• configuration of cryptographic management functions
Modified
p. 66
• for day-to-day non-sensitive operations of the Host System.
• configuration of host OS, security controls, software and user accounts.
• configuration of cryptographic management functions
• auditing of host functions Documented access-control procedures reviewed:
• Host System operator role
• for day-to-day non-sensitive operations of the Host System. • Host System administrator role
• configuration of host OS, security controls, software and user accounts. • Cryptographic administrator role
• configuration of cryptographic management functions • Host System security role
• auditing of host functions Documented access-control procedures reviewed:
• for day-to-day non-sensitive operations of the Host System. • Host System administrator role
• configuration of host OS, security controls, software and user accounts. • Cryptographic administrator role
• configuration of cryptographic management functions • Host System security role
• auditing of host functions Documented access-control procedures reviewed:
Modified
p. 67
• for day-to-day non-sensitive operations of the Host System.
• configuration of host OS, security controls, software and user accounts.
• configuration of cryptographic management functions
• auditing of host functions.
• Host System operator role
• for day-to-day non-sensitive operations of the Host System. • Host System administrator role
• configuration of host OS, security controls, software and user accounts. • Cryptographic administrator role
• configuration of cryptographic management functions • Host System security role
• auditing of host functions.
• for day-to-day non-sensitive operations of the Host System. • Host System administrator role
• configuration of host OS, security controls, software and user accounts. • Cryptographic administrator role
• configuration of cryptographic management functions • Host System security role
• auditing of host functions.
Modified
p. 67
• for day-to-day non-sensitive operations of the Host System.
• configuration of host OS, security controls, software and user accounts.
• configuration of cryptographic management functions
• auditing of host functions. <Report Findings Here> 5D-2.5.c Interview a sample of users for each role to verify the assigned role is appropriate for their job function.
• Host System operator role
• for day-to-day non-sensitive operations of the Host System. • Host System administrator role
• configuration of host OS, security controls, software and user accounts. • Cryptographic administrator role
• configuration of cryptographic management functions • Host System security role
• auditing of host functions. <Report Findings Here> 5D-2.5.c Interview a sample of users for each role to verify the assigned role is appropriate for their job function.
• for day-to-day non-sensitive operations of the Host System. • Host System administrator role
• configuration of host OS, security controls, software and user accounts. • Cryptographic administrator role
• configuration of cryptographic management functions • Host System security role
• auditing of host functions. <Report Findings Here> 5D-2.5.c Interview a sample of users for each role to verify the assigned role is appropriate for their job function.
Modified
p. 67
• Requiring the participation of at least two persons. Therefore, the party making the change cannot authorize the change on their own.
Modified
p. 68 → 67
• Using a formal change-control procedure. • Ensuring all changes to access privileges result in an audit log.
• Using a formal change-control procedure.
• Requiring the participation of at least two persons. Therefore, the party making the change cannot authorize the change on their own. • Ensuring all changes to access privileges result in an audit log.
• Using a formal change-control procedure.
• Requiring the participation of at least two persons. Therefore, the party making the change cannot authorize the change on their own. • Ensuring all changes to access privileges result in an audit log.
Modified
p. 68
• Using a formal change-control procedure. • Requiring the participation of at least two persons. Therefore, the party making the change cannot authorize the change on their own. • Ensuring all changes to access privileges result in an audit log.
Modified
p. 68
• Requiring the participation of at least two persons. Therefore, the party making the change cannot authorize the change on their own. • Ensuring all changes to access privileges result in an audit log. <Report Findings Here> 5D-2.7.c Inspect the Host System configuration settings and, for a sample of user accounts, verify that any changes to their access privileges have been formally documented in the audit log.
Modified
p. 70
• Originate from and be managed by the solution provider.
Modified
p. 71
• Originate from and be managed by the solution provider.
Modified
p. 72
• Logs must be regularly reviewed by an authorized person who does not have access to the secure room or to the systems therein.
Modified
p. 72
• Logs are regularly reviewed by an authorized person who does not have access to the secure room or to the systems therein.
Modified
p. 72
• Logs are being retained for a minimum of three years.
Modified
p. 72
• The person performing the review does not have access to the secure room or to the systems therein.
Modified
p. 73
• Access to the Host System and HSM(s) Note: Motion-activated systems that are separate from the intrusion-detection system may be used. 5D-4.6.a Inspect CCTV configuration and review a sample of recordings to verify that CCTV monitoring is in place on a 24 hour basis, and covers, as a minimum, the following areas:
Modified
p. 73
• Access to the Host System and HSM(s) Sample of CCTV recordings reviewed:
Modified
p. 73
• Access to the Host System and HSM(s) <Report Findings Here> 5D-4.6.b If CCTV is motion-activated, observe system configurations for the motion-activated systems to verify they are separate from the intrusion- detection system.
Modified
p. 75
• Continuous (24/7) physical intrusion-detection monitoring of the secure room. • The physical intrusion-detection must be connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
Modified
p. 75
• It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
Modified
p. 75
• It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room. <Report Findings Here> 5D-4.12 Any windows in the secure room must be locked, protected by alarmed sensors, or otherwise similarly secured.
Modified
p. 77
• An airlock entrance system. 5D-4.20 Observe authorized personnel entering the secure room to verify that a mechanism is in place to ensure the door is not left open. Examples include:
Modified
p. 77
• A door that is contact monitored and fitted with automatic closing or locking devices. • An airlock entrance system.
Removed
p. 78
Providing reports annually and upon significant changes Types/models of HSMs Number of HSMs deployed and description of any changes since last report Date of last physical inspection of HSMs Date/status of last PCI DSS assessment Details of any suspicious activity that occurred, per 5C-1.2 Component provider’s documented procedures reviewed:
Addition and/or removal of HSM types. Critical infrastructure changes, including to the PCI DSS environment Changes to PCI DSS compliance status Note that adding or removing HSM types 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.
Addition and/or removal of HSM types. Critical infrastructure changes, including to the PCI DSS environment Changes to PCI DSS compliance status Note that adding or removing HSM types may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.
Modified
p. 78
• Details of any suspicious activity that occurred, per 5C-1.2 5E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel, and to confirm that the following processes are documented and implemented:
Modified
p. 78
• Details of any suspicious activity that occurred, per 5C-1.2 Identify reports reviewed: <Report Findings Here> 5E-1.2 Manage and monitor changes to decryption-management services and notify the solution provider upon occurrence of any of the following:
Modified
p. 79
• Additions and/or removal of HSM types Component provider’s documented procedures reviewed:
Modified
p. 79
• Critical infrastructure changes, including to the PCI DSS environment
Modified
p. 84
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 6A.1.1 Only approved encryption algorithms and key sizes must be used to protect account data and cryptographic keys, as listed in Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms. 6A-1.1.a Examine documented key-management policies and procedures to verify that all cryptographic keys use algorithms and key sizes that are in accordance with Normative Annex …
Domain 6: P2PE Cryptographic Key Operations and Device Management
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 6A.1.1 Only approved encryption algorithms and key sizes must be used to protect account data and cryptographic keys, as listed in Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms. [Applies to CA/RA assessments] 6A-1.1.a Examine documented key-management policies and procedures to verify that all cryptographic keys use algorithms and key sizes that are in accordance with …
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 6A.1.1 Only approved encryption algorithms and key sizes must be used to protect account data and cryptographic keys, as listed in Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms. [Applies to CA/RA assessments] 6A-1.1.a Examine documented key-management policies and procedures to verify that all cryptographic keys use algorithms and key sizes that are in accordance with …
Modified
p. 85
• Crypto-periods are based on industry best practices and guidelines (e.g., NIST Special Publication 800-57). • A process/methodology is in place to determine when the crypto-period is reached for each cryptographic key. • Cryptographic key changes are implemented whenever a key reaches the end of its defined crypto-period.
Modified
p. 86
• Key-destruction method 6A-1.3.1.a Examine key management policies and procedures and verify documentation of all cryptographic keys managed as part of the P2PE solution is required, and includes:
Modified
p. 86
• Key type/description • Description of level in the key hierarchy • Purpose/function of the key (including type of devices using key) • Key-creation method • Key-distribution method (e.g., manually via courier, remote key distribution) • Type of media used for key storage • Key type/description
• Description of level in the key hierarchy
• Purpose/function of the key (including type of devices using key)
• Key-creation method
• Key-distribution method (e.g., manually via courier, remote key distribution)
• Type of media used for key …
• Description of level in the key hierarchy
• Purpose/function of the key (including type of devices using key)
• Key-creation method
• Key-distribution method (e.g., manually via courier, remote key distribution)
• Type of media used for key …
Modified
p. 86
• Key-destruction method Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 6A-1.3.2 Maintain a list of all devices used to generate keys or key components managed as part of the P2PE solution, including:
Modified
p. 86
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22)
Modified
p. 87
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documented key management policies and procedures reviewed:
Modified
p. 87
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 6B-1.1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Cryptographic keys or key components must be generated by one of the following:
Modified
p. 87
• An approved random number generator that has been certified by an independent laboratory to comply with NIST SP800-22 Random number generation is critical to the security and integrity of all cryptographic systems. All cryptographic key generation relies upon good quality, randomly generated values. [Applies to CA/RA assessments] 6B-1.1.a Examine key-management policy document and verify that it requires that all devices used to generate cryptographic keys meet one of the following:
Modified
p. 87
• An approved key-generation function of a PCI
•approved HSM or POI device; • An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM; or • An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.
•approved HSM or POI device; • An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM; or • An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.
Modified
p. 88
• An approved key-generation function of a PCI
•approved HSM or POI device; • An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM; or • An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 Certification letters/technical documentation reviewed:
•approved HSM or POI device; • An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM; or • An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 Certification letters/technical documentation reviewed:
Modified
p. 88
Describe how the reviewed devices used for key generation verified that devices are as noted above, including validation of the firmware: <Report Findings Here> 6B-2.1 Implement security controls, including dual control and tamper protection to prevent the unauthorized disclosure of keys/key components.
Describe how the reviewed devices used for key generation verified that devices are as noted above, including validation of the firmware: <Report Findings Here> 6B-2.1 Implement security controls, including dual control and tamper protection to prevent the unauthorized disclosure of keys/key components. [Applies to CA/RA assessments] 6B-2.1 Perform the following:
Modified
p. 88
6B-2.1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component. 6B-2.1.1.a Examine documented procedures to verify the following.
6B-2.1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component. [Applies to CA/RA assessments] 6B-2.1.1.a Examine documented procedures to verify the following.
Modified
p. 88
• 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. • There is no unauthorized mechanism that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Modified
p. 89
• 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. • There is no mechanism (including connectivity) that might disclose a clear- text key or key component between the key-generation device and the device or medium receiving the key or key component.
Modified
p. 89
Responsible personnel interviewed: <Report Findings Here> Describe how the key-generations 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: <Report Findings Here> Describe how the key-generations processes observed verified that there is no mechanism (including connectivity) that might disclose a clear-text key or key component between the key-generation device and the device or medium …
Responsible personnel interviewed: <Report Findings Here> Describe how the key-generations 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: <Report Findings Here> Describe how the key-generations processes observed verified that there is no mechanism (including connectivity) that might disclose a clear-text key or key component between the key-generation device and the device or medium …
Modified
p. 89
• must have key-generation capabilities disabled when not in use and other activities are continuing. 6B-2.1.3 Examine documented procedures for all key-generation methods. Verify procedures require that:
• must have key-generation capabilities disabled when not in use and other activities are continuing. [Applies to CA/RA assessments] 6B-2.1.3 Examine documented procedures for all key-generation methods. Verify procedures require that:
Modified
p. 89
• Key-generation devices that generate clear-text key components are powered off when not in use; or • If logically partitioned for concurrent use in other processes, the key- generation capabilities are disabled when not in use and other activities are continuing.
Modified
p. 89
<Report Findings Here> 6B-2.1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., unnecessary cables).
<Report Findings Here> 6B-2.1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., unnecessary cables). [Applies to CA/RA assessments]
Removed
p. 90
Only approved key custodians can observe their own key component. Tampering can be visually detected. Printers used for this purpose must not be used for other purposes.
Modified
p. 90
Describe how the key-generation set-up processes observed verified that key- generation equipment is inspected prior to use to ensure equipment does not show any signs of tampering: <Report Findings Here> 6B-2.1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the key-generation area It must not be feasible to observe the key-component/key-generation process whereby clear-text keying material is observable either directly or via camera monitoring 6B-2.1.5.a Examine documentation to verify that physical security controls are defined to …
Describe how the key-generation set-up processes observed verified that key- generation equipment is inspected prior to use to ensure equipment does not show any signs of tampering: <Report Findings Here> 6B-2.1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the key-generation area It must not be feasible to observe the key-component/key-generation process whereby clear-text keying material is observable either directly or via camera monitoring [Applies to CA/RA assessments] 6B-2.1.5.a Examine documentation to verify that physical security …
Modified
p. 90
Describe how the physical security controls observed verified that the key- component/key-generation process cannot be observed or accessed by unauthorized personnel: <Report Findings Here> 6B-2.2 Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret key or private key, or key component thereof, appears in unprotected memory. 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 …
Describe how the physical security controls observed verified that the key- component/key-generation process cannot be observed or accessed by unauthorized personnel: <Report Findings Here> 6B-2.2 Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret key or private key, or key component thereof, appears in unprotected memory. 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 …
Modified
p. 90
<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> 6B-2.3 Printed key components must be printed within blind mailers or sealed immediately after printing to ensure that:
<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>
Modified
p. 91
• Only approved key custodians can observe their own key component.
Modified
p. 91
• Other types of displaying or recording [Applies to CA/RA assessments] 6B-2.4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures are implemented to ensure the following:
Modified
p. 92
• If generated externally, the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair [Applies to CA/RA assessments] 6B-2.5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:
Modified
p. 92
• 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.
Modified
p. 92
• 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.
Modified
p. 92
• 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. <Report Findings Here>
Removed
p. 93
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into startup instructions Affixing (e.g., taping) key or component values to or inside devices Writing key or component values in procedure manuals 6B-2.6.a Examine documented policy and procedures to verify that clear-text private or secret keys or their components are prohibited from being transmitted across insecure channels, including but not limited to:
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into …
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into …
Modified
p. 93 → 92
• Generated by the device that will use the key pair, or
• Dictating verbally keys or components • Recording key or component values on voicemail • Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components • Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging • Writing key or component values into startup instructions • Affixing (e.g., taping) key or component values to or inside devices • Writing key or component values …
• Dictating verbally keys or components • Recording key or component values on voicemail • Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components • Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging • Writing key or component values into startup instructions • Affixing (e.g., taping) key or component values to or inside devices • Writing key or component values …
Modified
p. 93
• Writing key or component values in procedure manual <Report Findings Here> 6B-3.1 Written key-generation procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of these procedures. Procedures for creating all keys must be documented. [Applies to CA/RA assessments]
Modified
p. 94
Describe how the actual or demonstrative key-generation ceremonies verified that the documented procedures are demonstrably in use: <Report Findings Here> 6B-3.2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs.
Describe how the actual or demonstrative key-generation ceremonies verified that the documented procedures are demonstrably in use: <Report Findings Here> 6B-3.2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs. [Applies to CA/RA assessments] 6B-3.2.a Examine documented key-generation procedures to verify that key- generation events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components and MFKs and BDKs) are logged.
Modified
p. 94
• Where key components are transmitted in clear-text using pre-numbered, tamper-evident, authenticable mailers:
Modified
p. 94
- 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. - Ensure that details of the serial number of the package are conveyed separately from the package itself. - Ensure that that documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material. Where an SCD …
- 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. - Ensure that details of the serial number of the package are conveyed separately from the package itself. - Ensure that that documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material. • Where an SCD …
Modified
p. 94
Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering. Components of encryption keys must be transferred using different communication channels, such as different courier services. It is not sufficient to send key components for a specific key on different days using the same communication channel. 6C-1.1.a Determine whether keys are transmitted encrypted as clear-text components, or within an SCD.
Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering. Components of encryption keys must be transferred using different communication channels, such as different courier services. It is not sufficient to send key components for a specific key on different days using the same communication channel. [Applies to CA/RA assessments]
Modified
p. 95
• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package itself. • Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself. • Examine documented procedures to verify that cryptographic-key components are transferred using different communications channels. • Examine records of key conveyances and interview responsible …
Modified
p. 95
• Examine documented procedures to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels. • Examine documented procedures to verify that the SCD is inspected to ensure that there are not any signs of tampering. • Examine records of key transfers and interview responsible personnel to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
Modified
p. 95
Documented procedures reviewed: <Report Findings Here> Records of key transfers examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6C-1.2 A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. …
Documented procedures reviewed: <Report Findings Here> Records of key transfers examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6C-1.2 A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. …
Modified
p. 96
• 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. • Any person with access to the media conveying a component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is …
Modified
p. 96
• An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key. • 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 …
Modified
p. 96
• An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key. • 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 …
Modified
p. 96
Describe how the method used to transport key components verified that it does not allow for any personnel to have access to all components: <Report Findings Here> 6C-1.3 E-mail shall not be used for the conveyance of secret or private keys or their components, even if encrypted, unless the key (or component) has already been encrypted in accordance with these requirements•i.e., in an SCD. This is due to the existence of these key values in unprotected memory just prior to …
Describe how the method used to transport key components verified that it does not allow for any personnel to have access to all components: <Report Findings Here> 6C-1.3 E-mail shall not be used for the conveyance of secret or private keys or their components, even if encrypted, unless the key (or component) has already been encrypted in accordance with these requirements•i.e., in an SCD. This is due to the existence of these key values in unprotected memory just prior to …
Modified
p. 97
• Within an SCD Note: Self-signed certificates must not be used as the sole method of authentication. [Applies to CA/RA assessments] 6C-1.4.a For all methods used to convey public keys, perform the following: Identify the P2PE Assessor who verified all methods used to convey public keys:
Modified
p. 97
• Using a MAC (message authentication code) created using the algorithm defined in ISO 16609 • Within an SCD Documented procedures reviewed: <Report Findings Here> 6C-1.4.c Observe the process for conveying public keys and interview responsible personnel to verify that self-signed certificates are not be used as the sole method of authentication.
Modified
p. 98
• Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or • Contained within a physically secure SCD. Note: No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key. [Applies to CA/RA assessments] 6C-2.1.a Examine documented procedures for transmission, …
Modified
p. 98
• Under the continuous supervision of a person with authorized access to this component • Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or • Contained within a physically secure SCD.
Modified
p. 98
• Under the continuous supervision of a person with authorized access to this component • Locked in a security container (including pre-numbered tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or • Contained within a physically secure SCD.
Modified
p. 98
• Under the continuous supervision of a person with authorized access to this component • Locked in a security container (including pre-numbered tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or • Contained within a physically secure SCD. <Report Findings Here>
Modified
p. 99
• Any keys encrypted under this (combined) key [Applies to CA/RA assessments] 6C-2.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.
Modified
p. 99
• Any keys encrypted under this (combined) key Documented procedures reviewed: <Report Findings Here> 6C-2.2.d Interview responsible personnel and observe processes to verify that if a package shows signs of tampering, processes are implemented that result in the destruction and replacement of both:
Modified
p. 99
• Any keys encrypted under this (combined) key Responsible personnel interviewed Describe how the observed process verified that if a package shows signs of tampering, processes are implemented that result in the destruction and replacement of both:
Modified
p. 99
• Any keys encrypted under this (combined) key <Report Findings Here> 6C-2.3 Only the authorized key custodian (and designated backup(s)) shall have physical access to a key component prior to transmittal or upon receipt of a component. [Applies to CA/RA assessments] 6C-2.3.a Verify that a list(s) of key custodians (and designated backup(s)) authorized to have physical access to key components prior to transmittal or upon receipt of a component is defined and documented.
Removed
p. 100
Place key components into pre-numbered tamper-evident, authenticable packaging for transmittal. Check tamper-evident packaging upon receipt for signs of tamper prior to opening tamper-evident authenticable packaging containing key components. Check the serial number of the tamper-evident packaging upon receipt of a component package. 6C-2.4.a Verify that a list(s) of key custodians authorized to perform the following activities is defined and documented:
Modified
p. 100
• Place the key component into pre-numbered tamper-evident packaging for transmittal. • Upon receipt, check the tamper-evident packaging for signs of tamper prior to opening the tamper-evident packaging containing the key component. • Check the serial number of the tamper-evident packaging upon receipt of a component package.
Modified
p. 100
• Place the key component into pre-numbered tamper-evident packaging for transmittal. • Upon receipt, check the tamper-evident packaging for signs of tamper prior to opening the tamper-evident packaging containing the key component. • Check the serial number of the tamper-evident packaging upon receipt of a component package.
Modified
p. 100
• Place the key component into pre-numbered tamper-evident packaging for transmittal. • Upon receipt, check the tamper-evident packaging for signs of tamper prior to opening the tamper-evident packaging containing the key component. • Check the serial number of the tamper-evident packaging upon receipt of a component package. <Report Findings Here> 6C-2.5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers. Note: Numbered …
Modified
p. 100
• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package itself. • Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself.
Removed
p. 101
- DEA keys used for encrypting keys must be at least double-length keys (have bit strength of 80 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment. - A double- or triple-length DEA key must not be encrypted with a DEA key of lesser strength. - TDEA keys are not used to protect AES keys. - TDEA keys are not be used to encrypt keys greater in strength than 112 bits. - RSA keys encrypting keys greater in strength than 80 bits have bit strength at least 112 bits.
Modified
p. 101
• RSA keys encrypting keys greater in strength than 80 bits shall have bit strength of at least 112 bits. 6C-3.1.a Examine documented procedures to verify that all keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed, as delineated in Annex C.
Modified
p. 101
• Interview appropriate personnel and examine documented procedures for the creation of these keys. • Using the table in Annex C, validate the respective key sizes for TDEA, RSA, Elliptic Curve, DSA, and Diffie Hellman algorithms where used for key encryption. • Verify that:
Modified
p. 101
Appropriate personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> Describe how 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 <Report Findings Here> 6C-1.c Examine system documentation and configuration files to validate the above, including HSM settings.
Appropriate personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> Describe how 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 <Report Findings Here> 6C-.3.1.c Examine system documentation and configuration files to validate the above, including HSM settings.
Modified
p. 101
System documentation reviewed: <Report Findings Here> Describe how the configuration files observed validated the above, including HSM settings: <Report Findings Here> 6C-4.1 Written procedures must exist and be known to all affected parties.
System documentation reviewed: <Report Findings Here> Describe how the configuration files observed validated the above, including HSM settings: <Report Findings Here> 6C-4.1 Written procedures must exist and be known to all affected parties. [Applies to CA/RA assessments] 6C-4.1.a Verify documented procedures exist for all key transmission and conveyance processing.
Modified
p. 102
Responsible personnel interviewed: <Report Findings Here> 6C-4.2 Methods used for the conveyance or receipt of keys must be documented.
Responsible personnel interviewed: <Report Findings Here> 6C-4.2 Methods used for the conveyance or receipt of keys must be documented. [Applies to CA/RA assessments] 6C-4.2 Verify documented procedures include all methods used for the conveyance or receipt of keys.
Modified
p. 102
• split knowledge. Note: Manual key loading may involve the use of media such as paper, smart cards, or other physical tokens. 6D-1.1.a Review documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and
• split knowledge. Note: Manual key loading may involve the use of media such as paper, smart cards, or other physical tokens. [Applies to CA/RA assessments] 6D-1.1.a Review documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and
Modified
p. 102
Describe how the structured walk-through/demonstration verified that key- loading devices can only be accessed and used under dual control: <Report Findings Here> 6D-1.2 Procedures must be established that will prohibit any one person from having access to components sufficient to form an encryption key when components are removed from and returned to storage for key loading. 6D-1.2. Examine logs of access to security containers for key components to verify that only the authorized custodian(s) have accessed. Compare the number on …
Describe how the structured walk-through/demonstration verified that key- loading devices can only be accessed and used under dual control: <Report Findings Here> 6D-1.2 Procedures must be established that will prohibit any one person from having access to components sufficient to form an encryption key when components are removed from and returned to storage for key loading. [Applies to CA/RA assessments] 6D-1.2. Examine logs of access to security containers for key components to verify that only the authorized custodian(s) have accessed. …
Modified
p. 103
• Two or more passwords of five characters or more (vendor default values must be changed) • Multiple cryptographic tokens (such as smartcards), or physical keys • Physical access controls Note that for devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. [Applies to CA/RA assessments] 6D-1.3.a Examine documented procedures for loading of clear-text cryptographic keys …
Modified
p. 103
Describe how default dual-control mechanisms were verified to have been disabled or changed: <Report Findings Here> 6D-1.4 Key components for symmetric keys must be combined using a process such that no active bit of the key can be determined without knowledge of the remaining components (e.g., via XOR‘ing of full-length components). The resulting key must only exist within the SCD. Note that concatenation of key components together to form the key is unacceptable; e.g., concatenating two 8-hexadecimal character halves to …
Describe how default dual-control mechanisms were verified to have been disabled or changed: <Report Findings Here> 6D-1.4 Key components for symmetric keys must be combined using a process such that no active bit of the key can be determined without knowledge of the remaining components (e.g., via XOR‘ing of full-length components). The resulting key must only exist within the SCD. Note that concatenation of key components together to form the key is unacceptable; e.g., concatenating two 8-hexadecimal character halves to …
Modified
p. 103
Describe how key-component lengths or device configuration settings verified that key components used to create a key are the same length as the resultant key: <Report Findings Here> 6D-1.5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least double-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits.
Describe how key-component lengths or device configuration settings verified that key components used to create a key are the same length as the resultant key: <Report Findings Here>
Modified
p. 104
<Report Findings Here> 6D-1.6 Any other SCD loaded with the same key components must combine all entered key components using the identical process.
<Report Findings Here> 6D-1.6 Any other SCD loaded with the same key components must combine all entered key components using the identical process. [Applies to CA/RA assessments] 6D-1.6 Through 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.
Modified
p. 104
• The existing TMK to encrypt the replacement TMK for download Keys shall not be reloaded by any methodology in the event of a compromised device, and must be withdrawn from use. 6D-1.7.a Examine documented procedures for the loading of TMKs to verify that they require asymmetric key-loading techniques or manual techniques for initial loading.
Modified
p. 104
• Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device actually has (or actually can) compute the session key, and that no entity other than the POI device specifically identified can possibly compute the session key.
Removed
p. 105
Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of clear-text key components. There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys. The SCD must be inspected prior to use to ensure that it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying material. SCDs must be inspected to detect evidence of monitoring and to ensure dual control procedures are not circumvented during key loading. An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are uniquely identified by the device. 6D-2.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. 105
• Use of public and private key lengths that are in accordance with Annex C for the algorithm in question. • Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question. • Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable.
Modified
p. 105
• Ensure cameras are positioned to ensure they cannot monitor the entering of clear-text key components. • Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: - 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 …
Modified
p. 105
• 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. • There is not any mechanism at the interface (including cabling) between the conveyance medium and the SCD that might disclose the transferred keys. • The SCD is inspected to ensure it has not been subject to …
Modified
p. 106
•e.g., smart card, thumb drive, fob or other devices used for data transport
•to a cryptographic device (and verification of the correct receipt of the component, if applicable) results in either of the following
• The medium is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or • All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement 6F-4. [Applies to CA/RA assessments] 6D-2.3.a Examine documented procedures for the loading of secret or private key components from electronic medium to a cryptographic device. Verify that …
Modified
p. 106
• Instructions for the medium to be placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or • Instructions to erase or otherwise destroy all traces of the component from the electronic medium.
Modified
p. 106
• The medium used for key injection is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or • All traces of the component are erased or otherwise destroyed from the electronic medium.
Modified
p. 106
• The medium used for key injection is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or • All traces of the component are erased or otherwise destroyed from the electronic medium. <Report Findings Here> 6D-2.4 For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device: [Applies to CA/RA assessments] …
Modified
p. 106
6D-2.4.1 The key-loading device must be a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
6D-2.4.1 The key-loading device must be a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected. [Applies to CA/RA assessments]
Modified
p. 107
Describe how processes for the use of key-loading devices verified that 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: <Report Findings Here> 6D-2.4.2 The key-loading device must be 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. 6D-2.4.2 Verify the key-loading device is under the supervision …
Documented procedures reviewed: <Report Findings Here> Describe how processes for the use of key-loading devices verified that 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: <Report Findings Here> 6D-2.4.2 The key-loading device must be 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. [Applies to CA/RA …
Modified
p. 107
Documented procedures reviewed: <Report Findings Here> Describe how processes for the use of key-loading devices verified that 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: <Report Findings Here> 6D-2.4.3 The key-loading device must be designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel …
Documented procedures reviewed: <Report Findings Here> Describe how processes for the use of key-loading devices verified that 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: <Report Findings Here> 6D-2.4.3 The key-loading device must be designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel …
Modified
p. 107
Documented procedures reviewed: <Report Findings Here> Describe how processes for the use of key-loading devices verified that authorized personnel 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> 6D-2.4.4 The key-loading device must not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred.
Documented procedures reviewed: <Report Findings Here> Describe how processes for the use of key-loading devices verified that authorized personnel 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> 6D-2.4.4 The key-loading device must not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred. [Applies to CA/RA assessments]
Modified
p. 108
• removed from secure storage. Key components that can be read (e.g., those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in clear text to a non-custodian for that component. 6D-2.5.a Interview personnel and observe media locations to verify that the media is maintained in a secure location accessible only to custodian(s) authorized to access the key components.
• removed from secure storage. Key components that can be read (e.g., those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in clear text to a non-custodian for that component. [Applies to CA/RA assessments] 6D-2.5.a Interview personnel and observe media locations to verify that the media is maintained in a secure location accessible only to custodian(s) authorized to …
Modified
p. 108
• Requirement that media/devices be in the physical possession of only the designated component holder(s). • The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process.
Modified
p. 108
Key-injection personnel interviewed: <Report Findings Here> Logs examined: <Report Findings Here> 6D-2.6 If the component is in human-readable form, it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
Key-injection personnel interviewed: <Report Findings Here> Logs examined: <Report Findings Here> 6D-2.6 If the component is in human-readable form, it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD. [Applies to CA/RA assessments]
Modified
p. 109
Personnel interviewed: <Report Findings Here> Describe how it was verified 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: <Report Findings Here> 6D-2.7 Written or printed key component documents must not be opened until immediately prior to use.
Personnel interviewed: <Report Findings Here> Describe how it was verified 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: <Report Findings Here> 6D-2.7 Written or printed key component documents must not be opened until immediately prior to use. [Applies to CA/RA assessments] 6D-2.7.a Review documented procedures and confirm that printed/written key component documents are …
Modified
p. 109
Describe how the key-loading processes observed verified that printed/written key component documents are not opened until immediately prior to use: <Report Findings Here> 6D-2.8 A person with access to any component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to …
Describe how the key-loading processes observed verified that printed/written key component documents are not opened until immediately prior to use: <Report Findings Here> 6D-2.8 A person with access to any component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to …
Modified
p. 109
Describe how key-component access controls and access logs verified that any single authorized custodian can only access their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key: <Report Findings Here> 6D-3.1 Any hardware and passwords used in the key-loading function or for the signing of authenticated applications must be controlled and maintained in a secure environment under dual control. Resources (e.g., passwords and associated hardware) must be managed such that no single individual has the capability …
Describe how key-component access controls and access logs verified that any single authorized custodian can only access their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key: <Report Findings Here> 6D-3.1 Any hardware and passwords used in the key-loading function or for the signing of authenticated applications must be controlled and maintained in a secure environment under dual control. Resources (e.g., passwords and associated hardware) must be managed such that no single individual has the capability …
Removed
p. 110
<Report Findings Here> 6D-3.4 Any physical tokens (e.g., brass keys or chip cards) used to enable key loading or the signing of authenticated applications must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control. These tokens must be secured in a manner similar to key components, including the use of access-control logs for when removed or placed into secure storage.
Modified
p. 110
• 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 resources (e.g., passwords and associated hardware) used in the key- loading function or for the signing of authenticated applications must be controlled and managed such that no single individual has the capability to enable key loading of clear-text keys or their components.
Modified
p. 110
• 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 resources (e.g., passwords and associated hardware) used for key- loading functions and for the signing of authenticated applications are controlled and managed such that no single individual has the capability to enable key loading.
Modified
p. 110
• 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 resources (e.g., passwords 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. <Report Findings Here> 6D-3.2 All cable attachments where clear-text keying material traverses must be examined before each key-loading …
Modified
p. 110
Describe how the key-loading processes observed verified that all cable attachments are properly examined prior to key-loading functions or application-signing operations: <Report Findings Here> 6D-3.3 Key-loading equipment usage must be monitored and a log of all key-loading and application-signing activities maintained for audit purposes, containing at a minimum date, time, personnel involved, and number of devices keys are loaded to. 6D-3.3.a Observe key-loading and application-signing activities to verify that key-loading equipment usage is monitored.
Describe how the key-loading processes observed verified that all cable attachments are properly examined prior to key-loading functions or application-signing operations: <Report Findings Here> 6D-3.3 Key-loading equipment usage must be monitored and a log of all key-loading and application-signing activities maintained for audit purposes, containing at a minimum date, time, personnel involved, and number of devices keys are loaded to. [Applies to CA/RA assessments] 6D-3.3.a Observe key-loading and application-signing activities to verify that key-loading equipment usage is monitored.
Modified
p. 111
<Report Findings Here> 6D-3.5 Default passwords or PINs used to enforce dual-control mechanisms must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change. 6D-3.5.a Verify that documented procedures require default passwords or PINs used to enforce dual-control mechanisms are changed.
<Report Findings Here> 6D-3.5 Default passwords or PINs used to enforce dual-control mechanisms must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change. [Applies to CA/RA assessments] 6D-3.5.a Verify that documented procedures require default passwords or PINs used to enforce dual-control mechanisms are changed.
Modified
p. 111
Documented procedures reviewed: <Report Findings Here> 6D-4.1 A cryptographic-based validation mechanism must be in place to ensure the authenticity and integrity of keys and/or their components (e.g., testing key check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO 11568. Where check values are used, recorded or displayed key-component check values and key check values shall not exceed six hexadecimal characters in length. 6D-4.1.a Examine documented procedures to verify …
Documented procedures reviewed: <Report Findings Here> 6D-4.1 A cryptographic-based validation mechanism must be in place to ensure the authenticity and integrity of keys and/or their components (e.g., testing key check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO 11568. Where check values are used, recorded or displayed key-component check values and key check values shall not exceed six hexadecimal characters in length. [Applies to CA/RA assessments]
Removed
p. 112
<Report Findings Here> 6D-5.2 All key-loading events must be documented. Audit trails must be in place for all key-loading events.
Modified
p. 112
• Have a MAC (message authentication code) created using the algorithm defined in ISO 16609 [Applies to CA/RA assessments] 6D-4.2.a Interview personnel and review documented procedures to verify that all public keys exist only in an approved form.
Modified
p. 112
Describe how public-key stores and mechanisms verified that public keys exist only in an approved form: <Report Findings Here> 6D-5.1 Documented key-loading procedures must exist for all devices (e.g., HSMs and POI devices), and all parties involved in cryptographic key loading must be aware of those procedures. 6D-5.1.a Verify documented procedures exist for all key-loading operations. Documented procedures reviewed: <Report Findings Here> 6D-5.1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties …
Describe how public-key stores and mechanisms verified that public keys exist only in an approved form: <Report Findings Here> 6D-5.1 Documented key-loading procedures must exist for all devices (e.g., HSMs and POI devices), and all parties involved in cryptographic key loading must be aware of those procedures. [Applies to CA/RA assessments] 6D-5.1.a Verify documented procedures exist for all key-loading operations. Documented procedures reviewed: <Report Findings Here> 6D-5.1.b Interview responsible personnel to verify that the documented procedures are known and understood …
Modified
p. 113
• Not be given to any other entity or logically separate systems. 6E-1.1.a Examine the documented key matrix and operational procedures and interview personnel to determine whether any keys are shared between organizations or logically separate systems. For all keys shared between two organizations or logically separate systems for encrypting account data (including key-encryption keys used to encrypt a data- encryption key) perform the following:
Modified
p. 114
• 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.) • Proactive safeguards that shut down the source of any synchronization errors and start an investigative process to determine the true cause of the event.
Modified
p. 114
Documented procedures reviewed: <Report Findings Here> 6E-2.2 To prevent or detect usage of a compromised key, key-component packaging or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist. 6E-2.2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering must result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
Documented procedures reviewed: <Report Findings Here> 6E-2.2 To prevent or detect usage of a compromised key, key-component packaging or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist. [Applies to CA/RA assessments] 6E-2.2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering must result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all …
Modified
p. 114
Personnel interviewed: <Report Findings Here> Describe how the processes observed verified that procedures are implemented to require that key-component packaging/containers showing signs of tampering result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist: <Report Findings Here> 6E-3.1 Encryption keys must only be used for the purpose they were intended (i.e., key-encryption keys must not be used as PIN-encryption keys, PIN-encryption keys must not be used for account-data, …
Personnel interviewed: <Report Findings Here> Describe how the processes observed verified that procedures are implemented to require that key-component packaging/containers showing signs of tampering result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist: <Report Findings Here> 6E-3.1 Encryption keys must only be used for the purpose they were intended (i.e., key-encryption keys must not be used as PIN-encryption keys, PIN-encryption keys must not be used for account-data, …
Modified
p. 114
Sample of device types reviewed: <Report Findings Here> Describe how review of check values, terminal definition files, etc. verified that keys used for key encipherment or PIN encipherment are not used for any other purpose: <Report Findings Here>
Sample of device types reviewed: <Report Findings Here> Describe how review of check values, terminal definition files, etc. verified that keys used for key encipherment or PIN encipherment are not used for any other purpose:
Modified
p. 115
• 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). • Private keys must never be used to encrypt other keys. [Applies to CA/RA assessments] 6E-3.2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only used as follows:
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices). • Private keys must never be used to encrypt other keys. [Applies to CA/RA assessments] 6E-3.2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only used as follows:
Modified
p. 115
• For a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both. • Private keys are never used to encrypt other keys.
•a private key must only be used for either decryption or for creating digital signatures, but not both. • Private keys are never used to encrypt other keys.
Modified
p. 115
<Report Findings Here> 6E-3.3 Public keys must only be used for a single purpose•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for transaction-originating POI devices). 6E-3.3 Examine key-management documentation and interview key custodian and key-management supervisory personnel to verify that public keys are only used:
<Report Findings Here> 6E-3.3 Public keys must only be used for a single purpose•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for transaction-originating POI devices). [Applies to CA/RA assessments] 6E-3.3 Examine key-management documentation and interview key custodian and key-management supervisory personnel to verify that public keys are only used:
Modified
p. 115
• 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).
•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI devices).
Modified
p. 115
• Keys used for testing must never be present or used in a production system. Note: For logically partitioned HSMs and computing platforms, if one or more logical partitions of a physical device are used for production and one or more other logical partitions are used for testing, including QA or similar, the entire configuration must be managed and controlled as production. [Applies to CA/RA assessments] 6E-3.4.a Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify …
Modified
p. 115
Describe how the observed processes for generating and loading keys into production systems verified that they are in no way associated with test or development keys: <Report Findings Here> 6E-3.4.c Observe processes for generating and loading keys into test systems to ensure that they are in no way associated with production keys.
Describe how the observed processes for generating and loading keys into production systems verified that they are in no way associated with test or development keys:
Modified
p. 115 → 116
Describe how the observed processes for generating and loading keys into test systems verified that they are in no way associated with production keys: <Report Findings Here>
Describe how the observed processes for generating and loading keys into test systems verified that they are in no way associated with production keys: <Report Findings Here> 6E-3.4.d Compare check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.
Modified
p. 116
• All keying material is deleted from the HSM(s) and the server /computer platforms prior to testing. • 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. 116
Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6E-4.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. Disclosure of the key in one such device must not provide any information that could be feasibly used to determine the key …
Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6E-4.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. Disclosure of the key in one such device must not provide any information that could be feasibly used to determine the key …
Modified
p. 116 → 117
• Known only to HSMs at the minimum number of facilities consistent with effective system operations.
Modified
p. 117
• Examine documented procedures for generating all types of keys and verify the procedures ensure that unique keys or sets of keys are used for each acquiring organization and totally independent and are not variants of one another.
Removed
p. 118
At least two separate key shares or full-length components Encrypted with a key of equal or greater strength as delineated in Annex C Contained within a secure cryptographic device Note for hybrid decryption solutions: Clear-text Data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data.
Modified
p. 118
• 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.
Modified
p. 118
• 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. <Report Findings Here> 6E-4.3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device.
Modified
p. 118
• Different BDKs by geographic region, market segment, platform, or sales unit Injection vendors must use at least one unique Base Derivation Key (BDK) per acquiring organization, and must be able to support segmentation of multiple BDKS of acquiring organizations. 6E-4.4 Determine whether the entity processing or injecting DUKPT or other key-derivation methodologies does so on behalf of multiple acquiring organizations. If so:
Modified
p. 118
• Interview personnel and review documented procedures to determine that unique Base Derivation Keys are used for each acquiring organization. • Observe key-injection processes for devices associated with different acquiring organizations to verify that Base Derivation Key(s) unique to each organization are used.
Modified
p. 119
Describe how the observed key stores verified that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions): <Report Findings Here> 6F-1.2 Wherever key components are used, they have the following properties:
Describe how the observed key stores verified that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions): <Report Findings Here> 6F-1.2 Wherever key components are used, they have the following properties: [Applies to CA/RA assessments] 6F-1.2 Examine documented procedures and interview responsible personnel to determine all instances where key components are used. Perform the following wherever key components …
Modified
p. 119
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6F-1.2.1 Knowledge of any one key component/share does not convey any knowledge of any part of the actual cryptographic key.
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6F-1.2.1 Knowledge of any one key component/share does not convey any knowledge of any part of the actual cryptographic key. [Applies to CA/RA assessments] 6F-1.2.1 Review processes for creating key components and examine key components to verify that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key.
Modified
p. 119
Describe how the processes for creating key components and the examined key components verified that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key: <Report Findings Here> 6F-1.2.2 Construction of the cryptographic key requires the use of at least two key components/shares.
Describe how the processes for creating key components and the examined key components verified that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key: <Report Findings Here> 6F-1.2.2 Construction of the cryptographic key requires the use of at least two key components/shares. [Applies to CA/RA assessments] 6F-1.2.2 Observe processes for constructing cryptographic keys to verify that at least two key components/shares are required for each key construction.
Modified
p. 119
Describe how the observed processes for constructing keys verified that at least two key components/shares are required for each key construction: <Report Findings Here> 6F-1.2.3 Each key component/share has one or more specified authorized custodians.
Describe how the observed processes for constructing keys verified that at least two key components/shares are required for each key construction: <Report Findings Here> 6F-1.2.3 Each key component/share has one or more specified authorized custodians. [Applies to CA/RA assessments] 6F-1.2.3.a Examine documented procedures for the use of key components and interview key custodians and key-management supervisory personnel to verify that each key component is assigned to a specific individual, or set of individuals, who are designated as key custodians for …
Modified
p. 120
Describe how the observed key-component access controls and key-custodian authorizations/assignments verified that all individuals with access to key components are designated as key custodians for those particular components: <Report Findings Here> 6F-1.2.4 Procedures exist to ensure any custodian never has access to sufficient key components or shares to reconstruct a secret or private key cryptographic key. For example, in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), where only two of any three components are …
Describe how the observed key-component access controls and key-custodian authorizations/assignments verified that all individuals with access to key components are designated as key custodians for those particular components: <Report Findings Here> 6F-1.2.4 Procedures exist to ensure any custodian never has access to sufficient key components or shares to reconstruct a secret or private key cryptographic key. For example, in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), where only two of any three components are …
Modified
p. 120
Describe how the key-component access controls and access logs examined verified that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key: <Report Findings Here> 6F-1.3 Key components must be stored as follows:
Describe how the key-component access controls and access logs examined verified that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key: <Report Findings Here> 6F-1.3 Key components must be stored as follows: [Applies to CA/RA assessments] 6F-1.3 Examine documented procedures, interview responsible personnel and inspect key-component storage locations to verify that key components are stored as outlined in Requirements 6F-1.3.1 through 6F-1.3.3 below:
Modified
p. 120
• used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card, contactless card, or other media that can be read without direct physical contact, the packaging should be designed to prevent such access to the key …
• used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card, contactless card, or other media that can be read without direct physical contact, the packaging should be designed to prevent such access to the key …
Modified
p. 120
Describe how the key components and storage locations examined verified that components are stored in opaque, pre-numbered, tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging: <Report Findings Here>
Describe how the key components and storage locations examined verified that components are stored in opaque, pre-numbered, tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging:
Modified
p. 121
<Report Findings Here> 6F-1.3.2 Key components for each specific custodian must be stored in a separate secure container that is accessible only by the custodian and/or designated backup(s). Note: Furniture-based locks or containers with a limited set of unique keys
•e.g., desk drawers
•are not sufficient to meet this requirement. Components for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers. 6F-1.3.2 …
•e.g., desk drawers
•are not sufficient to meet this requirement. Components for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers. 6F-1.3.2 …
<Report Findings Here> 6F-1.3.2 Key components for each specific custodian must be stored in a separate secure container that is accessible only by the custodian and/or designated backup(s). Note: Furniture-based locks or containers with a limited set of unique keys
•e.g., desk drawers
•are not sufficient to meet this requirement. Components for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers. [Applies …
•e.g., desk drawers
•are not sufficient to meet this requirement. Components for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers. [Applies …
Modified
p. 121
<Report Findings Here> 6F-1.3.3 If a key is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner (or designated backup(s)) must have possession of both the token and its access code. 6F-1.3.3 Interview responsible personnel and observe implemented processes to verify that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, …
<Report Findings Here> 6F-1.3.3 If a key is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner (or designated backup(s)) must have possession of both the token and its access code. [Applies to CA/RA assessments] 6F-1.3.3 Interview responsible personnel and observe implemented processes to verify that if a key is stored on a token, and an access code (PIN or similar mechanism) is used …
Modified
p. 121
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner
•or designated backup(s)
•has possession of both the token and its access code:<Report Findings Here>
•or designated backup(s)
•has possession of both the token and its access code:
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner
•or designated backup(s)
•has possession of both the token and its access code:
•or designated backup(s)
•has possession of both the token and its access code:
Modified
p. 123
• Processing with that key is halted, and the key is replaced with a new unique key. • 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. • The replacement key must not be a variant of the original key, or an irreversible transformation of the original key.
Modified
p. 123
• Processing with that key is halted, and the key is replaced with a new unique key. • 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. • The replacement key must not be a variant of the original key, or an irreversible transformation of the original key. <Report Findings Here> 6F-2.1.4 A documented escalation process and notification to organizations …
Modified
p. 123
• Specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc. 6F-2.1.4.a Interview responsible personnel and observe implemented processes to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
Modified
p. 123
• A damage assessment including, where necessary, the engagement of outside consultants • Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Removed
p. 124
Missing secure cryptographic devices Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation Host System tamper-detection mechanism has been activated, for hybrid decryption solutions 6F-2.1.5 Interview responsible personnel and review documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
Modified
p. 124
• Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries • Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate • Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities • Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of …
Modified
p. 125
Describe how the observed processes verified that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge: <Report Findings Here> 6F-3.2 An MFK used by host processing systems for encipherment of keys for local storage
•and variants of the MFK
•must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local …
•and variants of the MFK
•must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local …
Describe how the observed processes verified that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge: <Report Findings Here> 6F-3.2 An MFK used by host processing systems for encipherment of keys for local storage
•and variants of the MFK
•must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local …
•and variants of the MFK
•must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local …
Modified
p. 126
• Variants used as KEKs must only be calculated from other key-encrypting keys • Variants of working keys must only be calculated from other working keys.
Modified
p. 126
• Variants used as KEKs must only be calculated from other key-encrypting keys • Variants of working keys must only be calculated from other working keys. <Report Findings Here> 6F-4.1 Instances of secret or private keys, and their key components, that are no longer used or that have been
Modified
p. 126
6F-4.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.
• replaced by a new key must be destroyed. [Applies to CA/RA assessments] 6F-4.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
Modified
p. 127
Describe how the key-destruction processes observed verified that no part of the key or component can be recovered: <Report Findings Here> 6F-4.2.1 Keys on all other storage media types in all permissible forms
•physically secured, enciphered (except for electronic database backups of cryptograms), or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568. For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder. 6F-4.2.1.a Examine documented procedures for destroying …
•physically secured, enciphered (except for electronic database backups of cryptograms), or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568. For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder. 6F-4.2.1.a Examine documented procedures for destroying …
Describe how the key-destruction processes observed verified that no part of the key or component can be recovered: <Report Findings Here> 6F-4.2.1 Keys on all other storage media types in all permissible forms
•physically secured, enciphered (except for electronic database backups of cryptograms), or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568. For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder. [Applies to CA/RA assessments] 6F-4.2.1.a Examine …
•physically secured, enciphered (except for electronic database backups of cryptograms), or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568. For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder. [Applies to CA/RA assessments] 6F-4.2.1.a Examine …
Modified
p. 127
Describe how the key-destruction processes observed verified that keys on all other storage media types in all permissible forms
•physically secured, enciphered, or component
•are destroyed following the procedures outlined in ISO
•9564 or ISO
•11568: <Report Findings Here> 6F-4.2.2 The key-destruction process must be observed by a third party other than the custodians of any component of that key•i.e., the third party must not be a key custodian for any part of the key being destroyed. The third-party witness must sign an affidavit …
•physically secured, enciphered, or component
•are destroyed following the procedures outlined in ISO
•9564 or ISO
•11568: <Report Findings Here> 6F-4.2.2 The key-destruction process must be observed by a third party other than the custodians of any component of that key•i.e., the third party must not be a key custodian for any part of the key being destroyed. The third-party witness must sign an affidavit …
Describe how the key-destruction processes observed verified that keys on all other storage media types in all permissible forms
•physically secured, enciphered, or component
•are destroyed following the procedures outlined in ISO
•9564 or ISO
•11568: <Report Findings Here> 6F-4.2.2 The key-destruction process must be observed by a third party other than the custodians of any component of that key•i.e., the third party must not be a key custodian for any part of the key being destroyed. The third-party witness must sign an affidavit …
•physically secured, enciphered, or component
•are destroyed following the procedures outlined in ISO
•9564 or ISO
•11568: <Report Findings Here> 6F-4.2.2 The key-destruction process must be observed by a third party other than the custodians of any component of that key•i.e., the third party must not be a key custodian for any part of the key being destroyed. The third-party witness must sign an affidavit …
Modified
p. 127
Key-destruction logs inspected: <Report Findings Here> 6F-4.3 Key components for keys other than the HSM MFK 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. 6F-4.3.a Verify documented procedures exist for destroying key components of keys once the …
Key-destruction logs inspected: <Report Findings Here> 6F-4.3 Key components for keys other than the HSM MFK 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. [Applies to CA/RA assessments]
Removed
p. 128
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date and time for the custodian’s access Signature of management authorizing the access
Modified
p. 128
Describe how the key-conveyance/loading processes observed verified that any key components are destroyed once the keys are successfully loaded and validated as operational: <Report Findings Here> 6F-5.1 To reduce the opportunity for key compromise, limit the number of key custodians to a minimum required for operational efficiency. For example: 6F-5.1 Interview key custodians and key-management supervisory personnel and observe implemented processes to verify the following:
Describe how the key-conveyance/loading processes observed verified that any key components are destroyed once the keys are successfully loaded and validated as operational: <Report Findings Here> 6F-5.1 To reduce the opportunity for key compromise, limit the number of key custodians to a minimum required for operational efficiency. For example: [Applies to CA/RA assessments] 6F-5.1 Interview key custodians and key-management supervisory personnel and observe implemented processes to verify the following:
Modified
p. 128
<Report Findings Here> 6F-5.1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. . Key custodians must be employees or contracted personnel. 6F-5.1.1 Review key-custodian assignments for each component to verify that:
<Report Findings Here> 6F-5.1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. . Key custodians must be employees or contracted personnel. [Applies to CA/RA assessments] 6F-5.1.1 Review key-custodian assignments for each component to verify that:
Modified
p. 128
• The fewest number of key custodians is assigned as necessary to enable effective key management. • Assigned key custodians are employees or contracted personnel.
Modified
p. 128
• A primary and a backup key custodian are designated for each component. • The fewest number of key custodians is assigned as necessary to enable effective key management. • Assigned key custodians are employees or contracted personnel. <Report Findings Here> 6F-5.1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form. [Applies to CA/RA assessments] 6F-5.1.2.a Examine completed key-custodian forms to verify that key custodians sign the form.
Modified
p. 129 → 128
• Specific authorization for the custodian • Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them • Signature of the custodian acknowledging their responsibilities • An effective date and time for the custodian’s access • Signature of management authorizing the access [Applies to CA/RA assessments]
• Specific authorization for the custodian
• Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them
• Signature of the custodian acknowledging their responsibilities
• …
• Specific authorization for the custodian
• Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them
• Signature of the custodian acknowledging their responsibilities
• …
Modified
p. 129
<Report Findings Here> 6F-5.1.4 In order for key custodians to be free from undue influence in discharging their custodial duties, key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual except as noted below for organizations of insufficient size. For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), …
<Report Findings Here> 6F-5.1.4 In order for key custodians to be free from undue influence in discharging their custodial duties, key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual except as noted below for organizations of insufficient size. For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), …
Modified
p. 129
• Key custodians that form the necessary threshold to create a key do not directly report to the same individual. • Neither direct reports nor the direct reports in combination with their immediate supervisor possess the necessary threshold of key components sufficient to form any given key.
Modified
p. 129
• Receive explicit training to instruct them from sharing key components with their direct manager. • Sign key-custodian agreement that includes an attestation to the requirement. • Ensure training includes whistleblower procedures to report any violations.
Removed
p. 130
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable) 6F-6.1.a Review log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:
Modified
p. 130
• Loaded to an SCD Log files reviewed: <Report Findings Here> Describe how log files and audit log settings verified that logs are kept for any time that keys, key components, or related materials are:
Modified
p. 130
• Loaded to an SCD <Report Findings Here> 6F-6.1.b Review log files and audit log settings to verify that logs include the following:
Modified
p. 130
• Tamper-evident package number (if applicable) Log files reviewed: <Report Findings Here> Describe how log files and audit log settings verified that logs include the following:
Modified
p. 130
• Tamper-evident package number (if applicable) <Report Findings Here> 6F-7.1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as are followed for the primary keys. [Applies to CA/RA assessments] 6F-7.1 Interview responsible personnel and examine documented procedures and backup records to determine whether any backup copies of keys or their components exist. Perform the following:
Removed
p. 131
Security-awareness training Role definition•nominated individual with overall responsibility Background checks for personnel (within the constraints of local laws) Management of personnel changes, including revocation of access control and other privileges when personnel move
Modified
p. 131
• Subject to at least the same level of security control as operational keys as specified in this document Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> OR Describe how backup storage locations verified that backups are maintained as follows:
Modified
p. 131
• Subject to at least the same level of security control as operational keys as specified in this document <Report Findings Here> 6F-7.2 If backup copies are created, the following must be in place:
Modified
p. 131
•e.g., MFKs
•must require a minimum of two authorized individuals to enable the process.
• Creation (including cloning) of top-level keys
•e.g., MFKs
•must require a minimum of two authorized individuals to enable the process.
•e.g., MFKs
•must require a minimum of two authorized individuals to enable the process.
Modified
p. 131
• The creation of any backup copies for top-level keys requires at least two authorized individuals to enable the process • All requirements applicable for the original keys also apply to any backup copies of keys and their components.
Modified
p. 131
• The creation of any backup copies for top-level keys requires at least two authorized individuals to enable the process • All requirements applicable for the original keys also apply to any backup copies of keys and their components. <Report Findings Here> 6F-8.1 Written procedures must exist and all affected parties must be aware of those procedures. All activities related to key administration must be documented. This includes all aspects of key administration, as well as:
Modified
p. 132
• Management of personnel changes, including revocation of access control and other privileges when personnel move Documented procedures reviewed: <Report Findings Here> 6F-8.1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
Modified
p. 132
<Report Findings Here> 6G-1.1 Secure cryptographic devices
•such as HSMs and POI devices
•must be placed into service only if there is assurance that the equipment has not been subjected to unauthorized modifications, substitution, or tampering and has not otherwise been subject to misuse prior to deployment. 6G-1.1.a Review documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys:
•such as HSMs and POI devices
•must be placed into service only if there is assurance that the equipment has not been subjected to unauthorized modifications, substitution, or tampering and has not otherwise been subject to misuse prior to deployment. 6G-1.1.a Review documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys:
<Report Findings Here> 6G-1.1 Secure cryptographic devices
•such as HSMs and POI devices
•must be placed into service only if there is assurance that the equipment has not been subjected to unauthorized modifications, substitution, or tampering and has not otherwise been subject to misuse prior to deployment. [Applies to CA/RA assessments] 6G-1.1.a Review documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys:
•such as HSMs and POI devices
•must be placed into service only if there is assurance that the equipment has not been subjected to unauthorized modifications, substitution, or tampering and has not otherwise been subject to misuse prior to deployment. [Applies to CA/RA assessments] 6G-1.1.a Review documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys:
Modified
p. 133
Documented procedures reviewed: <Report Findings Here> 6G-1.1.1.1 Access to all POI devices, and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection. 6G-1.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.
Documented procedures reviewed: <Report Findings Here> 6G-1.1.1.1 Access to all POI devices, and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection. [Applies to CA/RA assessments] 6G-1.1.1.1.a Examine access-control documentation and device configurations to verify that access to all POI devices and key injection/loading devices is defined and documented.
Modified
p. 133
Describe how the implemented access controls examined verified that unauthorized individuals cannot access, modify, or substitute any POI device or other SCD: <Report Findings Here> 6G-1.1.1.2 POI devices and other SCDs must not use default keys (such as keys that are pre-installed for testing purposes), passwords, or data.
Describe how the implemented access controls examined verified that unauthorized individuals cannot access, modify, or substitute any POI device or other SCD: <Report Findings Here> 6G-1.1.1.2 POI devices and other SCDs must not use default keys (such as keys that are pre-installed for testing purposes), passwords, or data. [Applies to CA/RA assessments] 6G-1.1.1.2 Examine vendor documentation or other information sources to identify default keys (such as keys that are pre-installed for testing purposes), passwords, or data. Observe implemented processes and …
Modified
p. 133
<Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how the implemented processes examined verified that default keys, passwords or data are not used: <Report Findings Here>
<Report Findings Here> Personnel interviewed: <Report Findings Here> Describe how the implemented processes examined verified that default keys, passwords or data are not used:
Modified
p. 134
• All personnel with access to POI devices and other SCDs are documented in a formal list. • All personnel with access to POI devices and other SCDs are authorized by management. • The authorizations are reviewed annually.
Modified
p. 135
<Report Findings Here> 6G-1.4.1 HSM serial numbers must be compared to the serial numbers documented by the sender (sent using a different communication channel from the device) to ensure device substitution has not occurred. A record of device serial-number validations must be maintained. Note: Documents used for this process must be received via a different communication channel•i.e., the control document used must not have arrived with the equipment. An example of how serial numbers may be documented by the sender …
<Report Findings Here> 6G-1.4.1 HSM serial numbers must be compared to the serial numbers documented by the sender (sent using a different communication channel from the device) to ensure device substitution has not occurred. A record of device serial-number validations must be maintained. Note: Documents used for this process must be received via a different communication channel•i.e., the control document used must not have arrived with the equipment. An example of how serial numbers may be documented by the sender …
Modified
p. 135
<Report Findings Here> 6G-1.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. Note: Examples of sensitive functions include but are not limited to: loading of key components, outputting clear-text key components, and altering HSM configuration. 6G-1.4.3 Examine HSM configurations and observe processes to verify that HSMs are not enabled in a sensitive state when connected to …
<Report Findings Here> 6G-1.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. Note: Examples of sensitive functions include but are not limited to: loading of key components, outputting clear-text key components, and altering HSM configuration. [Applies to CA/RA assessments]
Modified
p. 135 → 136
Describe how the HSM configurations examined and processes observed verified that HSMs are not enabled in a sensitive state when connected to online systems: <Report Findings Here>
Describe how the HSM configurations examined and processes observed verified that HSMs are not enabled in a sensitive state when connected to online systems: <Report Findings Here> 6G-1.4.4 Inspect and test all HSMs
•either new or retrieved from secure storage
•prior to installation to verify devices have not been tampered with or compromised. Processes must include: [Applies to CA/RA assessments] 6G-1.4.4.a Examine documented procedures to verify they require inspection and testing of HSMs prior to installation to verify integrity of device and …
•either new or retrieved from secure storage
•prior to installation to verify devices have not been tampered with or compromised. Processes must include: [Applies to CA/RA assessments] 6G-1.4.4.a Examine documented procedures to verify they require inspection and testing of HSMs prior to installation to verify integrity of device and …
Modified
p. 136
Documented procedures reviewed: <Report Findings Here> 6G-1.4.4.1 Running self-tests to ensure the correct operation of the device.
Documented procedures reviewed: <Report Findings Here> 6G-1.4.4.1 Running self-tests to ensure the correct operation of the device. [Applies to CA/RA assessments] 6G-1.4.4.1 Examine records of device inspections and test results to verify that self-tests are run on devices to ensure the correct operation of the device.
Modified
p. 136
<Report Findings Here> Describe how the records of device inspections and test results examined verified that self-tests are run on devices to ensure the correct operation of the device: <Report Findings Here> 6G-1.4.4.2 Installing (or re-installing) devices only after confirming that the device has not been tampered with or compromised.
<Report Findings Here> Describe how the records of device inspections and test results examined verified that self-tests are run on devices to ensure the correct operation of the device: <Report Findings Here> 6G-1.4.4.2 Installing (or re-installing) devices only after confirming that the device has not been tampered with or compromised. [Applies to CA/RA assessments] 6G-1.4.4.2 Observe inspection processes and interview responsible personnel to verify that devices are installed, or reinstalled, only after confirming that the device has not been tampered …
Modified
p. 136
• removed 6G-1.4.4.3 Observe inspection processes and interview responsible personnel to confirm processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not
• removed [Applies to CA/RA assessments] 6G-1.4.4.3 Observe inspection processes and interview responsible personnel to confirm processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not
Modified
p. 136
Responsible personnel interviewed: <Report Findings Here> Describe how the inspection processes observed verified that processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not modified or removed: <Report Findings Here> 6G-1.4.4.4 Maintaining records of the tests and inspections, and retaining records for at least one year.
Responsible personnel interviewed: <Report Findings Here> Describe how the inspection processes observed verified that processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not modified or removed:
Modified
p. 136 → 137
Records of inspections examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here>
Records of inspections examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6G-1.4.4.4.b Examine records of inspections to verify records are retained for at least one year.
Modified
p. 137
Records of inspections examined: <Report Findings Here> 6G-1.4.5 Maintain HSMs in tamper-evident packaging or in secure storage until ready for installation.
Records of inspections examined: <Report Findings Here> 6G-1.4.5 Maintain HSMs in tamper-evident packaging or in secure storage until ready for installation. [Applies to CA/RA assessments] 6G-1.4.5.a Examine documented procedures to verify they require devices be maintained in tamper-evident packaging until ready for installation.
Modified
p. 137
• removed from the network. 6G-3.1 Verify that documented procedures for removing SCDs from service include the following:
• removed from the network. [Applies to CA/RA assessments] 6G-3.1 Verify that documented procedures for removing SCDs from service include the following:
Modified
p. 137
• Procedures require that all keys and key material, and all account data stored within the device be securely destroyed. • Procedures cover all devices removed from service permanently or for repair. • Procedures cover requirements at 6G-3.1.1 through 6G-3.1.6 below.
Modified
p. 137
Documented procedures reviewed: <Report Findings Here> 6G-3.1.1 HSMs require dual control (e.g., to invoke the system menu) to implement all critical decommissioning processes.
Documented procedures reviewed: <Report Findings Here> 6G-3.1.1 HSMs require dual control (e.g., to invoke the system menu) to implement all critical decommissioning processes. [Applies to CA/RA assessments] 6G-3.1.1.a Review documented procedures for removing HSMs from service to verify that dual control is implemented for all critical decommissioning processes.
Modified
p. 137
Documented procedures reviewed: <Report Findings Here> 6G-3.1.1.b Interview personnel and observe demonstration (if HSM is available) of processes for removing HSMs from service to verify that dual control is implemented for all critical decommissioning processes.
Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here>
Modified
p. 137 → 138
Describe how the demonstration of processes for removing HSMs from service verified that dual control is implemented for all critical decommissioning processes: <Report Findings Here> 6G-3.1.2 Keys and account data are rendered irrecoverable (e.g., zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual control to prevent the disclosure of any sensitive data or keys. [Applies to CA/RA assessments] 6G-3.1.2 Interview personnel and observe demonstration of processes for removing SCDs from service to verify …
Modified
p. 138
Personnel interviewed: <Report Findings Here> Describe how the demonstration of processes for removing SCDs from service verified that all keying material and account data are rendered irrecoverable, or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys: <Report Findings Here> 6G-3.1.3 SCDs being decommissioned are tested and inspected to ensure keys and account data have been rendered irrecoverable.
Personnel interviewed: <Report Findings Here> Describe how the demonstration of processes for removing SCDs from service verified that all keying material and account data are rendered irrecoverable, or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys: <Report Findings Here> 6G-3.1.3 SCDs being decommissioned are tested and inspected to ensure keys and account data have been rendered irrecoverable. [Applies to CA/RA assessments] 6G-3.1.3 Interview personnel and observe processes for removing SCDs …
Modified
p. 138
Personnel interviewed: <Report Findings Here> Describe how the observed processes for removing SCDs from service verified that tests and inspections of devices are performed to confirm that keys and account data have been rendered irrecoverable: <Report Findings Here> 6G-3.1.4 Affected entities are notified before devices are returned.
Personnel interviewed: <Report Findings Here> Describe how the observed processes for removing SCDs from service verified that tests and inspections of devices are performed to confirm that keys and account data have been rendered irrecoverable: <Report Findings Here> 6G-3.1.4 Affected entities are notified before devices are returned. [Applies to CA/RA assessments] 6G-3.1.4 Interview responsible personnel and examine device-return records to verify that affected entities are notified before devices are returned.
Modified
p. 138
Responsible personnel interviewed: <Report Findings Here> Device-return records examined: <Report Findings Here> 6G-3.1.5 Devices are tracked during the return process.
Responsible personnel interviewed: <Report Findings Here> Device-return records examined: <Report Findings Here> 6G-3.1.5 Devices are tracked during the return process. [Applies to CA/RA assessments] 6G-3.1.5 Interview responsible personnel and examine device-return records to verify that devices are tracked during the return process.
Modified
p. 138
Responsible personnel interviewed: <Report Findings Here> Device-return records examined: <Report Findings Here> 6G-3.1.6 Records of the tests and inspections are maintained for at least one year.
Responsible personnel interviewed: <Report Findings Here> Device-return records examined: <Report Findings Here> 6G-3.1.6 Records of the tests and inspections are maintained for at least one year. [Applies to CA/RA assessments]
Modified
p. 139 → 140
• To place the device into a state that allows for the input or output of clear- text key components; • For all access to KLDs and authenticated application-signing devices.
Modified
p. 140 → 139
• To enable any manual key-encryption functions and any key-encryption functions that occur outside of normal transaction processing;
Modified
p. 140
• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing; • To enable application-signing functions; • To place the device into a state that allows for the input or output of clear- text key components; • For all access to KLDs and authenticated application-signing devices. <Report Findings Here> 6G-4.1.3 Devices must not use default passwords.
Modified
p. 140
• Under the continuous supervision of at least two authorized people who ensure that any unauthorized use of the device would be detected. 6G-4.1.4.a Examine documented procedures to confirm that they require devices are at all times within a secure room and either:
Modified
p. 141
• Locked in a secure cabinet and/or sealed in tamper-evident packaging at all times, or • Under the continuous supervision of at least two authorized people at all times. <Report Findings Here> 6G-5.1 Written procedures must exist, and all affected parties must be aware of those procedures. Records must be maintained of the tests and inspections performed on account-data processing devices before they are placed into service, as well as devices being decommissioned. [Applies to CA/RA assessments] 6G-5.1.a Examine documented …
Modified
p. 141
• Each DDK must have a defined usage period (cryptoperiod) based on a formal risk assessment and industry guidance as provided in NIST SP800-57, ISO TR 14742 and NIST SP800-131. The cryptoperiod defines the duration of time that the DDK may be used to decrypt account data, defined either as a maximum threshold of transactions, or hours, or both (e.g., 1024 transactions or 24 hours, whichever is reached first). • Upon reaching the defined usage threshold, the DDK must not …
Modified
p. 141
OR DDKs are unique per transaction. Each DDK is erased from the host memory upon completion of the decryption process.
OR • DDKs are unique per transaction. Each DDK is erased from the host memory upon completion of the decryption process.
Modified
p. 142
OR DDKs are unique per transaction. Each DDK is erased from the host memory upon completion of the decryption process.
OR • DDKs are unique per transaction. Each DDK is erased from the host memory upon completion of the decryption process.
Modified
p. 142
• Each DDK must have a defined usage period (cryptoperiod) based on a formal risk assessment and industry guidance as provided in NIST SP800- 57, ISO TR 14742 and NIST SP800-131. The cryptoperiod defines the duration of time that the DDK may be used to decrypt account data, defined either as a maximum threshold of transactions, or hours, or both (e.g., 1024 transactions or 24 hours, whichever is reached first). • Upon reaching the defined usage threshold, the DDK must …
Modified
p. 142
• The master key used to generate the DDK must be dedicated to generating DDKs. 6H-1.3.a Examine key-management policies and procedures to verify that the following is required for any DDKs generated from a master key:
Modified
p. 142
• The master key used to generated the DDK must be dedicated to generating DDKs.
Modified
p. 143
• The master key used to generate the DDK is dedicated to generating DDKs.
Modified
p. 143
• The master key used to generate the DDK is dedicated to generating DDKs. <Report Findings Here> 6H-1.4 The DDK must be encrypted between the HSM and the Host System, e.g., using a fixed transport key or a cryptographic protocol. The method of encryption used must maintain the security policy to which the HSM was approved (either FIPS140-2, Level 3 or higher, or approved to the PCI HSM standard). 6H-1.4.a Examine key-management policies and procedures to verify that DDKs must …
Modified
p. 145
• Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Note that 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. 6I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider …
• Details of any known or suspected compromised keys, per 6F-2.1 Note that 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. 6I-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 …
Modified
p. 145
• Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Documented component provider procedures reviewed:
• Details of any known or suspected compromised keys, per 6F-2.1 Documented component provider procedures reviewed:
Modified
p. 145
• Types/models of POIs for which keys have been injected
Modified
p. 145
• Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Solution provider reports reviewed: <Report Findings Here>
• Details of any known or suspected compromised keys, per 6F-2.1 Solution provider reports reviewed: <Report Findings Here>
Modified
p. 147
• POI devices must validate authentication credentials of KDHs 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.
Modified
p. 148
• POI devices validate authentication credentials of KDHs 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.
Modified
p. 148
• Within an implementation design, there shall 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. 148
• There are no means available in the implementation design for “man-in- the-middle” attacks. • System implementations are designed to prevent replay attacks.
Modified
p. 148
• 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. • Observe key transfer and loading operations to verify that the secrecy of private keys and the integrity of the public keys are ensured. • Verify the process ensures that key pairs are unique per POI device.
Modified
p. 148
• 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; • POIs only communicate with KDHs for key management, normal transaction processing, and certificate (entity) status checking.
Modified
p. 149
• 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; • POIs only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking.
Modified
p. 149
• KDHs only communicate with POIs for the purpose of key management and normal transaction processing; • KDHs only to communicate with CAs for the purpose of certificate signing and certificate (entity) status checking.
Modified
p. 149
• KDHs only communicate with POIs for the purpose of key management and normal transaction processing; • KDHs only communicate with CAs for the purpose of certificate signing and certificate (entity) status checking.
Modified
p. 149
• Each key pair generated results in only one certificate Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here>
Modified
p. 150
• Certificates are replaced by generating a new key pair and requesting a new certificate. • Each key pair generated results in only one certificate.
Modified
p. 150
• Certificates are replaced by generating a new key pair and requesting a new certificate. • Each key pair generated results in only one certificate. <Report Findings Here> 6E-3.7 KDH private keys must not be shared between devices except for load balancing and disaster recovery.
Modified
p. 150
• As components using a recognized (e.g., Shamir) secret-sharing scheme. 6F-1.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. 152
• 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. • Observe key transfer and loading operations to verify that the secrecy of private keys and the integrity of the public keys are ensured. • Verify the process ensures that key pairs are unique per POI device.
Modified
p. 153
• Certificates are replaced by generating a new key pair and requesting a new certificate. • Each key pair generated results in only one certificate.
Modified
p. 153
• All keying material is deleted from the HSM(s) and the server/computer platforms prior to testing. • 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. 153
• Each key pair generated results in only one certificate Documented procedures reviewed: <Report Findings Here> 6E-3.6.b Interview responsible personnel and observe certificate issuing and replacement processes to verify that:
Modified
p. 153
•that is, keys must be used in accordance with their certificate policy. See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy …
• Certificates are replaced by generating a new key pair and requesting a new certificate. • Each key pair generated results in only one certificate. <Report Findings Here> 6E-3.9 Mechanisms must be utilized to preclude the use of a key for other than its designated and intended purpose
•that is, keys must be used in accordance with their certificate policy. See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content. 6E-3.9.a Examine …
•that is, keys must be used in accordance with their certificate policy. See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content. 6E-3.9.a Examine …
Modified
p. 154
• Certificate status checking (e.g., Certificate Revocation Lists) signature keys, or • Signature keys for updating valid/authorized host lists in POIs Must not be used for any purpose other than:
Modified
p. 154
• Certificate signature keys,
• Subordinate entity certificate requests, • Certificate status checking, and/or • Self-signed root certificates.
• Subordinate entity certificate requests, • Certificate status checking, and/or • Self-signed root certificates.
Modified
p. 154
• Signature keys for updating valid/authorized host lists in POIs Are not used for any purpose other than:
Modified
p. 154
• Signature keys for updating valid/authorized host lists in POIs Are not used for any purpose other than:
Modified
p. 154
• Certificate signature keys,
• Status checking (e.g., Certificate Revocation Lists) signature keys, or
• Subordinate entity certificate requests, • Certificate status checking, and/or • Self-signed root certificates.
• Status checking (e.g., Certificate Revocation Lists) signature keys, or
• Subordinate entity certificate requests, • Certificate status checking, and/or • Self-signed root certificates.
Modified
p. 154
• Self-signed root certificates. <Report Findings Here> 6E-3.9.2 CAs that issue certificates to other CAs must not be used to issue certificates to POIs.
Modified
p. 155
• As components using a recognized (e.g., Shamir) secret-sharing scheme. 6F-1.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. 156
• Revoke subordinate certificates, and
Modified
p. 156
• Revoke subordinate certificates, and
Modified
p. 156
• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.
Modified
p. 156
• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.
Modified
p. 156
• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred <Report Findings Here> 6F-2.7.2 In the event of confirming a compromise, the CA must determine whether to revoke and reissue all signed certificates with a newly generated signing key.
Modified
p. 157
• The CA will perform a damage assessment to determine the need to either:
Modified
p. 157
• The CA performs a damage assessment to determine the need to either:
Modified
p. 157
• EPP/PED devices and KDHs have a minimum RSA 1024 bits or equivalent. Effective 1 January 2017, KDHs must use a minimum RSA 2048 bits or equivalent. The key-pair lifecycle shall 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. 158
• 1024 for KDHs and POI devices Appropriate personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6F-2.8.c Verify that KDH keys expire every five years unless another mechanism exists to prevent the use of a compromised KDH private key.
Modified
p. 158
• Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
Modified
p. 159
• CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment). • The network is only used for certificate issuance, revocation, or both certificate issuance and revocation. • Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
Modified
p. 159
• CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment). • The network is only used for certificate issuance, revocation, or both certificate issuance and revocation. • Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs) <Report Findings Here> 6F-5.3.2 CA or Registration Authority (RA) software updates must not be done over the network (local console access must …
Removed
p. 160
Definition of Critical functions of the CA Separation of duties to prevent one person from maliciously using a CA system without detection Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) Responsible personnel interviewed: <Report Findings Here> Describe how the CA operations observed verified:
Modified
p. 160
• Separation of duties to prevent one person from maliciously using a CA system without detection • Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) Documented procedures reviewed: <Report Findings Here> 6F-5.4.b Observe CA operations and interview responsible personnel to verify:
Modified
p. 160
• Separation of duties to prevent one person from maliciously using a CA system without detection • Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) <Report Findings Here> 6F-5.5 All CA systems that are not operated strictly offline must be hardened to prevent insecure network access, to include:
Modified
p. 160
• Documentation must exist to support the enablement of all active services and ports. 6F-5.5.a Examine system documentation to verify the following is required:
Modified
p. 160
• 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. 161
• 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. 161
• There is documentation to support all active services and ports. <Report Findings Here> 6F-5.5.1 All vendor-default IDs must be changed, removed, or disabled unless necessary for a documented and specific business reason. Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades must only be enabled when required and otherwise must be disabled from login. 6F-5.5.1.a Examine documented procedures to verify that:
Modified
p. 161
• Vendor-default IDs are changed, removed, or disabled unless necessary for a documented and specific business reason. • Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades are only be enabled when required and otherwise must be disabled from login.
Modified
p. 161
• Vendor-default IDs are changed, removed or disabled unless necessary for a documented and specific business reason. • Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades are only be enabled when required and otherwise must be disabled from login.
Modified
p. 162
• All key-management operations, such as key generation, loading, transmission, backup, recovery, compromise, and destruction and certificate generation or revocation • The identity of the person authorizing the operation • The identities of all persons handling any key material (such as key components or keys stored in portable devices or media) • Protection of the logs from alteration and destruction 6F-5.6.a Examine system configurations and audit trails to verify that all key- management operations are logged.
Modified
p. 162
• Mechanisms exist to protect logs from alteration and destruction Sample of key-management operations reviewed:
Modified
p. 162
• Mechanisms exist to protect logs from alteration and destruction <Report Findings Here> 6F-5.6.1 Audit logs must be archived for a minimum of two years.
Modified
p. 163
• Success or failure of the event. 6F-5.6.3.a Examine audit trails to verify that logical events are divided into operating-system and CA application events.
Modified
p. 163
• Identity of the entity and/or user that caused the event,
Modified
p. 163
• Identity of the entity and/or user that caused the event,
Modified
p. 164
• 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. • Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled. 6F-5.7.1.a Examine network and system configurations to verify that certificate- processing system components operated online are protected from unauthorized access by …
Modified
p. 165
• Not accept traffic on its external interfaces that appears to be coming from internal network addresses. • 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. • Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled.
Modified
p. 165
• Not accept traffic on its external interfaces that appears to be coming from internal network addresses. • 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. • 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> 6F-5.7.2 …
Modified
p. 166
• Shared user IDs for system administration activities and other critical functions do not exist. • Shared and generic user IDs are not used.
Modified
p. 166
• Shared user IDs for system administration activities and other critical functions do not exist. • Shared and generic user IDs are not used <Report Findings Here> 6F-5.8.2.b Examine authentication policies/procedures to verify that group and shared passwords or other authentication methods are explicitly prohibited.
Modified
p. 168
• All physical and logical CA system components must be separated from key-distribution systems.
Modified
p. 169
Describe how the observed system and network configurations and physical access controls verified that all physical and logical CA system components are separated from key-distribution systems: <Report Findings Here> 6F-8.3 Each CA operator must develop a certification practice statement (CPS). (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.) The CPS must be consistent with the requirements described within this document. The CA shall operate in accordance with …
Describe how the observed system and network configurations and physical access controls verified that all physical and logical CA system components are separated from key-distribution systems: <Report Findings Here> 6F-8.3 Each CA operator must develop a certification practice statement (CPS). (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.)
Modified
p. 169
• Verification of the certificate applicant’s possession of the associated private key through the use of a digitally signed certificate request pursuant to PKCS #10 or another cryptographically-equivalent demonstration; • Determination that the organization exists by using at least one third-party identity-proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization; • Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the …
Modified
p. 170
• The entity submitting the request is authorized to submit the request on behalf of the certificate request’s originating entity. • The entity submitting the request has a valid business relationship with the issuing authority (e.g., the vendor) consistent with the certificate being requested. • The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner.
Modified
p. 170
• The entity submitting the request is who it claims to be. • The entity submitting the request is authorized to submit the request on behalf of the certificate request’s originating entity. • The entity submitting the request has a valid business relationship with the issuing authority (e.g., the vendor) consistent with the certificate being requested. • The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner. 6F-8.5.1.a Examine documented procedures …
Modified
p. 170
• The entity submitting the request is authorized to submit the request on behalf of the certificate request’s originating entity. • The entity submitting the request has a valid business relationship with the issuing authority (e.g., the vendor) consistent with the certificate being requested. • The certificate-signing request has been transferred from the certificate request’s originating entity to the RA in a secure manner.
Modified
p. 171
• For all certificates whose status had changed Documentation reviewed: <Report Findings Here> Describe how the observation of audit trails verified that the identification of entities is retained for the life of the associated certificates:
Modified
p. 171
• For all certificates whose status had changed <Report Findings Here> 6G-3.2.1 The certificate-processing operations center must implement a three-tier physical security boundary, as follows:
Modified
p. 171
• Consists of the entrance to the facility. Level Two Barrier
• Consists of the entrance to the facility.
Modified
p. 171
• Secures the entrance beyond the foyer/reception area to the CA facility. Level Three Barrier
• Secures the entrance beyond the foyer/reception area to the CA facility.
Modified
p. 171
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Documented physical security policies reviewed:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Documented physical security policies reviewed:
Modified
p. 171
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Describe how the physical facility observed verified that three tiers of physical security are implemented as follows:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Describe how the physical facility observed verified that three tiers of physical security are implemented as follows:
Modified
p. 171
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices <Report Findings Here> Level 1 Barrier 6G-3.2.2 The entrance to the CA facility/building must include the following controls:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices <Report Findings Here> Level 1 Barrier 6G-3.2.2 The entrance to the CA facility/building must include the following controls:
Modified
p. 174
• Specific access authorizations, whether logical or physical 6G-3.2.6.a Examine documented procedures to verify they include the following:
Modified
p. 174
• Granting, revocation, and review of access privileges by an authorized officer of the entity operating the CA • Specific access authorizations, whether logical or physical Documented procedures reviewed: <Report Findings Here> 6G-3.2.6.b Interview responsible personnel to verify that the documented procedures are followed for:
Modified
p. 174
• Granting, revocation, and review of access privileges by an authorized officer of the entity operating the CA • Specific access authorizations, whether logical or physical Responsible personnel interviewed: <Report Findings Here> 6G-3.2.6.1 All authorized personnel with access through the Level 3 barrier must:
Modified
p. 174
• Be assigned resources (staff, dedicated personnel) of the CA operator with defined business needs and duties. Note: This requirement applies to all personnel with pre-designated access to the Level 3 environment.
Modified
p. 175
• Be assigned resources of the CA operator with defined business needs and duties.
Modified
p. 177
6G-3.2.9.2 Examine monitoring system configurations to verify; The system records to time-lapse VCRs or similar mechanisms. A minimum of five frames are recorded every three seconds.
6G-3.2.9.2 Examine monitoring system configurations to verify;
Modified
p. 177
• A minimum of five frames are recorded every three seconds. <Report Findings Here>
Modified
p. 179
• Ensure that segregation is maintained between users and administrators of the system.
Modified
p. 179
• Ensure that segregation is maintained between users and administrators of the system. <Report Findings Here> 6G-3.3 The environment must have continuous (24/7) intrusion-detection systems in place, which protects the secure area by motion detectors when unoccupied. 6G-3.3.a Examine security policies and procedures to verify they require:
Modified
p. 179
• Continuous (24/7) intrusion-detection monitoring of the Level 3 environment. • Motion detectors must be active when the environment is unoccupied.
Modified
p. 179
• Continuous (24/7) intrusion-detection monitoring of the Level 3 environment is in place. • Motion detectors are active when the environment is unoccupied.
Modified
p. 179
• Continuous (24/7) intrusion-detection monitoring of the Level 3 environment is in place. • Motion detectors are active when the environment is unoccupied <Report Findings Here> 6G-3.3.1 Any windows in the secure area must be locked and protected by alarmed sensors.
Modified
p. 180
• The intrusion-detection system(s) is automatically activated every time all authorized personnel have exited the secure area.
Modified
p. 180
• The intrusion-detection system(s) is automatically activated every time all authorized personnel have exited the secure area. <Report Findings Here> 6G-3.3.3.b Verify the IDS and alarms function correctly via:
Modified
p. 180
• Having all authorized personnel who badged or otherwise authenticated into the area exit and one person remain behind even though they have badged out. • Having all but one authorized person who badged or otherwise authenticated into the system badge out and exit.
Modified
p. 180
• Actions that disable the intrusion-detection system Describe how the observed security-system configurations verified that an alarm event is generated for:
Modified
p. 180
• Actions that disable the intrusion-detection system <Report Findings Here> 6G-3.4 All personnel (including CA personnel and visitors) must sign an access logbook when entering the Level 3 environment. Note: This log is in addition to those provided by the access-control system.
Modified
p. 181
• For visitor access, the initials of the person escorting the visitor 6G-3.4.1 Examine the access logbook to verify it contains the following information:
Modified
p. 181
• For visitor access, the initials of the person escorting the visitor Identify the P2PE Assessor who confirms the access logbook contains the following:
Modified
p. 181
• Reason for access or purpose of visit • For visitor access, the initials of the person escorting the visitor <Report Findings Here> 6G-3.4.2 The logbook must be maintained within the Level 3 secure environment.
Modified
p. 188
• PCI approved. 6A-1.3.a For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and review the list of approved devices to verify that all HSMs are either:
Modified
p. 188
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 Level 3, or higher. Refer http://csrc.nist.gov. • 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.
Modified
p. 189
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 6A-1.4.a For all PCI-approved HSMs used, examine HSM devices and review the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
Modified
p. 189
• 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: <Report Findings Here> 6A-1.4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS140-2 Level 3 (or …
Modified
p. 189
• The PCI PTS or 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: <Report Findings Here> 6A-1.5 The KIF platform provider maintains documentation detailing the distributed KIF architecture and key-management flows. The platform provider must:
Modified
p. 189
• Maintain documentation detailing the flow of keys from the key generation, through the distributed functionality to the destination device. The documentation should indicate how personnel interaction and inventory management is integrated into the flow.
Modified
p. 190
• 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 is kept current and updated as needed upon changes to the KIF architecture Personnel interviewed: <Report Findings Here> Documented key-management flows reviewed:
Modified
p. 190
• An approved random number generator that has been certified by an independent laboratory to comply with NIST SP 800-22 Note: Random number generation is critical to the security and integrity of all cryptographic systems. All cryptographic key generation relies upon good quality, randomly generated values. 6B-1.1.a Examine key-management policy document and to verify that it requires that all devices used to generate cryptographic keys meet one of the following
Modified
p. 190
<Report Findings Here> 6B-1.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 An approved key-generation function of a PCI•approved HSM An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM or An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 Certification letters/technical documentation reviewed:
<Report Findings Here> 6B-1.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. 191
• 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. • There is no unauthorized mechanism that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Modified
p. 191
• 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. • There is no mechanism including connectivity that might disclose a clear- text key or key component between the key-generation device and the device or medium receiving the key or key component.
Modified
p. 192
• Key-generation devices that generate clear-text key components be powered off when not in use; or • If logically partitioned for concurrent use in other processes, the key- generation capabilities are disabled when not in use and other activities are continuing.
Modified
p. 193
• 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 6D-2 of this Annex B are met.
Modified
p. 193
• 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 6D-2 of this Annex B are met. <Report Findings Here> 6B-2.3 Printed key components must be printed within blind mailers or sealed immediately after printing to ensure that:
Modified
p. 193
• Tampering can be visually detected. Printers used for this purpose must not be used for other purposes. 6B-2.3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed immediately after printing such that:
Modified
p. 193
• Tampering can be visually detected. Printers used for this purpose are not used for other purposes.
Modified
p. 194
• Other types of displaying or recording 6B-2.4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures are implemented to ensure the following:
Modified
p. 194
• Any residue that may contain clear-text keys or components is destroyed immediately after generation. • If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device that will use the key.
Removed
p. 195
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text secret or private keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into startup instructions Affixing (e.g., taping) key or component values to or inside devices Writing key or component values in procedure manuals
Modified
p. 195
• 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.
Modified
p. 195
• If generated externally, the private key of the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair. 6B-2.5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:
Modified
p. 195
• If generated externally, the key pair and all related critical security parameters must be deleted (zeroized) immediately after the transfer to the device that will use the key pair.
Modified
p. 195
• 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> 6B-2.6 Policy and procedures must exist to ensure that clear-text private or secret keys or their components are prohibited from being transmitted across insecure channels. These include but are not limited to:
Removed
p. 196
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into startup instructions Affixing (e.g., taping) key or component values to or inside devices Writing key or component values in procedure manual Describe how the key-management processes observed verified that key components are not transmitted across insecure channels, including but not limited to:
Modified
p. 196 → 195
• Generated by the device that will use the key pair, or
• Dictating verbally keys or components • Recording key or component values on voicemail • Faxing, e-mailing, or otherwise conveying clear-text secret or private keys or components • Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging • Writing key or component values into startup instructions • Affixing (e.g., taping) key or component values to or inside devices • Writing key or component values …
• Dictating verbally keys or components • Recording key or component values on voicemail • Faxing, e-mailing, or otherwise conveying clear-text secret or private keys or components • Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging • Writing key or component values into startup instructions • Affixing (e.g., taping) key or component values to or inside devices • Writing key or component values …
Modified
p. 196
• Writing key or component values in procedure manual <Report Findings Here> 6B-3.1 Written key-creation procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. All key-creation events performed by a key-injection facility must be documented. Procedures for creating all keys must be documented. 6B-3.1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations.
Modified
p. 197
• Where key components are transmitted in clear-text using pre-numbered tamper-evident, authenticable mailers:
Modified
p. 197
- 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. - Ensure that details of the serial number of the package are conveyed transmitted separately from the package itself. - Ensure that documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material. Where SCDs are …
- 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. - Ensure that details of the serial number of the package are conveyed transmitted separately from the package itself. - Ensure that documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material. • Where SCDs are …
Modified
p. 197
• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package itself. • Observe the method used to transport clear-text key components using tamper-evident mailers and interview responsible personnel to verify that Documented procedures reviewed: <Report Findings Here> Records of key conveyances examined:
Modified
p. 198
• Examine documented procedures to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels. • Examine documented procedures to verify that the SCD is inspected to ensure that there are not any signs of tampering. • Examine records of key transfers and interview responsible personnel to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
Modified
p. 198
• Examine documented procedures to verify that the SCD requires dual- control mechanisms to become operational. • Examine documented procedures to verify that the SCD is inspected to ensure that there are not any signs of tampering. • Examine records of key transfers and interview responsible personnel to verify that the mechanisms make the SCD operational are conveyed using separate communication channels.
Modified
p. 199
• Any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other components or shares sufficient to form the necessary threshold to derive the key. • Any person with access to the media conveying a component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is …
Modified
p. 199
• 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. • 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 …
Modified
p. 199
• 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. • 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 …
Removed
p. 200
Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A. A hash of the public key sent by a separate channel (e.g., mail) Using a MAC (message authentication code) created using the algorithm defined in ISO 16609 Be within an SCD Note: Self-signed certificates must not be used as the sole method of authentication. 6C-1.4 For all methods used to convey public keys, perform the following:
Modified
p. 200
• Examine documented procedures for conveying public keys to verify that methods are defined to convey public keys in a manner that protects their integrity and authenticity such as: - Use of public-key certificates created by a trusted CA that meets the requirements of Annex A - A hash of the public key sent by a separate channel (e.g., mail) - Using a MAC (message authentication code) created using the algorithm defined in ISO 16609 - Be within an SCD …
Modified
p. 200
• Contained within a physically secure SCD. Note: No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key. 6C-2.1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear-text secret or private key component/share must at all times be either:
Modified
p. 200
• Under the continuous supervision of a person with authorized access to this component, • Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access to it would be detected, or • Contained within a physically secure SCD.
Modified
p. 201
• Under the continuous supervision of a person with authorized access to this component, • Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access to it would be detected, or • Contained within a physically secure SCD.
Modified
p. 201
• Under the continuous supervision of a person with authorized access to this component • Locked in a security container (including pre-numbered tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or • Contained within a physically secure SCD. <Report Findings Here> 6C-2.2 Packaging or mailers (i.e., pre-numbered tamper-evident packaging) containing clear-text key components are examined for evidence of tampering before …
Modified
p. 201
• Any keys encrypted under this (combined) key 6C-2.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.
Modified
p. 201
• Any keys encrypted under this (combined) key Documented procedures reviewed: <Report Findings Here>
Modified
p. 202
• Any keys encrypted under this (combined) key Responsible personnel interviewed <Report Findings Here> Describe how the process observed verified that if a package shows signs of tampering, processes are implemented that result in the destruction and replacement of both:
Modified
p. 202
• Any keys encrypted under this (combined) key <Report Findings Here> 6C-2.3 Only the authorized key custodian (and designated backup(s)) shall have physical access to a key component prior to transmittal or upon receipt of a component. 6C-2.3.a Verify that a list(s) of key custodians (and designated backup(s)) authorized to have physical access to key components prior to transmittal or upon receipt of a component is defined and documented.
Modified
p. 202
• Check the serial number of the tamper-evident packing upon receipt of a component package. 6C-2.4.a Verify that a list(s) of key custodians authorized to perform the following activities is defined and documented:
Modified
p. 202
• Place the key component into pre-numbered tamper-evident packaging for transmittal. • Upon receipt, check the tamper-evident packaging for signs of tamper prior to opening the tamper-evident packaging containing the key component. • Check the serial number of the tamper-evident packing upon receipt of a component package.
Modified
p. 203
• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package itself. • Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself.
Modified
p. 203
• Place the key component into pre-numbered tamper-evident packaging for transmittal. • Upon receipt, check the tamper-evident packaging for signs of tamper prior to opening the tamper-evident packaging containing the key component. • Check the serial number of the tamper-evident packing upon receipt of a component package.
Modified
p. 203
• Place the key component into pre-numbered tamper-evident packaging for transmittal. • Upon receipt, check the tamper-evident packaging for signs of tamper prior to opening the tamper-evident packaging containing the key component. • Check the serial number of the tamper-evident packaging upon receipt of a component package. <Report Findings Here> 6C-2.5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers. Note: Numbered …
Modified
p. 203
• RSA keys encrypting keys greater in strength than 80 bits shall have bit strength at least 112 bits. 6C-3.1.a Examine documented procedures to verify that all keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed, as delineated in Annex C.
Removed
p. 204
- DEA keys used for encrypting keys must be at least double-length keys (have bit strength of 80 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment. - A double- or triple-length DEA key must not be encrypted with a DEA key of lesser strength. - TDEA keys are not used to protect AES keys. - TDEA keys shall not be used to encrypt keys greater in strength than 112 bits. - RSA keys encrypting keys greater in strength than 80 bits have bit strength at least 112 bits.
Modified
p. 204
• Interview appropriate personnel and examine documented procedures for the creation of these keys. • Using the table in Annex C, validate the respective key sizes for TDEA, RSA, Elliptic Curve, DSA, and Diffie Hellman algorithms where used for key encryption. • Verify that:
Modified
p. 205
• Physical access controls Note that for devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. 6D-1.3.a Examine documented procedures for loading of clear-text cryptographic keys, including public keys, to verify they require dual control to authorize any key-loading session.
Modified
p. 206
Describe how the key-component lengths or device configuration settings observed verified that key components used to create a key are the same length as the resultant key: <Report Findings Here> 6D-1.5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least double-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits. 6D-1.5 Examine vendor documentation describing options for how …
Describe how the key-component lengths or device configuration settings observed verified that key components used to create a key are the same length as the resultant key: <Report Findings Here> 6D-1.5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least triple-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits. 6D-1.5 Examine vendor documentation describing options for how …
Modified
p. 207
• The existing TMK to encrypt the replacement TMK for download. Keys shall not be reloaded by any methodology in the event of a compromised device, and must be withdrawn from use. 6D-1.7.a Examine documented procedures for the loading of TMKs to verify that they require asymmetric key-loading techniques or manual techniques for initial loading.
Modified
p. 207
• Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device actually has (or actually can) compute the session key and that no entity other than the POI device specifically identified can possibly compute the session key. 6D-1.8.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including the size and sources of the parameters involved, and …
Removed
p. 208
Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of clear-text key components. There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys. The SCD must be inspected prior to use to ensure that it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying materials. SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading. An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are uniquely identified by the device.
Modified
p. 208
• Use of public and private key lengths that are in accordance with Annex C for the algorithm in question. • Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question. • Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable.
Modified
p. 208
• 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 • Logical dual control via multiple logins with unique user IDs to the key-injection platform application such that …
Modified
p. 209
• Instructions for the medium to be placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or • Instructions to erase or otherwise destroy all traces of the component from the electronic medium.
Modified
p. 209
• Ensure that any cameras that are present are positioned to ensure they cannot monitor the entering of clear-text key components. • Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: - SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading. - …
Modified
p. 209
• SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading. • An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device. • There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys. • The SCD is inspected to ensure it has not been …
Modified
p. 209
• The medium is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or • All traces of the component are erased or otherwise destroyed from the electronic medium. 6D-2.3 Examine documented procedures for the loading of secret or private key components from an electronic medium to a cryptographic device. Verify that procedures define specific instructions to be followed as …
Modified
p. 210
• The medium used for key loading is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or • All traces of the component are erased or otherwise destroyed from the electronic medium.
Modified
p. 210
• The medium used for key injection is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or • All traces of the component are erased or otherwise destroyed from the electronic medium. <Report Findings Here> 6D-2.4 For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device:
Modified
p. 212
• Requirement that media/devices are in the physical possession of only the designated component holder(s). • The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process.
Modified
p. 213
• Located in a physically secure room that is dedicated to key-loading activities. 6D-2.9.1 For facilities using PC-based key-loading software platforms or similar devices, verify through interviews and observation that the platform is:
Modified
p. 213
• Located in a physically secure room that is dedicated to key loading activities Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that for facilities using PC- based key-loading software platforms or similar devices, the platform is standalone, dedicated to only key loading, and located in a physically secure room that is dedicated to key loading activities <Report Findings Here> 6D-2.9.2 All hardware used in key loading (including the PC) must be managed under dual control. Key-injection …
Removed
p. 214
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. 6D-2.9.3.a Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
Modified
p. 214
• 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.
Modified
p. 214
• 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 <Report Findings Here> 6D-2.9.3 PC access and use must be monitored, and logs of all key loading must be maintained. These logs must be …
Modified
p. 214
• Regularly reviewed by an authorized person who does not have access to the room or to the PC. • The reviews are documented.
Modified
p. 215
• Regularly reviewed by an authorized person who does not have access to the room or to the PC.
Modified
p. 216
• All openings on the PC that are not used for key-injection are covered with security seals that are tamper-evident and serialized. • The seals are recorded in a log, and the log is maintained along with the other key-loading logs in a dual-control safe. • Verification of the seals must be performed prior to key-loading activities. <Report Findings Here>
Modified
p. 217
• 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. <Report Findings Here> 6D-2.9.4.10 Manufacturer’s default passwords for PC-based applications must be changed.
Modified
p. 217
• Any hardware used in the key-loading function must be controlled and maintained in a secure environment under dual control. • Any resources (e.g., passwords and associated hardware) used in the key- loading function must be controlled and managed such that no single individual has the capability to enable key loading.
Modified
p. 217
• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control. • 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.
Modified
p. 217
• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control. • 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> 6D-3.2 All cable attachments must be examined before each key-loading operation to ensure they have not been tampered with or compromised.
Modified
p. 219
• Have a MAC (message authentication code) created using the algorithm defined in ISO 16609. 6D-4.2.a Interview personnel and review documented procedures to verify that all public keys exist only in an approved form.
Modified
p. 221
• 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. 6E-2.5.a Examine documented procedures to verify they include:
Modified
p. 221
• Controls to prevent the operation of devices without legitimate keys.
Modified
p. 221
• Controls are implemented that protect against unauthorized substitution of keys, and • Controls are implemented that prevent the operation of devices without legitimate keys.
Modified
p. 221
• Controls are implemented that protect against unauthorized substitution of keys, and • Controls are implemented that prevent the operation of devices without legitimate keys. <Report Findings Here> 6E-3.1 Encryption keys must be used only for the purpose they were intended (i.e., key-encryption keys must not to be used as PIN-encryption keys, PIN- encryption keys must not be used for account data, etc.). This is necessary to limit the magnitude of exposure should any key(s) be compromised. Using keys only …
Modified
p. 222
• 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).
•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI devices).
Modified
p. 222
• 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). • Private keys shall never be used to encrypt other keys. 6E-3.2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only used:
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices). • Private keys shall never be used to encrypt other keys. 6E-3.2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only used:
Modified
p. 222
• For a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for POI devices). • Private keys are never used to encrypt other keys.
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for POI devices). • Private keys are never used to encrypt other keys.
Modified
p. 222
• Keys used for testing keys must never be present or used in a production system. 6E-3.4.a Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that cryptographic keys are never shared or substituted between production and development systems.
Modified
p. 223
• All keying material is deleted from the HSM(s) and the server /computer platforms prior to testing. • 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. 224
• Known only to HSMs at the minimum number of facilities consistent with effective system operations.
Modified
p. 224
• Examine documented procedures for generating all types of keys and verify the procedures ensure that unique keys, or sets of keys, are used for each acquiring organization and are totally independent and not variants of one another. • Interview personnel and observe key-generation processes to verify that unique keys or sets of keys are generated for each acquiring organization.
Modified
p. 225
• Unique data is used for the derivation process such that all transaction- originating POIs receive unique secret keys. • Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.
Modified
p. 225
• 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. <Report Findings Here> 6E-4.3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device.
Modified
p. 225
• Different BDKs by geographic region, market segment, platform, or sales unit Injection vendors must use at least one unique Base Derivation Key (BDK) per acquiring organization, and must be able to support segmentation of multiple BDKs of acquiring organizations. 6E-4.4.a Examine documented key-generation and injection procedures to verify that the following is required when injecting keys into a single POI for more than one acquiring organization:
Modified
p. 225
• The POI must have a completely different and unique key, or set of keys, for each acquiring organization. • These different keys, or sets of keys, must be totally independent and not variants of one another.
Modified
p. 225
• The POI has a completely different and unique key, or set of keys, for each acquiring organization. • These different keys, or sets of keys, are totally independent and not variants of one another.
Modified
p. 225
• The POI has a completely different and unique key, or set of keys, for each acquiring organization. • These different keys, or sets of keys, are totally independent and not variants of one another. <Report Findings Here>
Modified
p. 226
• Keys must be uniquely identifiable in all hosts and POI Devices (e.g., EPPs/PEDs). Keys must be identifiable via cryptographically verifiable means (e.g., through the use of digital signatures or key check values). • Key pairs must be unique per POI device (e.g., EPPs and PEDs). 6E-4.6.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including:
Modified
p. 226
• The mechanisms utilized for mutual device authentication for both the host and the POIPED.
Modified
p. 226
• Cryptographic mechanisms exist to uniquely identify the keys.
Modified
p. 226
• Contained within a secure cryptographic device 6F-1.1.a Examine documented procedures for key storage and usage and observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored.
Modified
p. 230
• Processing with that key is halted, and the key is replaced with a new unique key. • 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. • The replacement key must not be a variant of the original key, or an irreversible transformation of the original key.
Modified
p. 230
• Processing with that key is halted, and the key is replaced with a new unique key. • 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. • The replacement key must not be a variant of the original key, or an irreversible transformation of the original key. <Report Findings Here>
Modified
p. 231
• Specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc. 6F-2.1.4.a Interview responsible personnel and review documented procedures to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
Modified
p. 231
• A damage assessment including, where necessary, the engagement of outside consultants. • Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Modified
p. 231
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 6F-2.1.5 Interview responsible personnel and review documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
Modified
p. 231
• Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries • Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate • Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities • Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of …
Modified
p. 233
• Variants used as KEKs must only be calculated from other key-encrypting keys. • Variants of working keys must only be calculated from other working keys.
Modified
p. 233
• Variants used as KEKs must only be calculated from other key-encrypting keys • Variants of working keys must only be calculated from other working keys. <Report Findings Here> 6F-4.1 Instances of secret or private keys, and their key components, that are no longer used or that have been replaced by a new key must be destroyed 6F-4.1.a Verify documented procedures are in place for destroying secret or private keys, and their key components that are no longer used or …
Removed
p. 235
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date for the custodian’s access Signature of management authorizing the access
Modified
p. 235
• A primary and a backup key custodian are designated for each component. • The fewest number of key custodians is assigned as necessary to enable effective key management. • Assigned key custodians are employees or contracted personnel. <Report Findings Here> 6F-5.1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.
Modified
p. 235
• A primary and a backup key custodian are designated for each component. • The fewest number of key custodians is assigned as necessary to enable effective key management. • Assigned key custodians are employees or contracted personnel Describe how the key-custodian assignments observed for each component verified that:
Modified
p. 236 → 235
• Specific authorization for the custodian • Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them • Signature of the custodian acknowledging their responsibilities • An effective date for the custodian’s access • Signature of management authorizing the access
• Specific authorization for the custodian
• Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them
• Signature of the custodian acknowledging their responsibilities
• An effective date for the custodian’s …
• Specific authorization for the custodian
• Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them
• Signature of the custodian acknowledging their responsibilities
• An effective date for the custodian’s …
Modified
p. 236
• Key custodians that form the necessary threshold to create a key do not directly report to the same individual. • Neither direct reports nor the direct reports in combination with their immediate supervisor possess the necessary threshold of key components sufficient to form any given key.
Modified
p. 236
• Receive explicit training to instruct them from sharing key components with their direct manager. • Sign key-custodian agreement that includes an attestation to the requirement. • Ensure training includes whistleblower procedures to report any violations.
Modified
p. 237
• Loaded to an SCD <Report Findings Here> 6F-6.1.b Review log files and audit log settings to verify that logs include the following:
Modified
p. 237
• Tamper-evident package number (if applicable) 6F-6.1.a Review log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:
Modified
p. 237
• Loaded to an SCD Log files reviewed: <Report Findings Here> Describe how the audit log settings observed verified that logs are kept for any time that keys, key components, or related materials are:
Modified
p. 237
• Tamper-evident package number (if applicable) Log files reviewed: <Report Findings Here> Describe how the audit log settings observed verified that logs include the following:
Modified
p. 237
• Tamper-evident package number (if applicable) <Report Findings Here> 6F-7.1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as are followed for the primary keys.
Modified
p. 238
• Subject to at least the same level of security control as operational keys as specified in this document <Report Findings Here> 6F-7.2 If backup copies are created, the following must be in place:
Modified
p. 238
• Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys. • Inspect backup storage locations and access controls or otherwise verify through examination of documented procedures and interviews of personnel that backups are maintained as follows: - Securely stored with proper access controls - Under at least dual control - Subject to at least the same level of security control as operational …
Modified
p. 238
• All requirements applicable for the original keys also apply to any backup copies of keys and their components. 6F-7.2 Interview responsible personnel and observe backup processes to verify the following:
Modified
p. 238
• The creation of any backup copies requires at least two authorized individuals to enable the process. • All requirements applicable for the original keys also apply to any backup copies of keys and their components.
Modified
p. 238
• The creation of any backup copies requires at least two authorized individuals to enable the process • All requirements applicable for the original keys also apply to any backup copies of keys and their components. <Report Findings Here> 6F-8.1 Written procedures must exist, and all affected parties must be aware of those procedures. All activities related to key administration performed by a key- injection facilities must be documented. This includes all aspects of key administration, as well as:
Modified
p. 238
• Management of personnel changes, including revocation of access control and other privileges when personnel move
Modified
p. 239
• Management of personnel changes, including revocation of access control and other privileges when personnel move Documented procedures reviewed: <Report Findings Here> 6F-8.1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
Modified
p. 239
• POIs have not been substituted or subjected to unauthorized modifications or tampering. • SCDs used for key injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 239
• POIs have not been substituted or subjected to unauthorized modifications or tampering. • SCDs used for key injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 241
• All personnel with access to POIs and other SCDs are documented in a formal list. • All personnel with access to POIs and other SCDs are authorized by management. • The authorizations are reviewed annually.
Modified
p. 242
• Use of physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging). The devices are then stored in such packaging, or in secure storage, until key insertion and deployment occurs. • A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. Before key-insertion, the SCD used for key-insertion verifies the presence of the correct “transport-protection token” before overwriting this value with the initial key, and the device is further protected …
Modified
p. 245
• 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. Note: The KIF platform must ensure that only authorized devices can ever be injected or initialized with authorized keys. Processes must prevent (1) substitution of an authorized device with an unauthorized device, and (2) insertion of an unauthorized device into a production run. 6G-2.3.a Obtain and review documentation of inventory control and monitoring procedures. …
Modified
p. 245
• Each production run is associated with a predefined inventory of identified POI devices to be injected or initialized with keys. • Unauthorized personnel are not able to modify this inventory without detection. • All POI devices to be initialized with keys on a production run are identified and accounted for against the inventory. • Unauthorized POI devices submitted for injection or initialized are rejected by the injection platform and investigated. • Once processed by the KIF, whether successfully initialized …
Modified
p. 245
• Procedures require that all keys and key material stored within the device be securely destroyed.
Modified
p. 247 → 248
• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing; • To place the device into a state that allows for the input or output of clear- text key components; • For all access to KLDs. <Report Findings Here> 6G-4.1.4 Devices must not use default passwords.
Modified
p. 248 → 247
• To enable any manual key-encryption functions and any key-encryption functions that occur outside of normal transaction processing;
Modified
p. 248
• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing; • To place the device into a state that allows for the input or output of clear- text key components; • For all access to KLDs Dual-control mechanisms examined: <Report Findings Here> Describe how the observation of authorized personnel performing the defined activities verified that dual control is implemented for the following:
Modified
p. 248
• Under the continuous supervision of at least two authorized people who ensure that any unauthorized use of the device would be detected. Note: POI devices may be secured by storage in the dual-control access key injection room. 6G-4.1.5.a Examine documented procedures to confirm that they require devices are at all times within a secure room and either:
Modified
p. 249
• Locked in a secure cabinet and/or sealed in tamper-evident packaging at all times, or • Under the continuous supervision of at least two authorized people at all times. <Report Findings Here> 6G-4.9 Distributed functionality of the KIF that is used for generation and transfer of keys must communicate via mutually authenticated channels. All key transfers between distributed KIF functions must meet the requirements of 6C. 6G-4.9.1 The KIF must ensure that keys are transmitted between KIF components in accordance …
Modified
p. 250
• When a KLD is used as an intermediate device to establish keys between POIs and a KIF HSM it must not be possible to insert an unauthorized SCD into the flow without detection. 6G-4.9.6 Interview responsible personnel and observe processes for establishment of enciphered secret or private keys between sending and receiving devices to verify:
Modified
p. 250
• KIFs validate authentication credentials of a POI 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. • 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 Responsible personnel interviewed: <Report Findings Here> Describe how the …
Modified
p. 250
• 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> 6G-4.9.7 Mechanisms must exist to prevent a non-authorized host from injecting keys into POIs or an unauthorized POI from establishing a key with a legitimate KIF component. 6G-4.9.7 Examine documented procedures to confirm they define mechanisms to prevent an unauthorized host from performing key …
Modified
p. 251
• Dual-access requirements for entry into the secure area, and
Modified
p. 252
• Anti-pass-back Describe how the observation of authorized personnel entering the secure area verified that a badge-control system is in place that enforces the following requirements:
Modified
p. 252
• Anti-pass-back <Report Findings Here> 6G-4.10.6 The badge-control system must support generation of an alarm when one person remains alone in the secure area for more than 30 seconds. Note: Examples of alarm-generation mechanisms include but are not limited to motion detectors, login/logout controls, biometrics, badge sensors, etc. 6G-4.10.6 Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure area for more than 30 …
Modified
p. 253
• The equipment used for key injection. 6G-4.10.10 Inspect CCTV positioning and review a sample of recordings to verify that CCTV cameras are positioned to monitor:
Modified
p. 253
• SCDs, both pre and post key injection, • Any safes that are present, and • SCDs, both pre and post key injection,
• Any safes that are present, and
• The equipment used for key injection.
• Any safes that are present, and
• The equipment used for key injection.
Modified
p. 254
• Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Documented component provider procedures reviewed:
• Details of any known or suspected compromised keys, per 6F-2.1 Documented component provider procedures reviewed:
Modified
p. 254
• Types/models of POIs for which keys have been injected
Modified
p. 254
• Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Solution provider reports reviewed: <Report Findings Here>
• Details of any known or suspected compromised keys, per 6F-2.1 Solution provider reports reviewed: <Report Findings Here>
Modified
p. 254
• Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Note that adding, changing, or removing POI device 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 or removing elements of a P2PE solution. 6I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers and interview responsible …
• Details of any known or suspected compromised keys, per 6F-2.1 Note that adding, changing, or removing POI device 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 or removing elements of a P2PE solution. 6I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers and interview responsible component-provider personnel to …