Document Comparison
P2PE_v2_r1-1.pdf
→
P2PE_Standard_v2.0_r1.2.pdf
98% similar
293 → 294
Pages
117360 → 117540
Words
936
Content Changes
Content Changes
936 content changes. 148 administrative changes (dates, page numbers) hidden.
Added
p. 1
Payment Card Industry (PCI) Point-to-Point Encryption Solution Requirements and Testing Procedures Version 2.0 (Revision 1.2)
March 2020 2.0 1.2 Clarify intent of 6C-3.1 and 6D-1.5 (in both Domain 6 and Annex B) with regards to the use of triple- length TDEA keys and align with existing key table in Annex C.
Clarify domain applicability for CA/RAs.
Fixed numbering error for test procedure 6C-3.1.c.
March 2020 2.0 1.2 Clarify intent of 6C-3.1 and 6D-1.5 (in both Domain 6 and Annex B) with regards to the use of triple- length TDEA keys and align with existing key table in Annex C.
Clarify domain applicability for CA/RAs.
Fixed numbering error for test procedure 6C-3.1.c.
Added
p. 11
• Upon acceptance, the P2PE application is listed on PCI SSC’s list of Validated P2PE Applications.
Added
p. 14
• P2PE payment applications (subject to a Domain 2 assessment)
Added
p. 22
• 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)
• Confirmed per 1A-1.1 as a PTS-approved device(s)
• 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)
• Confirmed per 1A-1.1 as a PTS-approved device(s)
Added
p. 24
• Cannot view or access SAD
Added
p. 24
• Cannot view or access SAD.
• Cannot view or access SAD.
• Cannot view or access SAD.
Added
p. 27
• Integrity check of update
• Integrity checks of update
• The integrity of the update is checked
• Procedures for maintaining an up-to-date inventory of POI device system builds
• 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 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
• Changes to the applications within the device
• Changes to the applications within the device
• Changes to the firmware within the device
• Changes to the firmware within the device
• Cryptographic authentication by the POI device’s
• Integrity checks of update
• The integrity of the update is checked
• Procedures for maintaining an up-to-date inventory of POI device system builds
• 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 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
• Changes to the applications within the device
• Changes to the applications within the device
• Changes to the firmware within the device
• Changes to the firmware within the device
• Cryptographic authentication by the POI device’s
Added
p. 32
• Following the device vendor's security guidance or the application’s Implementation
• Cryptographic authentication of whitelisting functionality by the POI device’s
• Authentication of the application by the POI device’s firmware
• Requiring dual control to authenticate the application
• Following this process both for new installations and for updates.
• Cryptographic authentication of whitelisting functionality by the POI device’s
• Authentication of the application by the POI device’s firmware
• Requiring dual control to authenticate the application
• Following this process both for new installations and for updates.
Added
p. 47
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
• Documentation of customer impact
• Documented approval of change by appropriate authorized parties
• Functionality testing to verify that the change does not adversely impact the security of the device
• Documentation detailing the impact of all changes included in the relevant application release
• Documentation of customer impact
• Documented approval of change by appropriate authorized parties
• Functionality testing to verify that the change does not adversely impact the security of the device
• Documentation detailing the impact of all changes included in the relevant application release
Added
p. 56
• Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.)
• Details of how security-impacting changes will be indicated by the version scheme
• Details of how other types of changes will affect the version
• Link Layer protocols
• Any instructions on how to securely configure any configurable options, as applicable to the application’s specific business processing
• Details of how security-impacting changes will be indicated by the version scheme
• Details of how other types of changes will affect the version
• Link Layer protocols
• Any instructions on how to securely configure any configurable options, as applicable to the application’s specific business processing
Added
p. 60
• Confirmation that the application does not perform encryption of clear-text account- data, nor does it replace the POI device’s SRED encryption
Added
p. 64
• The logical interfaces intended for sharing of clear-text account data (e.g., those used to pass clear-text data back to the approved firmware of the POI device)
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
• How to perform cryptographic authentication by the POI device’s firmware
• That such functionality must be approved by authorized personnel prior to implementation
• That such functionality must be approved by authorized personnel prior to implementation
• How to establish cryptographically authentication by the POI device’s firmware
• Documentation detailing the impact of all changes included in the relevant application release
• Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.)
• Details of how security-impacting changes will be indicated by the version scheme
• Details of how other types of changes will affect the version
• A list of shared resources
• …
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
• How to perform cryptographic authentication by the POI device’s firmware
• That such functionality must be approved by authorized personnel prior to implementation
• That such functionality must be approved by authorized personnel prior to implementation
• How to establish cryptographically authentication by the POI device’s firmware
• Documentation detailing the impact of all changes included in the relevant application release
• Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.)
• Details of how security-impacting changes will be indicated by the version scheme
• Details of how other types of changes will affect the version
• A list of shared resources
• …
Added
p. 70
• What specifically is required
• What specifically is required
• Which legal/regulatory entity requires it
• Which legal/regulatory entity requires it
• Changes in third-party service providers
• Changes in third-party service providers
• Physical device breaches
• What specifically is required
• Which legal/regulatory entity requires it
• Which legal/regulatory entity requires it
• Changes in third-party service providers
• Changes in third-party service providers
• Physical device breaches
Added
p. 71
• Unauthorized logical alterations to devices (e.g., configuration, access controls, whitelists)
Added
p. 71
• Unauthorized use of sensitive functions (e.g., key-management functions)
• The issue has been resolved and P2PE encryption functionality is restored and re-enabled, or
• The issue has been resolved and P2PE encryption functionality is restored and re-enabled, or
• Identification that a failure has occurred
• Identification that a failure has occurred
• Identifying the root cause
• Identifying the root cause
• Determining remediation needed to address root cause
• Determining remediation needed to address root cause
• Identifying and addressing any security issues that occurred during the failure
• Identifying and addressing any security issues that occurred during the failure
• Identification of merchant submitting request
• Identification of merchant submitting request
• Date request received
• Date initial request received
• All functions each third party is responsible for
• Agreement to maintain P2PE controls for which they are responsible
• Notification and documentation of any changes affecting the third party governed by P2PE requirements
• Notification of any security-related incidents
• Defining and maintaining …
• The issue has been resolved and P2PE encryption functionality is restored and re-enabled, or
• The issue has been resolved and P2PE encryption functionality is restored and re-enabled, or
• Identification that a failure has occurred
• Identification that a failure has occurred
• Identifying the root cause
• Identifying the root cause
• Determining remediation needed to address root cause
• Determining remediation needed to address root cause
• Identifying and addressing any security issues that occurred during the failure
• Identifying and addressing any security issues that occurred during the failure
• Identification of merchant submitting request
• Identification of merchant submitting request
• Date request received
• Date initial request received
• All functions each third party is responsible for
• Agreement to maintain P2PE controls for which they are responsible
• Notification and documentation of any changes affecting the third party governed by P2PE requirements
• Notification of any security-related incidents
• Defining and maintaining …
Added
p. 82
• Reside within the decryption environment
• Only those systems (e.g., POI devices) directly related to supporting P2PE transactions, and
• Only those systems (e.g., POI devices) directly related to supporting P2PE transactions, and
Added
p. 88
• PCI PTS HSM approved.
• 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
• Purpose and description of any non-FIPS validated software added to the HSM
• Purpose and description of any non-FIPs validated software added to the HSM
• A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements Note that adding any software may invalidate the FIPS approval.
• Assigning administrative roles and responsibilities only to specific, authorized personnel
• 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
• Purpose and description of any non-FIPS validated software added to the HSM
• Purpose and description of any non-FIPs validated software added to the HSM
• A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements Note that adding any software may invalidate the FIPS approval.
• Assigning administrative roles and responsibilities only to specific, authorized personnel
Added
p. 91
• Console and non-console administration
Added
p. 91
• Assigning administrative roles and responsibilities only to specific, authorized
• Console/remote administration
• Console/remote administration
• Procedures and/or mechanisms for authenticating POI devices upon connection to the decryption environment
• Console/remote administration
• Console/remote administration
• Procedures and/or mechanisms for authenticating POI devices upon connection to the decryption environment
Added
p. 94
• Cryptographic authentication by the HSM
• Cryptographic authentication by the HSM
• Unauthorized use of sensitive functions (e.g., key-management functions)
• Changes to the applications
• Changes to the firmware
• 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)
• Cryptographic authentication by the HSM
• Unauthorized use of sensitive functions (e.g., key-management functions)
• Changes to the applications
• Changes to the firmware
• 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)
Added
p. 96
• 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 5C-1.2.b Interview personnel and observe implemented mechanisms to verify mechanisms are implemented to detect and respond to suspicious activity, including:
• Unauthorized logical alterations (configuration, access controls)
• Unauthorized use of sensitive functions (e.g., key management functions)
• Unauthorized use of the HSM API 5C-1.2.b Interview personnel and observe implemented mechanisms to verify mechanisms are implemented to detect and respond to suspicious activity, including:
• Unauthorized logical alterations (configuration, access controls)
• Unauthorized use of sensitive functions (e.g., key management functions)
Added
p. 103
• Failure of a security function or mechanism
• Failure of a system self-test, as described in Requirements 5D-1.6 and 5D-1.7
• 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
• During diagnostics of cryptographic operations.
• While in an error state, as described in Requirement 5D-1.8
• While in an error state, as described in Requirement 5D-1.8
• Failure of a system self-test, as described in Requirements 5D-1.6 and 5D-1.7
• 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
• During diagnostics of cryptographic operations.
• While in an error state, as described in Requirement 5D-1.8
• While in an error state, as described in Requirement 5D-1.8
Added
p. 113
• All entrances and exists
• All entrances and exists
• All entrances and exists
Added
p. 117
• Number of HSMs deployed and any change in numbers since last report
Added
p. 117
• Providing reports annually and upon significant changes
• Number of HSMs deployed and description of any changes since last report
• Number of HSMs deployed and description of any changes since last report
• Critical infrastructure changes, including to the PCI DSS environment
• 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 report
• Number of HSMs deployed and description of any changes since last report
• Critical infrastructure changes, including to the PCI DSS environment
• 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. 126
• An approved key-generation function of a PCI approved HSM or POI device;
Added
p. 126
• An approved key-generation function of a PCI
•approved HSM or POI device;
• An approved key-generation function of a PCI
•approved HSM or POI device;
• Key-generation devices that generate clear-text key components are powered off when not in use; or
• Memory storage of a key-loading device, after loading the key to a different device or system
• 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:
• Generated by the device that will use the key pair; or
•approved HSM or POI device;
• An approved key-generation function of a PCI
•approved HSM or POI device;
• Key-generation devices that generate clear-text key components are powered off when not in use; or
• Memory storage of a key-loading device, after loading the key to a different device or system
• 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:
• Generated by the device that will use the key pair; or
Added
p. 131
• Affixing (e.g., taping) key or component values to or inside devices
• Affixing (e.g., taping) key or component values to or inside devices
• 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
• Writing key or component values in procedure manual 6B-3 Documented procedures must exist and must be demonstrably in use for all key-generation processing.
• Affixing (e.g., taping) key or component values to or inside devices
• 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
• Writing key or component values in procedure manual 6B-3 Documented procedures must exist and must be demonstrably in use for all key-generation processing.
Added
p. 135
• 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
• Using a MAC (message authentication code) created using the algorithm defined in
• 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
• Using a MAC (message authentication code) created using the algorithm defined in
• Under the continuous supervision of a person with authorized access to this component, or
Added
p. 136
• Under the continuous supervision of a person with authorized access to this
• Under the continuous supervision of a person with authorized access to this
• Under the continuous supervision of a person with authorized access to this
Added
p. 139
• Verify that: o TDEA keys used for encrypting keys must be at least triple-length keys (have bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment. o A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength. o TDEA keys are not used to protect AES keys. o TDEA keys are not be used to encrypt keys greater in strength than 112 bits. o RSA keys encrypting keys greater in strength than 80 bits have bit strength at least 112 bits.
Added
p. 142
• Asymmetric techniques
• 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.
• Instructions to erase or otherwise destroy all traces of the component from the electronic medium.
• 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.
• Instructions to erase or otherwise destroy all traces of the component from the electronic medium.
Added
p. 148
• Be within a certificate as defined in Annex A, or
• Be within a PKCS#10, or
• Be within an SCD, or
• Not be given to any other entity or logically separate systems.
• Proactive safeguards that shut down the source of any synchronization errors and start an investigative process to determine the true cause of the event.
• Keys used for testing must never be present or used in a production system.
• Known only to a single POI device, and
• Be within a PKCS#10, or
• Be within an SCD, or
• Not be given to any other entity or logically separate systems.
• Proactive safeguards that shut down the source of any synchronization errors and start an investigative process to determine the true cause of the event.
• Keys used for testing must never be present or used in a production system.
• Known only to a single POI device, and
Added
p. 158
• Identification of key personnel
Added
p. 160
• Variants of working keys must only be calculated from other working keys.
Added
p. 164
• Name and signature of custodian accessing the
• Removed from secure storage
• Key component identifier
• Removed from secure storage
• Key component identifier
Added
p. 165
• Securely stored with proper access controls
• Under at least dual control
• All requirements applicable for the original keys also apply to any backup copies of keys and their components.
• Under at least dual control
• All requirements applicable for the original keys also apply to any backup copies of keys and their components.
Added
p. 174
• To enable application-signing functions;
• To enable application-signing functions;
• To enable application-signing functions;
Added
p. 174
• For all access to key-loading devices (KLDs) and authenticated application-signing devices.
• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;
• For all access to KLDs and authenticated application-signing devices.
• Locked in a secure cabinet and/or sealed in tamper- evident packaging, or
• Locked in a secure cabinet and/or sealed in tamper-evident packaging at all times, or
• Locked in a secure cabinet and/or sealed in tamper-evident packaging at all times, or
• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;
• For all access to KLDs and authenticated application-signing devices.
• Locked in a secure cabinet and/or sealed in tamper- evident packaging, or
• Locked in a secure cabinet and/or sealed in tamper-evident packaging at all times, or
• Locked in a secure cabinet and/or sealed in tamper-evident packaging at all times, or
Added
p. 179
• For each type/model of POI and/or HSM: o Number of devices o Type of key(s) injected o Key-distribution method
• For each type/model of POI and/or HSM: o Number of devices o Type of key injected o Key-distribution method
• Details of any known or suspected compromised keys, per 6F-2.1
• Types/models of POIs for which keys have been injected
• For each type/model of POI: o Number of POI devices o Type of key injected o Key-distribution method
• For each type/model of POI and/or HSM: o Number of devices o Type of key injected o Key-distribution method
• Details of any known or suspected compromised keys, per 6F-2.1
• Types/models of POIs for which keys have been injected
• For each type/model of POI: o Number of POI devices o Type of key injected o Key-distribution method
Added
p. 183
• POIs only communicate with KDHs for key management, normal transaction processing, and certificate (entity) status checking.
• POIs only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking.
• KDHs only communicate with POIs for the purpose of key management and normal transaction processing;
• KDHs only communicate with POIs for the purpose of key management and normal transaction processing;
• New certificate issue request
• Certificate replacement request
• Encrypted using an algorithm and key size of equivalent or greater strength, or
• As components using a recognized (e.g., Shamir) secret-sharing scheme.
• New certificate issue request
• Certificate replacement request
• Encrypted using an algorithm and key size of equivalent or greater strength, or
• As components using a recognized (e.g., Shamir) secret-sharing scheme.
• Notify affected entities.
• Notify affected entities.
• EPP/PED devices and KDHs have a minimum RSA 1024 bits or equivalent.
• POIs only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking.
• KDHs only communicate with POIs for the purpose of key management and normal transaction processing;
• KDHs only communicate with POIs for the purpose of key management and normal transaction processing;
• New certificate issue request
• Certificate replacement request
• Encrypted using an algorithm and key size of equivalent or greater strength, or
• As components using a recognized (e.g., Shamir) secret-sharing scheme.
• New certificate issue request
• Certificate replacement request
• Encrypted using an algorithm and key size of equivalent or greater strength, or
• As components using a recognized (e.g., Shamir) secret-sharing scheme.
• Notify affected entities.
• Notify affected entities.
• EPP/PED devices and KDHs have a minimum RSA 1024 bits or equivalent.
Added
p. 195
• The identity of the person authorizing the operation
• The identities of all persons handling any key material
• The identities of all persons handling any key material
Added
p. 201
• The CPS must be consistent with the requirements described within this document.
• For all certificates issued
• For all certificates issued
Added
p. 209
• The system records to time-lapse VCRs or similar mechanisms.
• Unauthorized entry attempts
• Name and signature of the individual
• Name and signature of the individual
• Date and time in and out
• Date and time in and out
• Reason for access or purpose of visit
• Reason for access or purpose of visit
• Unauthorized entry attempts
• Name and signature of the individual
• Name and signature of the individual
• Date and time in and out
• Date and time in and out
• Reason for access or purpose of visit
• Reason for access or purpose of visit
Added
p. 216
• The PCI PTS or FIPS 140 Approval Number
• The PCI PTS or FIPS 140 Approval Number
• 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 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 random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 6B-1.1.c Verify devices used for key generation are those as noted above, including validation of the firmware used.
• Key-generation devices that generate clear-text key components be powered …
• The PCI PTS or FIPS 140 Approval Number
• 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 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 random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 6B-1.1.c Verify devices used for key generation are those as noted above, including validation of the firmware used.
• Key-generation devices that generate clear-text key components be powered …
Added
p. 228
• Observe the process for conveying public keys and interview responsible personnel to verify that self-signed certificates must not be used as the sole method of authentication.
• Under the continuous supervision of a person with authorized access to this component, or
• Under the continuous supervision of a person with authorized access to this component,
• Under the continuous supervision of a person with authorized access to this component,
• Under the continuous supervision of a person with authorized access to this component, or
• Under the continuous supervision of a person with authorized access to this component,
• Under the continuous supervision of a person with authorized access to this component,
Added
p. 232
• Verify that: o TDEA keys used for encrypting keys must be at least triple-length keys (have bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment. o A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength. o TDEA keys are not used to protect AES keys. o TDEA keys shall not be used to encrypt keys greater in strength than 112 bits. o RSA keys encrypting keys greater in strength than 80 bits have bit strength at least 112 bits.
Added
p. 236
• Asymmetric techniques
• Logical dual control via multiple logins with unique user IDs to the key-injection platform application such that no one person can operate the application to singly inject cryptographic keys into devices
• Key-injection platform applications that force the entry of multiple key components and the implementation of procedures that involve multiple key custodians who store and access key components under dual-control and split- knowledge mechanisms
• Demonstrable procedures that prohibit key custodians from handing their components to any other individual for key entry 6D-1.9.a Examine documented key-injection procedures to verify that the procedures define use of dual control and split knowledge controls for the loading of keys into devices.
• Logical dual control via multiple logins with unique user IDs to the key-injection platform application such that no one person can operate the application to singly inject cryptographic keys into devices
• Key-injection platform applications that force the entry of multiple key components and the implementation of procedures that involve multiple key custodians who store and access key components under dual-control and split- knowledge mechanisms
• Demonstrable procedures that prohibit key custodians from handing their components to any other individual for key entry 6D-1.9.a Examine documented key-injection procedures to verify that the procedures define use of dual control and split knowledge controls for the loading of keys into devices.
Added
p. 241
• Instructions to erase or otherwise destroy all traces of the component from the electronic medium.
• Dedicated to only the key-loading function (e.g., there must not be any other application software installed); and
• Located in a physically secure room that is dedicated to key-loading activities.
• Dedicated to only key loading
• Dedicated to only the key-loading function (e.g., there must not be any other application software installed); and
• Located in a physically secure room that is dedicated to key-loading activities.
• Dedicated to only key loading
Added
p. 249
• Be within a certificate as defined in Annex A; or
• Be within a PKCS#10; or
• Be within an SCD; or
• Controls to protect against unauthorized substitution of keys, and
• Controls are implemented that protect against unauthorized substitution of keys, and
• Keys used for testing keys must never be present or used in a production system.
• Prior to reuse for production purposes the HSM is returned to factory state,
• The relevant production keying material is restored using the principles of dual control and split knowledge as stated in these requirements.
• Known only to a single POI device, and
• The size and sources of the parameters involved, and
• At least two separate key shares or full-length components
• Encrypted with a key of equal or greater strength as delineated in Annex C
• Be within a PKCS#10; or
• Be within an SCD; or
• Controls to protect against unauthorized substitution of keys, and
• Controls are implemented that protect against unauthorized substitution of keys, and
• Keys used for testing keys must never be present or used in a production system.
• Prior to reuse for production purposes the HSM is returned to factory state,
• The relevant production keying material is restored using the principles of dual control and split knowledge as stated in these requirements.
• Known only to a single POI device, and
• The size and sources of the parameters involved, and
• At least two separate key shares or full-length components
• Encrypted with a key of equal or greater strength as delineated in Annex C
Added
p. 260
• Identification of key personnel
• 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 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
• 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
• Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities
• 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 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
• 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
• Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities
Added
p. 264
• Specific authorization for the custodian
• Specific authorization for the custodian
• Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them
• Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them
• Signature of the custodian acknowledging their responsibilities
• Signature of the custodian acknowledging their responsibilities
• An effective date for the custodian’s access
• An effective date for the custodian’s access
• Signature of management authorizing the access 6F-5.1.3 Examine all key-custodian forms to verify that they include the following:
• Removed from secure storage
• Security awareness training
• Background checks for personnel (within the constraints of local laws
• Specific authorization for the custodian
• Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them
• Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them
• Signature of the custodian acknowledging their responsibilities
• Signature of the custodian acknowledging their responsibilities
• An effective date for the custodian’s access
• An effective date for the custodian’s access
• Signature of management authorizing the access 6F-5.1.3 Examine all key-custodian forms to verify that they include the following:
• Removed from secure storage
• Security awareness training
• Background checks for personnel (within the constraints of local laws
Added
p. 276
• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;
• To enable any manual key-encryption functions and any key-encryption functions that occur outside of normal transaction processing;
• Locked in a secure cabinet and/or sealed in tamper- evident packaging, or
• Under the continuous supervision of at least two authorized people at all times.
• Under the continuous supervision of at least two authorized people at all times.
• Anti-pass-back requirements.
• Dual-access for entry to the secure area
• 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
• Under the continuous supervision of at least two authorized people at all times.
• Under the continuous supervision of at least two authorized people at all times.
• Anti-pass-back requirements.
• Dual-access for entry to the secure area
Added
p. 282
• For each type/model of POI and/or HSM: o Number of devices o Type of key(s) injected o Key-distribution method
• For each type/model of POI and/or HSM: o Number of devices o Type of key injected o Key-distribution method
• Types/models of POIs for which keys have been injected
• For each type/model of POI: o Number of POI devices o Type of key injected o Key-distribution method
• For each type/model of POI and/or HSM: o Number of devices o Type of key injected o Key-distribution method
• Types/models of POIs for which keys have been injected
• For each type/model of POI: o Number of POI devices o Type of key injected o Key-distribution method
Added
p. 285
NOTE: Any entity performing Remote Key-Distribution Using Asymmetric Techniques Operations must additionally complete Annex A1, either as part of the Solution Assessment or as part of their respective Component Provider assessment.
NOTE: Any entity performing Certification and Registration Authority Operations with respect to remote key distribution must additionally complete Annex A2, either as part of the Solution Assessment or as part of their respective Component Provider assessment.
NOTE: Any entity performing Certification and Registration Authority Operations with respect to remote key distribution must additionally complete Annex A2, either as part of the Solution Assessment or as part of their respective Component Provider assessment.
Added
p. 294
Domain Solution Provider P2PE Application Encryption- Management Services Entity Decryption- Management Services Entity KIF Services CA/RA Services Entity Domain 1: Encryption Device and Application Management X Domain 2: Application Security X Domain 3: P2PE Solution Management X Domain 4: Merchant-managed Solutions X Domain 5: Decryption Environment X Domain 6: P2PE Cryptographic Key Operations and Device Management Domain 6 Annex A X as applicable X as applicable Domain 6 Annex B
Modified
p. 9
Encryption-management services (Domains 1 & 6 including Annex A as applicable) Decryption-management services (Domains 5 & 6 including Annex A as applicable), Key-Injection facility services (Annex B of Domain 6 including Annex A as applicable) Certification Authority/Registration Authority services (Domain 6 and Annex A Part A2, including Annex A1 as applicable) Note that P2PE component providers are allowed to outsource elements of their respective P2PE domain(s); however, they are still ultimately responsible for ensuring all P2PE requirements for the applicable …
Modified
p. 11
• Submit the application P2PE Report on Validation (P-ROV) to PCI SSC for review and acceptance, and
Modified
p. 11
• Submit the application P-ROV to PCI SSC along with the solution P-ROV.
Modified
p. 11
• P2PE non-payment software is assessed only per designated P2PE Domain 1 Requirements at 1C-2 during the assessment of the P2PE solution(s) in which the application will be used. Note that this software is not subject to P2PE Domain 2 Requirements.
Modified
p. 11
• P2PE non-payment software is not eligible for PCI-listing.
Modified
p. 12
P2PE Domain Entity Undergoing P2PE Validation Encryption Device and Application Management Solution provider OR Merchant as a solution provider OR Encryption-management services component provider Application Security Solution provider OR Merchant as a solution provider OR P2PE application vendor P2PE Solution Management Solution provider OR Merchant as a solution provider Merchant-managed Solutions 2 Merchant as a solution provider Decryption Environment Solution provider OR Merchant as a solution provider OR …
P2PE Domain Entity Undergoing P2PE Validation Encryption Device and Application Management • Solution provider OR • Merchant as a solution provider OR • Encryption-management services component provider Application Security • Solution provider OR • Merchant as a solution provider OR • P2PE application vendor P2PE Solution Management • Solution provider OR • Merchant as a solution provider Merchant-managed Solutions 2 • Merchant as a solution provider Decryption Environment • Solution provider OR • Merchant as a solution provider OR • …
Modified
p. 14
All PCI-approved POI devices included in the P2PE solution (for the merchant to use for payment acceptance).
Modified
p. 14
• Security requirements for P2PE applications
• P2PE non-payment software (those with no access to clear-text account data
•e.g., a loyalty or advertising application) Domain 2
• Security requirements for P2PE applications For software with access to clear-text account data intended for use on POI devices.
•e.g., a loyalty or advertising application) Domain 2
• Security requirements for P2PE applications For software with access to clear-text account data intended for use on POI devices.
Modified
p. 14
The solution provider’s overall management of the P2PE solution including any third-party relationships, communications between various P2PE entities, and/or use of P2PE component providers.
Modified
p. 14
The merchant-focused P2PE Instruction Manual (PIM) that the solution provider prepares for and distributes to merchants (for their encryption environments), including completion of the PCI-provided PIM Template.
Modified
p. 14
Specifies requirements for the separation between the merchant encryption environment(s) and the merchant decryption environment.
Modified
p. 14
Management of all system components located within or connected to the decryption environment, including those used for decryption of account data, and Maintenance of PCI DSS compliance for the decryption environment.
Modified
p. 14
Domain 6
• P2PE Key- Management Operations Secure key management
•including all HSMs, key-loading devices, etc.
• P2PE Key- Management Operations
•including all HSMs, key-loading devices, etc.
Domain 6
• P2PE Key- Management Operations Secure key management
•including all HSMs, key-loading devices, etc.
• P2PE Key- Management Operations Secure key management
•including all HSMs, key-loading devices, etc.
Modified
p. 15
POI devices (for account data encryption) are approved per PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements.
Modified
p. 15
HSMs in the decryption environment used for account-data decryption and related cryptographic-key operations are approved per PCI PTS HSM (or FIPS 140-2 level 3).
Modified
p. 15
Cryptographic-key operations for both encryption and decryption environments using key-management practices derived from the PTS PIN Security Standard.
Modified
p. 15
Applications on POI devices with access to clear-text data meet requirements derived from the Payment Application Data Security Standard (PA-DSS).
Modified
p. 15
The decryption environment is PCI DSS compliant.
Modified
p. 15
POI devices and applications/software must include every unique combination of hardware, firmware, and versions and configurations of both P2PE applications and P2PE non-payment software used by the solution.
Modified
p. 15
Samples of keys / key components must include all key types and/or functions.
Modified
p. 16
Document the rationale behind the sampling technique and sample size, Document any standardized processes and controls used to determine sample size, Document how it was verified that the standardized processes/controls ensure consistency and apply to all items in the population, and Explain how the sample is appropriate and representative of the overall population.
Modified
p. 16
P2PE Report on Validation submission and acceptance processes.
Modified
p. 16
Annual renewal process for solutions included on the list of Validated P2PE Solutions.
Modified
p. 16
Vendor Release Agreements for vendors and providers of P2PE solutions, applications, and solution components.
Modified
p. 16
The P2PE Designated Change process for all new PCI-approved POI devices or P2PE applications added to an existing P2PE solution after validation.
Modified
p. 16
Notification responsibilities in the event a listed P2PE solution is determined to be at fault in a compromise.
Modified
p. 21
• 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. 21
• SRED listed as a function provided 1A-1.1.1 The POI device’s SRED capabilities must be enabled and active.
Modified
p. 22
• Implementing configurations that prevent all non-SRED validated capture mechanisms from being used for P2PE transactions.
Modified
p. 22
• All non-validated capture mechanisms are either disabled or configured to prevent their use for P2PE transactions, prior to devices being deployed to merchant encryption environments.
Modified
p. 22
• 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.
Modified
p. 22
• IP Services 1A-1.3 For all POI device types that implement open protocols, examine device configurations and review the list of approved PTS devices at www.pcisecuritystandards.org, to verify that all POI devices that implement open protocols used in this solution are listed. Confirm each such device has a valid SSC listing number on the PCI SSC website under “Approved PCI PTS Devices” with “OP” listed as a “function provided”.
Modified
p. 23
• 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. 23
• Version number 1A-2.1.b For applications not on the PCI SSC list of Validated P2PE Applications, review the application P-ROV(s) and verify that the applications used in the solution match the application P-ROV in the following characteristics:
Modified
p. 23
• Version number 1A-2.2 All applications on POI devices with access to clear- text account data must only be deployed on POI device types that are:
Modified
p. 23
• Explicitly included in the Domain 2 assessment for that application.
Modified
p. 23
• Explicitly included in that application’s listing 1A-2.2.b For applications not on the PCI SSC list of Validated P2PE Applications, review the application P-ROV and verify the POI device types the application is used on are:
Modified
p. 23
• Explicitly included in that P-ROV as assessed for that application.
Removed
p. 24
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.
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.
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.
Modified
p. 24
• Cannot enable disabled device interfaces or disabled data-capture mechanisms 1B-1.1.a Examine documented POI device configuration procedures and account privilege assignments to verify that merchant logical access to POI devices is restricted as follows:
Modified
p. 24
• Cannot enable disabled device interfaces or disabled data-capture mechanisms 1B-1.1.b For a sample of all POI devices used in the solution, logon to the device using an authorized test merchant account. Verify that merchant-account logical access meets the following:
Modified
p. 24
• Cannot enable disabled device interfaces or disabled data-capture mechanisms 1B-1.1.c Observe a sample of POI device configurations and interview responsible personnel to verify that the defined merchant-access requirements are configured for all devices used in the solution.
Modified
p. 25
• The solution provider must document which payment application(s) facilitates printing of PANs for merchants.
Modified
p. 25
• 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.
Modified
p. 25
• All personnel with access to devices are documented in a formal list.
Modified
p. 25
• All personnel with access to devices are authorized by management.
Modified
p. 25
• The list of authorized personnel is reviewed at least annually.
Modified
p. 27
• 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. 28
• The origin of the update is authenticated 1B-3.2 An up-to-date inventory of POI device system builds must be maintained and confirmed at least annually and upon any changes to the build.
Modified
p. 28
• Procedures for confirming all builds at least annually and upon any changes to the 1B-3.2.b Review documented inventory of devices, and examine the inventory of system builds to verify:
Modified
p. 28
• The inventory includes all POI device system builds.
Modified
p. 28
• The inventory of POI device system builds is up-to-date.
Modified
p. 28
• Upon any changes to the build 1B-3.3 Critical software security updates must be deployed to POI devices in the field within 30 days of receipt from device vendors or application vendors.
Modified
p. 29
• Secure deletion of such data immediately after use 1B-4.1.b For a sample of recent troubleshooting requests, observe data collection and storage locations, and interview responsible personnel to verify the procedures identified at 1B-4.1.a were followed.
Modified
p. 30
• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) 1B-5.1.b Observe authorized personnel perform authorized changes on POI devices, as follows, and examine log files to verify that all such activities result in a correlating log file:
Modified
p. 32
• Implementing whitelisting functionality in accordance with the device vendor's security guidance or the application’s Implementation Guide.
Modified
p. 32
• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
Modified
p. 32
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 32
• Documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o The identity of the authorized person 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 Aligns with 2A-3.4 1C-1.2 Review documented policies and procedures and interview personnel to verify that processes for implementing any whitelisting functionality include:
Modified
p. 32
• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
Modified
p. 32
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 32
• Documentation for all new installations and updates to whitelist functionality that includes the following: o Description and justification for the functionality o The identity of the authorized person 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 1C-1.2.1 Any whitelisting functionality must only allow the output of clear-text account data for non-PCI payment brand account/card data.
Modified
p. 33
• Cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
Modified
p. 33
• Cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
Modified
p. 33
• Cryptographically authenticated by the POI device’s firmware in accordance with the device vendor's security guidance or the application’s Implementation Guide.
Modified
p. 33
• Cryptographically authenticated by the POI device firmware, in accordance with the device vendor's security guidance or the application’s Implementation Guide.
Modified
p. 33
• Coverage for both new installations and updates to such functionality.
Modified
p. 33
• Coverage for both new installations and updates to such functionality.
Modified
p. 33
• Description and justification for the functionality.
Modified
p. 33
• Description and justification for the functionality.
Modified
p. 33
• The identity of the person who approved the new installation or update prior to release.
Modified
p. 33
• The identity of the person who approved the new installation or update prior to release.
Modified
p. 33
• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
Modified
p. 33
• Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
Modified
p. 34
• Does not have any logical interfaces (e.g., application programming interfaces (APIs)) that allow for the storing, processing, or transmitting of account data.
Modified
p. 34
• Is cryptographically authenticated by the POI device’s firmware.
Modified
p. 34
• Requires dual control for the application-signing process.
Modified
p. 34
• Review of the application vendor’s documentation to determine all logical interfaces used by the application/software.
Modified
p. 34
• Documenting how the solution provider confirmed that the application has no logical interfaces that allow for storing, processing, or transmitting account data
Modified
p. 35
• Following vendor guidance in the application’s Implementation Guide.
Modified
p. 35
• Documented approval for all changes by appropriate personnel.
Modified
p. 35
• Documented reason and impact for all changes.
Modified
p. 35
• Functionality testing of all changes on the intended device(s).
Modified
p. 35
• Documented back-out procedures for application installations/updates.
Modified
p. 35
• Guidance in the Implementation Guide is followed.
Modified
p. 35
• All changes to applications include documented approval by appropriate authorized solution-provider personnel.
Modified
p. 35
• All changes to applications are documented as to reason and impact of the change.
Modified
p. 35
• Functionality testing of all changes on the intended devices is performed.
Modified
p. 35
• Documentation includes back-out procedures for application installations/updates.
Modified
p. 35
• Documentation includes back-out procedures for application installations/updates.
Modified
p. 35
• All Implementation Guide requirements were followed.
Modified
p. 35
• Approval of the change by appropriate parties is documented.
Modified
p. 35
• The documentation includes reason and impact of the change.
Modified
p. 35
• The documentation describes functionality testing that was performed.
Modified
p. 36
• Cryptographic signing processes for applications are followed as specified in the Implementation Guide.
Modified
p. 36
• Cryptographic signing (or similar) is performed prior to installation only by authorized personnel using dual control.
Modified
p. 36
• All new installations and updates to applications are signed prior to installation on the device.
Modified
p. 36
• Cryptographic signing for new installations and updates to applications is done under dual control.
Modified
p. 36
• The solution provider retains a current copy of the Implementation Guide.
Modified
p. 36
• 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. 37
• Number of devices deployed and any change in numbers since last report.
Modified
p. 37
• Date of last inventory of POI device system builds.
Modified
p. 37
• Date of last inventory of POI device system builds.
Modified
p. 37
• Number of devices deployed and change since last report.
Modified
p. 37
• Number of devices deployed and change since last report.
Modified
p. 37
• Date of last inventory of POI device system builds..
Modified
p. 38
• Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change.
Modified
p. 38
• Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change.
Modified
p. 38
• Adding, changing, and/or removing P2PE non-payment software (without access to clear-text account data), including description of change.
Modified
p. 41
• Model name and number • Hardware version number • Firmware version number • SRED listed as a function provided.
Modified
p. 41
• Hardware version number • Firmware version number • SRED listed as a function provided.
Modified
p. 41
• Application must not store PAN data after the payment transaction is complete.
Modified
p. 41
• Application must not store SAD after authorization is complete.
Modified
p. 41
• How it uses PAN and/or SAD for its application processing.
Modified
p. 41
• How it ensures the application does not store PAN after the payment transaction is complete.
Modified
p. 41
• How it ensures the application does not store SAD after authorization is complete.
Modified
p. 41
• PAN is not stored after the payment transaction is completed.
Modified
p. 41
• SAD is not stored after authorization is completed.
Modified
p. 42
• PAN is not stored after the payment transaction is completed.
Modified
p. 42
• SAD is not stored after authorization is completed.
Modified
p. 44
• The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms.
Modified
p. 44
• The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms.
Modified
p. 44
• The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and does not include any functionality that sends clear-text PANs to any devices attached via cabling or other networking mechanisms.
Modified
p. 45
• A list of all logical interfaces for the application, and the function/purpose of each.
Modified
p. 45
• The logical interfaces intended for sharing of clear-text account data (e.g., those used to pass clear-text data back to the approved firmware of the POI device).
Modified
p. 45
• The logical interfaces not intended for sharing of clear-text account data (e.g., those for communication with other applications).
Modified
p. 46
• A list of the external communication methods included in the POI device vendor’s security guidance.
Modified
p. 46
• A list of which approved external communication methods are used by the application.
Modified
p. 46
• A description of where external communications are used by the application.
Modified
p. 47
• How to configure the whitelisting functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data.
Modified
p. 47
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
Modified
p. 47
• How to perform cryptographic authentication by the POI device’s firmware.
Modified
p. 47
• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 47
• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 47
• That such functionality must be approved by authorized personnel prior to implementation.
Modified
p. 47
• That such functionality must be approved by authorized personnel prior to implementation.
Modified
p. 47
• That all new installations or updates to whitelist functionality must include the following: o Description and justification for the functionality. o Who approved the new installation or updated functionality prior to release. o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data.
Modified
p. 47
• How to configure the application functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data
Modified
p. 47
• How to establish cryptographically authentication by the POI device’s firmware.
Modified
p. 47
• That documentation for all new installations or updates to whitelist functionality includes the following: o Description and justification for the functionality. o Who approved the new installation or updated functionality prior to release. o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data.
Modified
p. 48
• Processes are based on industry standards and/or best practices.
Modified
p. 48
• Information security is included throughout the software development life cycle.
Modified
p. 48
• Applications are developed in accordance with all applicable P2PE requirements.
Modified
p. 48
• Incorporated into the application developer’s written software development processes.
Modified
p. 48
• Implemented per the POI device vendor's security guidance.
Modified
p. 48
• Examine written software development processes and interview software developers.
Modified
p. 48
• Examine testing documentation and samples of test data, observe testing processes, and interview software-testing personnel.
Modified
p. 48
• Examine the final application product.
Modified
p. 49
• Reviews are performed by an individual, other than the code author, who is knowledgeable in code-review techniques and secure coding practices.
Modified
p. 49
• Changes to code that manages security-sensitive configuration options are reviewed to confirm that they will not result in the exposure of PCI payment-brand accounts/cards.
Modified
p. 49
• Code reviews ensure code is developed according to secure coding guidelines.
Modified
p. 50
• Instructions detailing back-out or de-installation procedures for the application 2B-1.3.c Examine recent application changes, and trace those changes back to related change-control documentation. Verify that, for each change examined, the following was documented according to the change-control procedures:
Modified
p. 50
• Developing with least privilege.
Modified
p. 50
• Developing with least privilege.
Modified
p. 50
• Developing with fail-safe exception handling.
Modified
p. 50
• Developing with defensive (protective) techniques regarding the logical input interfaces of the application.
Modified
p. 50
• Developing with defensive (protective) techniques regarding the logical input interfaces of the application.
Modified
p. 50
• Developing with fail-safe defaults.
Modified
p. 51
• Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries.
Modified
p. 51
• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
Modified
p. 51
• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
Modified
p. 51
• Identification of all areas within the application that interact with account data, as well as any process- oriented outcomes that could lead to the exposure of account data.
Modified
p. 51
• A list of potential threats and vulnerabilities resulting from account-data flow analyses and assigned risk ratings (e.g., high, medium, or low priority) to each.
Modified
p. 51
• Implementation of appropriate corrections and countermeasures during the development process.
Modified
p. 51
• Implementation of appropriate corrections and countermeasures during the development process.
Modified
p. 51
• Documentation of application risk-assessment results for management review and approval.
Modified
p. 51
• Documentation of application risk-assessment results for management review and approval.
Modified
p. 51
• Coverage of all functions of the application, including but not limited to, security- impacting features and features that cross trust boundaries.
Modified
p. 51
• Identification of all areas within applications that interact with account data, as well as any process-oriented outcomes that could lead to the exposure of account data.
Modified
p. 51
• A list of potential threats and vulnerabilities resulting from account-data flow analyses, and assigned risk ratings (e.g., high, medium, or low priority) to each.
Modified
p. 52
• Secure application design.
Modified
p. 52
• Secure coding techniques to avoid common coding vulnerabilities (e.g., vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.).
Modified
p. 52
• Managing sensitive data in memory.
Modified
p. 52
• Security testing (e.g., penetration testing techniques).
Modified
p. 52
• Risk-assessment techniques.
Modified
p. 53
• Details of how the elements of the version scheme are in accordance with requirements specified in the P2PE Program Guide.
Modified
p. 53
• The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric characters).
Modified
p. 53
• Definition of what each element represents in the version scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.).
Modified
p. 53
• Definition of elements that indicate use of wildcards.
Modified
p. 54
• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application).
Modified
p. 54
• Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application).
Modified
p. 54
• Specific identification and definition of changes that: o Have no impact on functionality of the application or its dependencies o Have impact on application functionality but no impact on security or P2PE requirements o Have impact to any security functionality or P2PE requirement.
Modified
p. 54
• Specific identification and definition of changes that: o Have no impact on functionality of the application or its dependencies o Have impact on application functionality but no impact on security or P2PE requirements o Have impact to any security functionality or P2PE requirement.
Modified
p. 54
• How each type of change ties to a specific version number.
Modified
p. 54
• How each type of change ties to a specific version number.
Modified
p. 55
• Details of how wildcards are used in the versioning methodology.
Modified
p. 55
• Details of how wildcards are used in the versioning methodology.
Modified
p. 55
• Wildcards are never used for any change that has an impact on the security of the application and/or the POI device.
Modified
p. 55
• Wildcards are never used for any change that has an impact on the security of the application and/or the POI device.
Modified
p. 55
• Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change.
Modified
p. 55
• Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change.
Modified
p. 55
• Wildcard elements must not precede version elements that could represent security-impacting changes. Any version elements that appear after a wildcard element must not be used to represent security-impacting changes.
Modified
p. 55
• Any elements to the right of a wildcard cannot be used for a security-impacting change. Version elements reflecting a security-impacting change must appear “to the left of” the first wildcard element.
Modified
p. 55
• Wildcards are never used for any change that has an impact on security or any P2PE requirements.
Modified
p. 55
• Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are never be used to represent a security impacting change.
Modified
p. 55
• Wildcards are not used for any change that has an impact on security or any P2PE requirements.
Modified
p. 55
• Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are not used to represent a security impacting change.
Modified
p. 56
• Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change 2B-1.11 If an internal version mapping to published versioning scheme is used, the versioning methodology must include mapping of internal versions to the external versions.
Modified
p. 56
• Signature by an authorized party to formally approve release of the application or application update.
Modified
p. 56
• Confirmation that secure development processes were followed by the vendor.
Modified
p. 56
• Formal approval and signature by an authorized party.
Modified
p. 56
• Confirmation that that all secure development processes were followed.
Removed
p. 57
Link Layer protocols IP protocols Security protocols IP services
Modified
p. 57
• Any guidance that the POI device vendor intended for integrators/ resellers, solution providers, and/or end-users 2B-2.1.1 The application must not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device vendor’s security guidance. This includes the use of:
Modified
p. 57
• Was developed according to the POI device vendor’s security guidance with respect to the documented Open Protocols.
Modified
p. 58
• A list of shared resources.
Modified
p. 58
• A description of how the application connects to and/or uses shared resources.
Modified
p. 58
• Instructions for how the application should be configured to ensure secure integration with shared resources.
Modified
p. 60
• A description of the purpose and encryption method for any encryption provided by the application in addition to SRED encryption 2B-4.1.b Perform a source-code review to verify that any application functionality facilitating the encryption of account data utilizes the approved cryptographic algorithm(s) and associated key-management functions of the POI device’s SRED firmware and is not implemented within the application itself.
Modified
p. 61
• Using outside sources for security vulnerability information.
Modified
p. 61
• Periodic testing of applications for new vulnerabilities.
Modified
p. 61
• New vulnerabilities are identified using outside sources of security vulnerability information.
Modified
p. 61
• All applications are tested for vulnerabilities.
Modified
p. 61
• A description of how the application is cryptographically authenticated using the approved security mechanisms of the POI device’s firmware for any application installations and updates.
Modified
p. 61
• Instructions for how to use the approved security mechanisms to perform application installations and updates.
Modified
p. 61
• A statement that application installations and updates cannot occur except by using the approved security mechanisms of the POI device’s firmware.
Modified
p. 62
• Instructions for how to sign the application.
Modified
p. 62
• Instructions how to implement the dual control for the application-signing process.
Modified
p. 62
• A statement that all applications must be signed via the instructions provided in the Implementation Guide.
Modified
p. 63
• Any changes to the application (e.g., device changes/upgrades and major and minor software changes).
Modified
p. 63
• Any changes to the application (e.g., device changes/upgrades and major and minor software changes).
Modified
p. 63
• Any changes to the Implementation Guide requirements in this document.
Modified
p. 63
• Any changes to the Implementation Guide requirements in this document.
Modified
p. 64
• A list of all logical interfaces for the application, and the function/purpose of each.
Modified
p. 64
• The logical interfaces not intended for sharing of clear-text account data (e.g., those for communication with other applications) 2A-3.3 The application only uses external communication methods included in the PCI- approved POI device evaluation and has not implemented its own external communication stack.
Modified
p. 65
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
Modified
p. 65
• How to configure the application functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data
Modified
p. 65
• How to configure the whitelisting functionality to ensure the output of clear- text account data is prohibited, except for non-PCI payment brand account/card data.
Modified
p. 65
• That review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 65
• That documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that it was reviewed prior to release to only output non- PCI payment brand account/card data Details to describe any whitelisting functionality implemented by the application as follows:
Modified
p. 65
• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 66
• Instructions detailing back out or de-installation procedures for the application 2B-1.10 The vendor’s published versioning methodology must be communicated to customers and integrators/resellers.
Modified
p. 66
• Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change 2B-2.1 Where the application relies on the Open Protocol functionality of the POI device firmware, the application must be developed in accordance with the POI device vendor’s security guidance.
Modified
p. 66
• Any instructions on how to securely configure any configurable options, as applicable to the application’s specific business processing.
Modified
p. 66
• Any guidance that the POI device vendor intended for integrators/ resellers, solution providers, and/or end-users.
Modified
p. 66
• A description of how the device connects to and/or uses shared resources Instructions for how the application should be configured to ensure secure integration with shared resources 2B-3.1.1 The application developer must provide key- management security guidance describing how keys and certificates have to be used.
Modified
p. 66
• Key-management security guidance for solution providers, describing how cryptographic keys and certificates have to be used and managed.
Modified
p. 67
• A description of the purpose and encryption method for any encryption provided by the application in addition to SRED encryption 2C-2.1.1 All application installations and updates are cryptographically authenticated using the approved security mechanisms of the POI device’s firmware.
Modified
p. 67
• A statement that application installations and updates cannot occur except by using the approved security protocol of the POI device’s firmware 2C-2.1.2 The application developer includes guidance for whoever signs the application, including requirements for dual control over the application-signing process.
Modified
p. 67
• A statement that all applications must be signed via the instructions provided in the Implementation Guide.
Modified
p. 69
• Identification of all parts of the overall solution managed by the solution provider • Identification of any parts of the overall solution outsourced to third-party service providers • Identification of P2PE controls covered by each third- party service provider.
Modified
p. 69
• Identifies all components of the overall solution managed by the solution provider.
Modified
p. 69
• Identifies all components of the overall solution that have been outsourced to third-party solution providers.
Modified
p. 69
• Identifies all P2PE controls covered by each third-party service provider.
Modified
p. 69
• Shows all account data flows across systems and networks from the point the card data is captured through to the point the card data exits the decryption environment.
Modified
p. 69
• Is kept current and updated as needed upon changes to the environment.
Modified
p. 70
• To which region/country it applies Note that Domain 1 (at 1B-1.1.1) and Domain 2 (at 2A-3.1.2) also include requirements that must be met for any POI device and any P2PE application, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.
Modified
p. 70
• To which region/country it applies 3A-1.3.b Perform independent review of, or conduct interviews with responsible solution provider personnel, to verify that the exception to facilitate merchants’ access to full PANs is based on a legal/regulatory obligation and not solely for convenience.
Modified
p. 70
• Ensuring reports are received from all P2PE component providers as specified in the “Component providers ONLY: report status to solution providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider).
Modified
p. 70
• Ensuring reports are received from all P2PE component providers as specified in the “Component providers ONLY: report status to solution providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider).
Modified
p. 70
• Confirming reports include at least the details specified in the “Component providers ONLY: report status to solution providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider), and any additional details as agreed between a component provider and the solution provider.
Modified
p. 70
• Confirming reports include at least the details specified in the “Component providers ONLY: report status to solution providers” sections of Domains 1, 5, and/or 6 (as applicable to the component provider), and any additional details as agreed between a component provider and the solution provider.
Modified
p. 70
• Following up with the component provider to resolve any questions or changes in expected performance of the component provider.
Modified
p. 70
• Following up with the component provider to resolve any questions or changes in expected performance of the component provider.
Modified
p. 71
• Changes in overall solution architecture 3A-2.2.a Interview responsible personnel and review documentation to verify the solution provider has a formal process for ensuring P2PE controls are maintained when changes to the P2PE solution occur, including procedures for addressing the following:
Modified
p. 71
• Changes in overall solution architecture 3A-2.2.b For a sample of changes, verify changes were documented and the solution updated accordingly.
Modified
p. 71
• Physical device breaches • Tampered, missing, or substituted devices • Unauthorized logical alterations to devices (e.g., configuration, access controls, whitelists) • Failure of any device security control • Unauthorized use of sensitive functions (e.g., key- management functions) • Encryption/decryption failures
Modified
p. 71
• Encryption/decryption failures 3A-3.2 Upon detection of any suspicious activity defined at 3B-4.1, the POI device must be immediately removed, shut down, or taken offline until the integrity of the device is verified and the P2PE encryption mechanism is restored.
Modified
p. 72
• The merchant has provided written notification (signed by a merchant executive officer) formally requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement 3B-5.1).
Modified
p. 72
• The merchant has provided written notification (signed by a merchant executive officer) requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement 3B-5.1).
Modified
p. 72
• Details of whether any account data was transmitted from the POI device(s) during the time that encryption was malfunctioning or disabled 3A-3.3 Examine documented procedures and related records, and interview personnel to verify they maintain records of all suspicious activity, including the following details:
Modified
p. 72
• Identification of affected device(s), including make, model, and serial number • Identification of affected merchant, including specific sites/locations if applicable • Date/time of incident • Duration of device downtime • Date/time that the issue was resolved
• Identification of affected device(s), including make, model, and serial number
• Identification of affected merchant, including specific sites/locations if applicable
• Date/time of incident
• Duration of device downtime
• Date/time that issue was resolved • Details of whether any account data was transmitted from the POI …
• Identification of affected device(s), including make, model, and serial number
• Identification of affected merchant, including specific sites/locations if applicable
• Date/time of incident
• Duration of device downtime
• Date/time that issue was resolved • Details of whether any account data was transmitted from the POI …
Modified
p. 73
• Updating the solution and/or controls to prevent cause from recurring 3A-3.5.a Interview responsible personnel and review documentation to verify the solution provider has a formal process for any P2PE control failures, including procedures for addressing the following:
Modified
p. 73
• Implementing controls to prevent cause from recurring 3A-3.6.b For a sample of P2PE control failures, interview personnel and review supporting document to verify that:
Modified
p. 73
• Identification occurred.
Modified
p. 73
• Corrective actions were implemented and documented.
Modified
p. 73
• The solution and/or control was updated accordingly.
Modified
p. 73
• Copy of the formal notification from merchant 3A-4.1.2 Observe implemented processes and interview responsible personnel to verify a record of all received requests is maintained and includes:
Removed
p. 74
All functions each third party is responsible for Agreement to maintain P2PE controls for which they are responsible Notification and documentation of any changes affecting the third party governed by P2PE requirements Notification of any security-related incidents Defining and maintaining appropriate service level agreements (SLAs) Maintaining compliance with applicable P2PE and/or
Modified
p. 74
• Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE Domain.
Modified
p. 74
• All functions each third party is responsible for • Maintaining P2PE controls for which they are responsible • Notification and documentation of any changes affecting the third party governed by P2PE requirements • Notification of any security-related incidents • Defining and maintaining appropriate service level agreements (SLAs) • Maintaining compliance with applicable P2PE and/or PCI DSS requirements as • Agreement to provide proof of compliance with P2PE requirements and/or PCI DSS requirements as needed • Agreement to provide reports …
Modified
p. 75
• Evidence of adherence to PCI’s process for P2PE Designated Changes to Solutions 3B-1.2 Verify formal agreements established for all third parties managing SCDs on behalf of the solution provider require:
Modified
p. 76
• All P2PE applications specified in the PIM are either PCI-listed P2PE applications or assessed to Domain 2 as part of this P2PE solution assessment 3C-1.1.f Examine the PIM to verify that all P2PE non-payment software specified in the PIM were assessed as part of this P2PE solution assessment (per Requirement 1C-2).
Modified
p. 76
• The PIM provides accurate instructions.
Modified
p. 76
• The PIM instructions result in a securely installed P2PE solution.
Modified
p. 77
• Any changes to the P2PE solution (including additions or removals of POI device types, P2PE applications, and/or P2PE non-payment software), and
Modified
p. 77
• PIM must be updated as needed to keep the document current with: o Any changes to the P2PE solution (including additions or removals of POI device types, P2PE applications, and/or P2PE non-payment software), and o Any changes to the P2PE requirements.
Modified
p. 77
• PIM is updated as needed to keep the document current with: o Any changes to the P2PE solution (including additions or removals of POI device types, P2PE applications, and/or P2PE non-payment software), and o Any changes to the P2PE requirements.
Modified
p. 79
Only use hardware-based decryption as part of the P2PE solution (use of hybrid decryption in a merchant-managed P2PE solution is not permitted).
Modified
p. 79
Satisfy all P2PE domain requirements (Domains 1, 2, 3, 5, and 6) in this standard, including this domain (Domain 4).
Modified
p. 79
Undergo a full P2PE assessment by a qualified P2PE assessor.
Modified
p. 81
• Services, protocols, daemons, etc. necessary for performing and/or supporting decryption operations must be documented and justified.
Modified
p. 81
• Functions not required for performing or supporting decryption operations must be disabled or isolated (e.g., using logical partitions) from decryption operations.
Modified
p. 82
• Be dedicated to supporting the decryption environment.
Modified
p. 83
• Wireless connections to the decryption environment are prohibited.
Modified
p. 83
• Processes are implemented to detect and immediately (as soon as possible) respond to physical connections (e.g., wireless connections) to the decryption environment.
Modified
p. 84
• Only traffic that is necessary for transaction processing and/or terminal management purposes All other traffic between the encryption environment and any other CDE must be specifically denied.
Modified
p. 84
• Only those systems (e.g., POI devices) directly related to supporting P2PE transactions, and • Only traffic that is necessary for transaction processing and/or terminal management Verify all other traffic between those two networks is specifically denied (e.g., by using an explicit “deny all” or an implicit deny after an allow statement).
Modified
p. 88
• FIPS140-2 Level 3 (overall) or higher certified, or
Modified
p. 88
• 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.
Modified
p. 88
• Listed on the PCI SSC website, with a valid PCI SSC listing number, as Approved
Modified
p. 88
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment (continued on next page) 5A-1.1.1.a For all PCI-approved HSMs used in the solution, examine HSM devices and review the PCI SSC list of Approved PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
Modified
p. 89
• Firmware version number 5A-1.1.1.c If the solution provider has applied a vendor security patch that resulted in an updated HSM firmware version, and the PCI SSC or NIST validation of that updated firmware version has not yet been completed, obtain the vendor documentation and verify it includes confirmation that the update has been submitted for evaluation per the process specified by PCI SSC or NIST (as applicable to the HSM).
Modified
p. 89
Note: Solution providers operating HSMs in non-FIPS mode or adding non-FIPS validated software must complete a written confirmation that includes the following: Description of why the HSM is operated in non-FIPS mode Purpose and description of any non-FIPS validated software added to the HSM A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements Note that adding any software may invalidate …
Note: Solution providers operating HSMs in non-FIPS mode or adding non-FIPS validated software must complete a written confirmation that includes the following:
Modified
p. 89
• A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements.
Modified
p. 91
• Use of HSM commands 5B-1.2.a Examine documented procedures to verify secure administration by authorized personnel is defined for decryption devices including:
Modified
p. 91
• Use of HSM commands 5B-1.2.b Observe authorized personnel performing device-administration operations to verify secure administration procedures are implemented for the following:
Modified
p. 92
• Procedures and/or mechanisms for authenticating POI devices upon request by the solution provider 5B-1.4.c Interview responsible personnel and observe a sample of device authentications to verify the following:
Modified
p. 92
• POI devices are authenticated upon connection to the decryption environment.
Modified
p. 92
• POI devices are authenticated upon request by the solution provider.
Modified
p. 93
• 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. 93
• Physically connected devices 5B-1.5.b Interview personnel performing physical inspections and observe inspection processes to verify that inspections include:
Modified
p. 93
• Physically connected devices 5B-1.5.c Interview personnel performing inspections and review supporting documentation to verify that physical inspections are performed at least quarterly.
Modified
p. 93
• Performed within the previous 12 months 5B-1.7 Processes are implemented to ensure that clear-text account data is never sent back to the encryption environment.
Modified
p. 94
• Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
Modified
p. 94
• Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
Modified
p. 94
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 94
• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 94
• Documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 5B-1.9 Review documented policies and procedures to verify that that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment ensures the that the …
Modified
p. 95
• 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. 95
• Cryptographically authenticated by the HSM 5B-1.9.3 Any new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must follow change-control procedures that include:
Modified
p. 95
• Cryptographically signed (or similar) prior to installation only by authorized personnel using dual control
• 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 • Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
• 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 • Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
Modified
p. 95
• Both new installations and updates to whitelisting functionality are documented.
Modified
p. 95
• The documentation includes description and justification.
Modified
p. 95
• The documentation includes who approved it prior to implementation.
Modified
p. 95
• The documentation includes confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
Removed
p. 96
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 5C-1.2.b Interview personnel and observe implemented mechanisms to verify mechanisms are implemented to detect and respond to suspicious activity, 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.b Interview personnel and observe implemented mechanisms to verify mechanisms are implemented to detect and respond to suspicious activity, including:
Modified
p. 96
• Changes to any security-sensitive configurations 5C-1.2 Mechanisms must be implemented to detect and respond to suspicious activity, including but not limited to:
Modified
p. 97
• Procedures are defined to detect encryption failures, and include 5C-1.3.1 through 5C-1.3.4 below.
Modified
p. 97
• Procedures include immediate notification upon detection of a cryptographic failure, for each 5C-1.3.1 through 5C-1.3.4 below.
Modified
p. 98
• Details of whether any account data was transmitted from the POI device during any identified time that encryption was malfunctioning or disabled 5C-1.4.a Examine documented procedures to verify they include procedures for identifying the source and maintaining a record, of all suspicious activity, to include at least the following:
Modified
p. 98
• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled 5C-1.4.b Observe implemented controls and interview responsible personnel to verify that the source of any suspicious activity is identified, and records are maintained to include the following:
Modified
p. 101
• The necessary services, protocols, daemons etc. must be documented and justified, including description of the enabled security features for these services etc.
Modified
p. 101
• Functions not related to transaction processing must be disabled, or isolated (e.g., using logical partitions), from transaction processing.
Modified
p. 102
• Testing integrity of cryptographic functions.
Modified
p. 102
• Testing integrity of cryptographic functions.
Modified
p. 102
• Testing integrity of firmware.
Modified
p. 102
• Testing integrity of any security functions critical to the secure operation of the Host System.
Modified
p. 102
• Testing integrity of any security functions critical to the secure operation of the Host System.
Modified
p. 102
• Testing integrity of software/firmware.
Modified
p. 103
• Failure of a system self-test, as described in Requirements 5D-1.6 and 5D-1.7
Modified
p. 103
• Failure of a security function or mechanism 5D-1.8.b Interview personnel and examine logs/records of actual or test alerts to verify that alerts are generated and received when the Host System enters an error state under one of the following conditions:
Modified
p. 103
• Failure of a security function or mechanism 5D-1.9 Alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.
Modified
p. 104
• During self-tests, as described in Requirements 5D- 1.6 and 5D-1.7
Modified
p. 104
• During self-tests, as described in Requirements 5D-1.6 and 5D-1.7.
Modified
p. 104
• During self-tests, as described in Requirements 5D-1.6 and 5D-1.7.
Modified
p. 104
• During diagnostics of cryptographic operations.
Modified
p. 104
• During diagnostics of cryptographic operations.
Modified
p. 105
• ‘Core dumps’ of memory required for troubleshooting.
Modified
p. 105
• Core dumps’ of memory required for trouble-shooting.
Modified
p. 105
• ‘Core dumps’ of memory required for trouble-shooting.
Modified
p. 106
• Core dumps must be securely deleted immediately after analysis.
Modified
p. 106
• Core dumps must be securely deleted immediately after analysis.
Modified
p. 106
• Memory ‘swap/page’ files must be securely deleted upon system shut down or reset.
Modified
p. 106
• Memory ‘swap/page’ files must be securely deleted upon system shut down or reset.
Modified
p. 107
• for day-to-day non- sensitive operations of the Host System.
• for day-to-day non- sensitive operations of the Host System.
Modified
p. 107
• configuration of cryptographic management functions Host System security role
• auditing of host functions 5D-2.5.a Examine documented access-control procedures to verify they define, as a minimum, the following roles:
• auditing of host functions 5D-2.5.a Examine documented access-control procedures to verify they define, as a minimum, the following roles:
Modified
p. 107
• for day-to-day non-sensitive operations of the Host System.
• for day-to-day non-sensitive operations of the Host System.
Modified
p. 107
• for day-to-day non-sensitive operations of the Host System.
• for day-to-day non-sensitive operations of the Host System.
Modified
p. 107
• configuration of cryptographic management Host System security role
• auditing of host functions 5D-2.5.b Inspect the Host System configuration settings to verify that role-based access control is enforced and, at a minimum, the following roles are defined:
• auditing of host functions 5D-2.5.b Inspect the Host System configuration settings to verify that role-based access control is enforced and, at a minimum, the following roles are defined:
Modified
p. 107
• configuration of cryptographic management
• auditing of host functions.
• configuration of cryptographic management functions
Modified
p. 108
• Requiring the participation of at least two persons.
Modified
p. 108
• Requiring the participation of at least two persons. Therefore, the party making the change cannot authorize the change on their own.
Modified
p. 108
• Requiring the participation of at least two persons. Therefore, the party making the change cannot authorize the change on their own.
Modified
p. 110
• Originate from and be managed by the solution provider.
Modified
p. 110
• Originate from and be managed by the solution provider.
Modified
p. 110
• Meet all applicable PCI DSS requirements.
Modified
p. 110
• Meet all applicable PCI DSS requirements.
Modified
p. 112
• Logs must be retained for a minimum of three years.
Modified
p. 112
• 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. 112
• Log reviews must be documented.
Modified
p. 112
• Logs must include but not be limited to: o Logs of access to the room from a badge access system o Logs of access to the room from a manual sign- in sheet 5D-4.3.a Examine documented policies and procedures to verify all physical access to the secure room must be monitored and logs must be maintained. Policies and procedures must require the following:
Modified
p. 112
• Logs are retained for a minimum of three years.
Modified
p. 112
• Logs are regularly reviewed by an authorized person who does not have access to the secure room or to the systems therein.
Modified
p. 112
• Log reviews are documented.
Modified
p. 112
• Log reviews are documented.
Modified
p. 112
• Logs include at a minimum: o Access to the room from a badge access system o Access to the room from a manual sign-in sheet 5D-4.3.b Examine a sample of logs used to record physical access to the secure room to verify the following:
Modified
p. 112
• Logs are being retained for a minimum of three years.
Modified
p. 112
• Logs include at a minimum: o Access to the room from a badge access system o Access to the room from a manual sign-in sheet 5D-4.3.c Interview personnel responsible for reviewing logs used to record physical access to the secure room, to verify the following:
Modified
p. 112
• Logs are regularly reviewed.
Modified
p. 112
• The person performing the review does not have access to the secure room or to the systems therein.
Modified
p. 113
• Access to the Host System and HSM(s)
Modified
p. 113
• Access to the Host System and HSM(s) 5D-4.6.b If CCTV is motion-activated, observe system configurations for the motion- activated systems to verify they are separate from the intrusion-detection system.
Modified
p. 114
• Continuous (24/7) physical intrusion-detection monitoring of the secure room.
Modified
p. 114
• 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. 114
• Provides continuous (24/7) monitoring of the secure room.
Modified
p. 114
• It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
Modified
p. 115
• A door that is contact monitored and fitted with automatic closing or locking devices.
Modified
p. 115
• A door that is contact monitored and fitted with automatic closing or locking devices.
Modified
p. 115
• An airlock entrance system.
Modified
p. 115
• An airlock entrance system.
Modified
p. 117
• Details of any suspicious activity that occurred, per 5C- 5E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel, and to confirm that the following processes are documented and implemented:
Modified
p. 117
• Details of any suspicious activity that occurred, per 5C-1.2 5E-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
Modified
p. 118
• Addition and/or removal of HSM types.
Modified
p. 118
• 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. 118
• Additions and/or removal of HSM types 5E-1.2.b Observe reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence:
Modified
p. 118
• Critical infrastructure changes, including to the PCI DSS environment
Modified
p. 121
Secret Key = symmetric key (also known as a shared secret key) Private Key = asymmetric key used only for decryption operations or for creating digital signatures. No one private key should be used for both purposes (except for transaction-originating SCDs).
Modified
p. 121
Public Key = asymmetric key used only for encryption operations or for verifying digital signatures. No one public key should be used for both purposes (except for transaction-originating SCDs).
Modified
p. 121
Domain 6 Normative Annex A
• Symmetric-Key Distribution using Asymmetric Techniques For specific requirements pertaining to entities involved in the implementation of symmetric-key distribution using asymmetric keys (remote key distribution) or those entities involved in the operation of Certification Authorities for such purposes, see Domain 6 Normative Annex A. Entities involved in remote key distribution are subject to both the requirements stipulated in the main body of the Domain 6 section of this document and the additional criteria stipulated in Annex …
• Symmetric-Key Distribution using Asymmetric Techniques For specific requirements pertaining to entities involved in the implementation of symmetric-key distribution using asymmetric keys (remote key distribution) or those entities involved in the operation of Certification Authorities for such purposes, see Domain 6 Normative Annex A. Entities involved in remote key distribution are subject to both the requirements stipulated in the main body of the Domain 6 section of this document and the additional criteria stipulated in Annex …
Domain 6 Normative Annex A
• Symmetric-Key Distribution using Asymmetric Techniques For specific requirements pertaining to entities involved in the implementation of symmetric-key distribution using asymmetric keys (remote key distribution) or those entities involved in the operation of Certification Authorities for such purposes, see Domain 6 Normative Annex A. Entities involved in remote key distribution or the operation of CA/RAs are subject to both the requirements stipulated in the main body of the Domain 6 section of this document and the …
• Symmetric-Key Distribution using Asymmetric Techniques For specific requirements pertaining to entities involved in the implementation of symmetric-key distribution using asymmetric keys (remote key distribution) or those entities involved in the operation of Certification Authorities for such purposes, see Domain 6 Normative Annex A. Entities involved in remote key distribution or the operation of CA/RAs are subject to both the requirements stipulated in the main body of the Domain 6 section of this document and the …
Modified
p. 123
• Crypto-periods are defined for every type of key in use.
Modified
p. 123
• Crypto-periods are based on industry best practices and guidelines (e.g., NIST Special Publication 800-57).
Modified
p. 123
• A process/methodology is in place to determine when the crypto-period is reached for each cryptographic key.
Modified
p. 123
• Cryptographic key changes are implemented whenever a key reaches the end of its defined crypto-period.
Modified
p. 124
• 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. 124
• Key-destruction method 6A-1.3.1.b Observe documentation and interview personnel and confirm that documentation of all cryptographic keys managed as part of the P2PE solution exists, and includes:
Modified
p. 125
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) 6A-1.3.2.a Examine key management policies and procedures and verify a list of all devices used to generate keys managed as part of the P2PE solution is required, and includes:
Modified
p. 125
• Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) 6A-1.3.2.b Observe documentation and interview personnel and confirm that a list of all devices used to generate keys managed as part of the P2PE solution exists, and includes:
Modified
p. 126
• 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.
Modified
p. 126
• An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.
Modified
p. 126
• An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 6B-1.1.c Observe devices performing key-generation functions, including validation of firmware used.
Modified
p. 126
• 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. 127
• Any clear-text output of the key-generation process is overseen by only the assigned key custodian(s) for that component/share and is limited to those individual components and not the entire key..
Modified
p. 127
• There is no mechanism (including connectivity) that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Modified
p. 127
• If logically partitioned for concurrent use in other processes, the key-generation capabilities are disabled when not in use and other activities are continuing.
Modified
p. 129
Examples of where such key residue may exist include (but are not limited to): Printing material, including ribbons and paper waste Memory storage of a key-loading device, after loading the key to a different device or system 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:
Examples of where such key residue may exist include (but are not limited to): • Printing material, including ribbons and paper waste
Modified
p. 130
• If generated externally, the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair 6B-2.5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:
Modified
p. 130
• 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. 130
• 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. 130
• Writing key or component values into startup 6B-2.6.a Examine documented policy and procedures to verify that clear-text private or secret keys or their components are prohibited from being transmitted across insecure channels, including but not limited to:
Removed
p. 131
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 manual 6B-3 Documented procedures must exist and must be demonstrably in use for all key-generation processing.
Modified
p. 131
• Writing key or component values in procedure manuals 6B-2.6.b From observation of key-management processes verify that key components are not transmitted across insecure channels, including but not limited to:
Modified
p. 132
• Where key components are transmitted in clear-text using pre-numbered, tamper-evident, authenticable mailers: o Components/shares must be conveyed using at least two separate communication channels, such as different courier services. Components/shares sufficient to form the key must not be conveyed using the same communication channel. o Ensure that details of the serial number of the package are conveyed separately from the package itself. o Ensure that that documented procedures exist and are followed to require that the serial numbers be …
Modified
p. 132
• Examine documented procedures to verify that cryptographic-key components are transferred using different communications channels.
Modified
p. 132
• Examine records of key conveyances and interview responsible personnel to verify that cryptographic key components are transferred using different communications channels.
Modified
p. 132
• Examine documented procedures to verify that serial numbers are verified prior to the usage of the keying material.
Modified
p. 133
• Where an SCD is used for components, the mechanisms or data (e.g., PIN) to obtain the key component from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
Modified
p. 133
• Where an SCD (HSM or KLD) is conveyed with pre- loaded secret and/or private keys, the SCD must require dual control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
Modified
p. 133
• Examine documented procedures to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
Modified
p. 133
• 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. 133
• Any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component or shares sufficient to form the necessary threshold to derive the key.
Modified
p. 133
• Any person with access to the media conveying a component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key.
Modified
p. 134
• An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Modified
p. 134
• Any person with access to the media conveying a key component or key share must not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Modified
p. 135
• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A
Modified
p. 135
• Within an SCD 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. 136
• 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
Modified
p. 136
• 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
Modified
p. 136
• 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
Modified
p. 136
• 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. 137
• Any keys encrypted under this (combined) key 6C-2.2.d Interview responsible personnel and observe processes to verify that if a package shows signs of tampering, processes are implemented that result in the destruction and replacement of both:
Modified
p. 137
• Any keys encrypted under this (combined) key 6C-2.3 Only the authorized key custodian (and designated backup(s)) shall have physical access to a key component prior to transmittal or upon receipt of a component.
Modified
p. 137
• Place key components into pre-numbered tamper- evident, authenticable packaging for transmittal.
Modified
p. 137
• Check tamper-evident packaging upon receipt for signs of tamper prior to opening tamper-evident authenticable packaging containing key components.
Removed
p. 139
Verify that: o 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. o A double- or triple-length DEA key must not be encrypted with a DEA key of lesser strength. o TDEA keys are not used to protect AES keys. o TDEA keys are not be used to encrypt keys greater in strength than 112 bits. o RSA keys encrypting keys greater in strength than 80 bits have bit strength at least 112 bits.
Modified
p. 139
• TDEA keys used for encrypting keys must be at least triple-length keys (have bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment.
Modified
p. 139
• A triple-length TDEA key must not be encrypted with a TDEA key of lesser strength.
Modified
p. 139
• TDEA keys shall not be used to protect AES keys.
Modified
p. 139
• TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
Modified
p. 139
• RSA keys encrypting keys greater in strength than 80 bits shall have bit strength of at least 112 bits.
Modified
p. 139
• Interview appropriate personnel and examine documented procedures for the creation of these keys.
Modified
p. 139
• 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.
Modified
p. 139
6C-3.1.c Examine system documentation and configuration files to validate the above, including HSM settings.
Modified
p. 141
• 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.
Modified
p. 141
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 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least triple-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits.
Modified
p. 142
• The existing TMK to encrypt the replacement TMK for Keys shall not be reloaded by any methodology in the event of a compromised device, and must be withdrawn from use.
Modified
p. 142
• Use public and private key lengths that are in accordance with Annex C for the algorithm in question.
Modified
p. 142
• Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Modified
p. 142
• 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.
Modified
p. 142
• Use of public and private key lengths that are in accordance with Annex C for the algorithm in question.
Modified
p. 142
• Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Modified
p. 142
• Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable.
Modified
p. 143
• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of clear-text key components.
Modified
p. 143
• There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys.
Modified
p. 143
• 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.
Modified
p. 143
• SCDs must be inspected to detect evidence of monitoring and to ensure dual control procedures are not circumvented during key loading.
Modified
p. 143
• 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. 143
• Ensure cameras are positioned to ensure they cannot monitor the entering of clear-text key components.
Modified
p. 143
• Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: o SCDs are inspected to detect evidence of monitoring and to ensure dual- control procedures are not circumvented during key loading. o An SCD transfers a plaintext secret or private key only when at least two authorized individuals are identified by the device. …
Modified
p. 144
Domain 6 Requirements Testing Procedures 6D-2.3 The loading of secret or private key components from electronic medium
•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 …
•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
Domain 6 Requirements Testing Procedures 6D-2.3 The loading of secret or private key components from electronic medium
•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
•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
Modified
p. 144
• 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
Modified
p. 144
• 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
Modified
p. 145
• Requirement that media/devices be in the physical possession of only the designated component holder(s).
Modified
p. 145
• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process.
Modified
p. 146
• Any hardware used in the key-loading function or for the signing of authenticated applications must be controlled and maintained in a secure environment under dual control.
Modified
p. 146
• 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. 146
• All hardware used in the key-loading function or for the signing of authenticated applications is controlled and maintained in a secure environment under dual control.
Modified
p. 146
• 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. 148
• 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. 149
• Be unique to those two entities or logically separate systems and
Modified
p. 149
• Specific actions that determine whether the legitimate value of the cryptographic key has changed. (For example, encryption of a known value to determine whether the resulting cryptogram matches the expected result.)
Modified
p. 150
• For a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices).
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices).
Modified
p. 150
• Private keys must never be used to encrypt other keys.
Modified
p. 150
• To create digital signatures or to perform decryption operations.
Modified
p. 150
• For a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both.
•a private key must only be used for either decryption or for creating digital signatures, but not both.
Modified
p. 150
• Private keys are never used to encrypt other keys.
Modified
p. 150
• To perform encryption operations or to verify digital signatures.
Modified
p. 150
• 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. 151
• Keys used for production must never be present or used in a test/development system, and
Modified
p. 151
• 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. 151
• Prior to reuse for production purposes the HSM is returned to factory state.
Modified
p. 151
• The relevant production keying material is restored using the principles of dual control and split knowledge as stated in these requirements.
Modified
p. 152
• Known only to HSMs at the minimum number of facilities consistent with effective system operations.
Modified
p. 152
• 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.
Modified
p. 153
• Unique data is used for the derivation process such that all transaction-originating POI devices receive unique secret keys.
Modified
p. 153
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device.
Modified
p. 153
• Different BDKs for each financial institution • Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model • 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.
Modified
p. 153
• Interview personnel and review documented procedures to determine that unique Base Derivation Keys are used for each acquiring organization.
Modified
p. 153
• 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. 154
• 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. 156
• Key components for different custodians are stored in separate secure containers.
Modified
p. 156
• Each secure container is accessible only by the custodian and/or designated backup(s).
Modified
p. 157
• Processing with that key is halted, and the key is replaced with a new unique key.
Modified
p. 157
• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key-replacement process.
Modified
p. 157
• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key.
Removed
p. 158
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. 158
• Specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Modified
p. 158
• Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Modified
p. 160
• Variants used as KEKs must only be calculated from other key-encrypting keys
Modified
p. 162
• A primary and a backup key custodian are designated for each component.
Modified
p. 162
• The fewest number of key custodians is assigned as necessary to enable effective key management.
Modified
p. 162
• Assigned key custodians are employees or contracted personnel.
Removed
p. 163
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 6F-5.1.3 Examine all key-custodian forms to verify that they include the following:
Modified
p. 163
• 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 6F-5.1.3 Examine all key-custodian forms to verify that they include the following:
• Specific authorization for the custodian
• Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to …
• Specific authorization for the custodian
• Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to …
Modified
p. 163
• Key custodians that form the necessary threshold to create a key do not directly report to the same individual.
Modified
p. 163
• 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. 164
• Ensure key custodians do not report to each other.
Modified
p. 164
• Receive explicit training to instruct them from sharing key components with their direct manager.
Modified
p. 164
• Sign key-custodian agreement that includes an attestation to the requirement.
Modified
p. 164
• Ensure training includes whistleblower procedures to report any violations.
Modified
p. 164
• 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. 164
• Loaded to an SCD 6F-6.1.b Review log files and audit log settings to verify that logs include the following:
Modified
p. 165
• Subject to at least the same level of security control as operational keys as specified in this document 6F-7.2 If backup copies are created, the following must be in place:
Modified
p. 165
• Creation (including cloning) of top-level keys MFKs•must require a minimum of two authorized individuals to enable the process.
Modified
p. 165
• The creation of any backup copies for top-level keys requires at least two authorized individuals to enable the process
Modified
p. 166
• Management of personnel changes, including revocation of access control and other privileges when personnel move 6F-8.1.a Examine documented procedures for key-administration operations to verify they cover all activities related to key administration, and include:
Modified
p. 166
• Management of personnel changes, including revocation of access control and other privileges when personnel move 6F-8.1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
Modified
p. 167
• POI devices have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 167
• POI devices have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 168
• All personnel with access to POI devices and other SCDs are documented in a formal list.
Modified
p. 168
• All personnel with access to POI devices and other SCDs are authorized by management.
Modified
p. 168
• The authorizations are reviewed annually.
Modified
p. 172
• Procedures require that all keys and key material, and all account data stored within the device be securely destroyed.
Modified
p. 172
• Procedures cover all devices removed from service permanently or for repair.
Modified
p. 172
• Procedures cover requirements at 6G-3.1.1 through 6G-3.1.6 below.
Removed
p. 174
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.
Modified
p. 174
• To enable any manual key-encryption functions and any key-encryption functions that occur outside of normal transaction processing;
Modified
p. 175
• Under the continuous supervision of at least two authorized people who ensure that any unauthorized use of the device would be detected.
Modified
p. 175
• Under the continuous supervision of at least two authorized people at all times.
Modified
p. 175
• Under the continuous supervision of at least two authorized people at all times.
Modified
p. 176
• 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).
Modified
p. 176
• 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).
Modified
p. 176
• DDKs are unique per transaction. Each DDK is erased from the host memory upon completion of the decryption process.
Modified
p. 176
• DDKs are unique per transaction. Each DDK is erased from the host memory upon completion of the decryption process.
Modified
p. 177
• A one-way derivation process must be used.
Modified
p. 177
• A one-way derivation process must be used.
Modified
p. 177
• The DDK must never be generated as a variant of the HSM master file key.
Modified
p. 177
• The DDK must never be generated as a variant of the HSM master file key.
Modified
p. 177
• The master key used to generate the DDK must be dedicated to generating DDKs.
Modified
p. 177
• The master key used to generated the DDK must be dedicated to generating DDKs.
Modified
p. 177
• A one-way derivation process is used.
Modified
p. 177
• The DDK is never generated as a variant of the HSM master file key.
Modified
p. 177
• The master key used to generate the DDK is dedicated to generating DDKs.
Modified
p. 179
• 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.
Modified
p. 179
• 6I-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
Modified
p. 180
• Remote Key-Distribution Using Asymmetric Techniques Operations: Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account data
A1
• Remote Key-Distribution Using Asymmetric Techniques Operations: Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account data encryption.
• Remote Key-Distribution Using Asymmetric Techniques Operations: Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key-distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account data encryption.
Modified
p. 180
• Certification and Registration Authority Operations: Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
A2
• Certification and Registration Authority Operations: Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
• Certification and Registration Authority Operations: Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
Modified
p. 180
• Certification Authority requirements apply to all entities (P2PE solution providers, P2PE component providers, and entities performing these functions on behalf of solution providers or component providers) signing public keys to be used for remote distribution of cryptographic keys, whether in X.509 certificate-based schemes or other designs, to allow for the required authentication of these signed public keys. For purposes of these requirements, a certificate is any digitally signed value containing a public key, where the term “digitally signed” refers …
Modified
p. 180
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates.
• The Certification Authority requirements are not intended to be applied to devices that sign their own keys, nor to key-loading systems where the key loading is not performed remotely and authentication is provided by another method
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates.
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates.
Modified
p. 182
• POI devices must validate authentication credentials of KDHs prior to any key transport, exchange, or establishment with that device.
Modified
p. 182
• KDHs must validate authentication credentials of POIs prior to any key transport, exchange, or establishment with that device.
Modified
p. 182
• POI devices validate authentication credentials of KDHs immediately prior to any key transport, exchange, or establishment with that device.
Modified
p. 182
• KDHs validate authentication credentials of POIs immediately prior to any key transport, exchange, or establishment with that device.
Modified
p. 182
• 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. 182
• System implementations must be designed and implemented to prevent replay attacks
•e.g., through the use of random nonces.
•e.g., through the use of random nonces.
Modified
p. 182
• There are no means available in the implementation design for “man- in-the-middle” attacks.
Modified
p. 182
• System implementations are designed to prevent replay attacks.
Modified
p. 182
• Examine documented procedures to verify that controls are defined to ensure the secrecy of private keys and the integrity of public keys during key transfer and loading.
Modified
p. 182
• Observe key transfer and loading operations to verify that the secrecy of private keys and the integrity of the public keys are ensured.
Modified
p. 182
• Verify the process ensures that key pairs are unique per POI device.
Modified
p. 183
• 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;
Modified
p. 183
• 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;
Modified
p. 183
• KDHs only to communicate with CAs for the purpose of certificate signing and certificate (entity) status checking.
Modified
p. 183
• KDHs only communicate with CAs for the purpose of certificate signing and certificate (entity) status checking.
Modified
p. 184
• Each key pair generated results in only one certificate 6E-3.6.b Interview responsible personnel and observe certificate issuing and replacement processes to verify that:
Modified
p. 184
• Only one certificate is requested for each key pair generated.
Modified
p. 184
• Certificates are replaced by generating a new key pair and requesting a new certificate.
Modified
p. 184
• Each key pair generated results in only one certificate.
Modified
p. 185
• Within a secure cryptographic device that meets applicable PCI requirements for such a device,
Modified
p. 186
• Examine documented procedures to verify that controls are defined to ensure the secrecy of private keys and the integrity of public keys during key transfer and loading.
Modified
p. 186
• Observe key transfer and loading operations to verify that the secrecy of private keys and the integrity of the public keys are ensured.
Modified
p. 186
• Verify the process ensures that key pairs are unique per POI device.
Modified
p. 187
• 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. 187
• Prior to reuse for production purposes the HSM is returned to factory state.
Modified
p. 187
• The relevant production keying material is restored using the principles of dual control and split knowledge as stated in these requirements.
Modified
p. 187
• Each key pair generated results in only one certificate 6E-3.6.b Interview responsible personnel and observe certificate issuing and replacement processes to verify that:
Modified
p. 187
• Only one certificate is requested for each key pair generated.
Modified
p. 187
• Certificates are replaced by generating a new key pair and requesting a new certificate.
Modified
p. 187
• Each key pair generated results in only one certificate.
Modified
p. 188
• Signature keys for updating valid/authorized host lists in POIs Must not be used for any purpose other than:
Modified
p. 188
• Certificate signature keys,
• Certificate status checking (e.g., Certificate Revocation Lists) signature keys, or
• Subordinate entity certificate requests, • Certificate status checking, and/or • Self-signed root certificates.
• Certificate 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. 188
• Signature keys for updating valid/authorized host lists in POIs Are not used for any purpose other than:
Modified
p. 188
• 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. 189
• Within a secure cryptographic device that meets applicable PCI requirements for such a device,
Modified
p. 190
• Revoke subordinate certificates, and
Modified
p. 190
• Revoke subordinate certificates, and
Modified
p. 190
• The CA will cease issuance of certificates.
Modified
p. 190
• The CA will cease issuance of certificates.
Modified
p. 190
• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.
Modified
p. 190
• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.
Modified
p. 191
• The CA will notify any superior CAs.
Modified
p. 191
• The CA will notify any subordinate CAs.
Modified
p. 191
• The CA will perform a damage assessment to determine the need to either: o Reissue and distribute certificates to affected parties, or o Notify the affected parties to apply for new certificates.
Modified
p. 191
• The CA notifies any superior CAs.
Modified
p. 191
• The CA notifies any subordinate CAs.
Modified
p. 191
• The CA performs a damage assessment to determine the need to either: o Reissues and distributes certificates to affected parties, or o Notifies the affected parties to apply for new certificates.
Modified
p. 191
• Root and subordinate CAs have a minimum RSA 2048 bits or equivalent;
Modified
p. 191
• 1024 for KDHs and POI devices 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. 192
• The network must only be used for certificate issuance and/or revocation.
Modified
p. 192
• Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
Modified
p. 192
• Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
Modified
p. 192
• CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment).
Modified
p. 192
• The network is only used for certificate issuance, revocation, or both certificate issuance and revocation.
Modified
p. 193
• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) 6F-5.4.b Observe CA operations and interview responsible personnel to verify:
Modified
p. 194
• Services that are not necessary or that allow non-secure access (e.g., rlogin, rshell, telnet, ftp, etc.) must be removed or disabled.
Modified
p. 194
• Unnecessary ports must also be disabled.
Modified
p. 194
• Unnecessary ports must also be disabled.
Modified
p. 194
• Documentation must exist to support the enablement of all active services and ports.
Modified
p. 194
• Documentation must exist to support the enablement of all active services and ports.
Modified
p. 194
• 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. 194
• 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. 194
• Unnecessary ports are disabled.
Modified
p. 194
• There is documentation to support all active services and ports.
Modified
p. 194
• Vendor-default IDs are changed, removed, or disabled unless necessary for a documented and specific business reason.
Modified
p. 194
• 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. 194
• 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. 194
• Vendor-default IDs are changed, removed or disabled unless necessary for a documented and specific business reason.
Modified
p. 195
• 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. 195
• Mechanisms exist to protect logs from alteration and destruction 6F-5.6.1 Audit logs must be archived for a minimum of two years.
Modified
p. 196
• Identity of the entity and/or user that caused the event,
Modified
p. 196
• Identity of the entity and/or user that caused the event,
Modified
p. 196
• Identity of the entity and/or user that caused the event,
Modified
p. 197
• Deny all services not explicitly permitted.
Modified
p. 197
• Deny all services not explicitly permitted.
Modified
p. 197
• Disable or remove all unnecessary services, protocols, and ports.
Modified
p. 197
• Disable or remove all unnecessary services, protocols, and ports.
Modified
p. 197
• Fail to a configuration that denies all services, and require a firewall administrator to re-enable services after a failure.
Modified
p. 197
• Fail to a configuration that denies all services, and require a firewall administrator to re-enable services after a failure.
Modified
p. 197
• Disable source routing on the firewall.
Modified
p. 197
• Disable source routing on the firewall.
Modified
p. 197
• Not accept traffic on its external interfaces that appears to be coming from internal network addresses.
Modified
p. 197
• Not accept traffic on its external interfaces that appears to be coming from internal network addresses.
Modified
p. 197
• Notify the firewall administrator in near real time of any item that may need immediate attention such as a break-in, little disk space available, or other related messages so that an immediate action can be taken.
Modified
p. 197
• Notify the firewall administrator in near real time of any item that may need immediate attention such as a break-in, little disk space available, or other related messages so that an immediate action can be taken.
Modified
p. 197
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled.
Modified
p. 197
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled.
Modified
p. 198
• Generic user IDs and accounts are disabled or removed.
Modified
p. 198
• Shared user IDs for system administration activities and other critical functions do not exist.
Modified
p. 198
• Shared and generic user IDs are not used.
Modified
p. 200
• CA operations must be dedicated to certificate issuance and management.
Modified
p. 200
• All physical and logical CA system components must be separated from key- distribution systems.
Modified
p. 201
Domain 6 A2 Requirements Testing Procedures 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.
Domain 6 A2 Requirements Testing Procedures 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. 201
• The CA shall operate in accordance with its CPS.
Modified
p. 202
• 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. 204
• Consists of the entrance to the facility.
• Consists of the entrance to the facility.
Modified
p. 204
• Secures the entrance beyond the foyer/reception area to the CA facility.
• Secures the entrance beyond the foyer/reception area to the CA facility.
Modified
p. 204
• Provides access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices.
• Provides access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices.
Modified
p. 204
• The entrance to the facility Level Two Barrier
• The entrance beyond the foyer/reception area to the CA facility Level Three Barrier
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices 6G-3.2.1.b Observe the physical facility to verify three tiers of physical security are implemented as follows:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices 6G-3.2.1.b Observe the physical facility to verify three tiers of physical security are implemented as follows:
Modified
p. 204
• The entrance to the facility Level Two Barrier
• The entrance beyond the foyer/reception area to the CA facility Level Three Barrier
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices 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 Level 1 Barrier 6G-3.2.2 The entrance to the CA facility/building must include the following controls:
Modified
p. 206
• Specific access authorizations, whether logical or physical 6G-3.2.6.a Examine documented procedures to verify they include the following:
Modified
p. 206
• Specific access authorizations, whether logical or physical 6G-3.2.6.b Interview responsible personnel to verify that the documented procedures are followed for:
Modified
p. 207
• Have successfully completed a background security check.
Modified
p. 207
• Have successfully completed a background security check.
Modified
p. 207
• Be assigned resources (staff, dedicated personnel) of the CA operator with defined business needs and duties.
Modified
p. 207
• Be assigned resources of the CA operator with defined business needs and duties.
Modified
p. 209
6G-3.2.9.2 Examine monitoring system configurations to verify; The system records to time-lapse VCRs or similar mechanisms.
6G-3.2.9.2 Examine monitoring system configurations to verify;
Modified
p. 209
• A minimum of five frames are recorded every three seconds.
Modified
p. 210
• Backups are securely stored in a separate location from the primary.
Modified
p. 210
• Ensure that segregation is maintained between users and administrators of the system.
Modified
p. 210
• Continuous (24/7) intrusion-detection monitoring of the Level 3 environment.
Modified
p. 210
• Motion detectors must be active when the environment is unoccupied.
Modified
p. 210
• Continuous (24/7) intrusion-detection monitoring of the Level 3 environment is in place.
Modified
p. 210
• Motion detectors are active when the environment is unoccupied.
Modified
p. 211
• The intrusion-detection system(s) is connected to the alarm system.
Modified
p. 211
• The intrusion-detection system(s) is automatically activated every time all authorized personnel have exited the secure area.
Modified
p. 211
• Having all authorized personnel who badged or otherwise authenticated into the area exit and one person remain behind even though they have badged out.
Modified
p. 211
• Having all but one authorized person who badged or otherwise authenticated into the system badge out and exit.
Modified
p. 211
• Actions that disable the intrusion-detection system 6G-3.4 All personnel (including CA personnel and visitors) must sign an access logbook when entering the Level 3 environment.
Modified
p. 211
• 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. 211
• For visitor access, the initials of the person escorting the visitor 6G-3.4.2 The logbook must be maintained within the Level 3 secure environment.
Modified
p. 215
• FIPS140-2 Level 3 or higher certified, or
Modified
p. 215
• 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.
Modified
p. 215
• 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. 216
• 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. 216
• Any applications, including application version number, resident within the device which were included in the PTS assessment 6A-1.4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS140-2 Level 3 (or higher) approval listing for each HSM:
Modified
p. 217
• Maintain current documentation that describes or illustrates the architecture of the KIF, including all distributed KIF functionality.
Modified
p. 217
• 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. 217
• 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.
Modified
p. 218
• 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. 218
• An approved random number generator that has been certified by an independent laboratory to comply with NIST SP 800-22
Modified
p. 218
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 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.
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. 218
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 6B-1.1.c Verify devices used for key generation are those as noted …
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. 219
• 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. 219
• 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. 220
• 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. 221
Examples of where such key residue may exist include (but are not limited to): Printing material, including ribbons and paper waste Memory storage of a key-loading device, after loading the key to a different device or system 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:
Examples of where such key residue may exist include (but are not limited to): • Printing material, including ribbons and paper waste
Modified
p. 221
• Any residue that may contain clear-text keys or components is destroyed immediately after generation.
Removed
p. 222
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 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:
Modified
p. 222
• 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. 222
• 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.
Modified
p. 222
• 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. 223
• 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 6B-3 Documented procedures must exist and must be demonstrably in use …
Modified
p. 224
• Key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf);
Modified
p. 224
• Digitally signed HSM-authentication public key(s) signed by a device manufacturer’s private key and subsequently loaded into the HSM for supporting certain key-establishment and distribution applications protocols (if applicable);
Modified
p. 225
• Examine documented procedures to verify that cryptographic-key components are transferred using different communications channels.
Modified
p. 225
• Examine records of key conveyances and interview responsible personnel to verify that cryptographic key components are transferred using different communications channels.
Modified
p. 225
• Examine documented procedures to verify that serial numbers are verified prior to the usage of the keying material.
Modified
p. 225
• Examine documented procedures to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
Modified
p. 225
• 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. 225
• Where key components are transmitted in clear-text using pre-numbered tamper-evident, authenticable mailers: o Components/shares must be conveyed using at least two separate communication channels, such as different courier services. Components/shares sufficient to form the key must not be conveyed using the same communication channel. o Ensure that details of the serial number of the package are conveyed transmitted separately from the package itself. o Ensure that documented procedures exist and are followed to require that the serial numbers be …
Modified
p. 225
• Where SCDs are used to convey components, the mechanisms or data (e.g., PIN) to obtain the key component from the SCD must be conveyed using a separate communication channel from the SCD, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
Modified
p. 225
• 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. 226
• Any person with access to the media conveying a component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key.
Modified
p. 226
• Where an SCD (HSM or KLD) is conveyed with pre- loaded secret and/or private keys, the SCD must require dual-control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
Modified
p. 226
• Examine documented procedures to verify that the SCD requires dual-control mechanisms to become operational.
Modified
p. 226
• 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. 226
• 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.
Modified
p. 227
• Any person with access to the media conveying a key component or key share must not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Modified
p. 227
• An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Modified
p. 228
• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A.
Modified
p. 228
• Using a MAC (message authentication code) created using the algorithm defined in ISO 16609
Modified
p. 228
• Examine documented procedures for conveying public keys to verify that methods are defined to convey public keys in a manner that protects their integrity and authenticity such as: o Use of public-key certificates created by a trusted CA that meets the requirements of Annex A o A hash of the public key sent by a separate channel (e.g., mail) o Using a MAC (message authentication code) created using the algorithm defined in ISO 16609 o Be within an SCD
Modified
p. 228
• Observe the process for conveying public keys and interview responsible personnel to verify that the implemented method ensures public keys are conveyed in a manner that protects their integrity and authenticity.
Modified
p. 229
• Locked in a security container (including tamper-evident, authenticable packaging) in such a way that unauthorized access to it would be detected, or
Modified
p. 229
• 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
Modified
p. 229
• 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
Modified
p. 230
• 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. 230
• Any keys encrypted under this (combined) key 6C-2.3 Only the authorized key custodian (and designated backup(s)) shall have physical access to a key component prior to transmittal or upon receipt of a component.
Modified
p. 230
• Any keys encrypted under this (combined) key 6C-2.2.d Interview responsible personnel and observe processes to verify that, if a package shows signs of tampering, processes are implemented that result in the destruction and replacement of both:
Modified
p. 231
• Place key components into pre-numbered tamper- evident, authenticable packaging for transmittal.
Modified
p. 231
• Check tamper-evident packaging upon receipt for signs of tamper prior to opening the tamper-evident, authenticable packaging containing key components.
Removed
p. 232
Verify that: o 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. o A double- or triple-length DEA key must not be encrypted with a DEA key of lesser strength. o TDEA keys are not used to protect AES keys. o TDEA keys shall not be used to encrypt keys greater in strength than 112 bits. o RSA keys encrypting keys greater in strength than 80 bits have bit strength at least 112 bits.
Modified
p. 232
• TDEA keys shall not be used to protect AES keys.
Modified
p. 232
• TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
Modified
p. 232
• Interview appropriate personnel and examine documented procedures for the creation of these keys.
Modified
p. 232
• 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.
Modified
p. 232
• TDEA keys used for encrypting keys must be at least triple-length keys (have bit strength of 112 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment.
Modified
p. 232
• A triple-length TDEA key must not be encrypted with a TDEA key of a lesser strength.
Modified
p. 232
• RSA keys encrypting keys greater in strength than 80 bits shall have bit strength at least 112 bits.
Modified
p. 234
• Derived Unique Key Per Transaction (DUKPT) Base Derivation Keys (BDKs) used in the DUKPT key-management method; • Key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is injecting keys on their behalf); • Terminal master keys (TMKs) used in the master key/session key key-management method; • PIN-encryption keys used …
Modified
p. 235
• 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.
Modified
p. 236
Domain 6 Annex B Requirements Testing Procedures 6D-1.5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least double-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits.
Domain 6 Annex B Requirements Testing Procedures 6D-1.5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least triple-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits.
Modified
p. 236
• The existing TMK to encrypt the replacement TMK for download.
Modified
p. 237
• Use public and private key lengths that are in accordance with Annex C for the algorithm in question.
Modified
p. 237
• Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Modified
p. 237
• Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Modified
p. 237
• Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable.
Modified
p. 237
• 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.
Modified
p. 237
• Use of public and private key lengths that are in accordance with Annex C for the algorithm in question .
Modified
p. 238
• Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to key injection such that the badge-access system enforces the presence of at least two authorized individuals at all times in the room so no one person can singly access the key- loading equipment. Access is restricted to only appropriate personnel involved in the key-loading process
Modified
p. 239
• XOR’ing of key components is performed in software.
Modified
p. 239
• Clear-text keys and components can reside in software during the key-loading process.
Modified
p. 239
• Some systems require only a single password.
Modified
p. 239
• Some systems store the keys (e.g., BDKs, TMKs) on removable media or smart cards. These keys are in the clear with some systems.
Modified
p. 239
• PCs, by default, are not managed under dual control. Extra steps (e.g., logical user IDs, physical access controls, etc.) must be implemented to prevent single control of a PC.
Modified
p. 239
• Data can be recorded in the PC’s non-volatile storage.
Modified
p. 239
• Software Trojan horses or keyboard sniffers can be installed on PCs.
Modified
p. 240
• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of clear-text key components.
Modified
p. 240
• There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys.
Modified
p. 240
• 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. 240
• The SCD must be inspected prior to use to ensure that it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying materials.
Modified
p. 240
• SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.
Modified
p. 240
• Ensure that any cameras that are present are positioned to ensure they cannot monitor the entering of clear-text key components.
Modified
p. 240
• Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: o SCDs must be inspected to detect evidence of monitoring and to ensure dual- control procedures are not circumvented during key loading. o An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by …
Modified
p. 241
• 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
Modified
p. 241
• 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
Modified
p. 241
• 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
Modified
p. 242
• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process.
Modified
p. 242
• Requirement that media/devices are in the physical possession of only the designated component holder(s).
Modified
p. 243
• Standalone (i.e., without modems, not connected to a LAN or WAN, not capable of wireless connections, etc.);
Modified
p. 244
• All hardware used in key loading (including the PC) is managed under dual control.
Modified
p. 244
• Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process.
Modified
p. 244
• Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals.
Modified
p. 244
• 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 …
Modified
p. 244
• Retained for a minimum of three years.
Modified
p. 244
• Retained for a minimum of three years.
Modified
p. 244
• Regularly reviewed by an authorized person who does not have access to the room or to the PC.
Modified
p. 244
• Regularly reviewed by an authorized person who does not have access to the room or to the PC.
Modified
p. 244
• The reviews are documented.
Modified
p. 244
• The reviews are documented.
Modified
p. 244
• Logs include a minimum of: o Access to the room from a badge access system, o Access to the room from a manual sign-in sheet, o User sign-on logs on the PC at the operating system level, o User sign-on logs on the PC at the application level, o Logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key-injection, o Video surveillance logs with a minimum …
Modified
p. 247
• Any hardware used in the key-loading function must be controlled and maintained in a secure environment under dual control.
Modified
p. 247
• 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. 247
• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control.
Modified
p. 247
• 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. 249
• Have a MAC (message authentication code) created using the algorithm defined in ISO 16609.
Modified
p. 250
• All devices loaded with keys must be tracked at each key-loading session by serial number.
Modified
p. 250
• 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.
Modified
p. 250
• Controls to prevent the operation of devices without legitimate keys.
Modified
p. 250
• Controls are implemented that prevent the operation of devices without legitimate keys.
Modified
p. 251
• For a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices).
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices).
Modified
p. 251
• To create digital signatures or to perform decryption operations.
Modified
p. 251
• Private keys are never used to encrypt other keys.
Modified
p. 251
• To perform encryption operations or to verify digital signatures.
Modified
p. 251
• 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. 251
• Where test keys are used, key-injection facilities must use a separate test system for the injection of test keys.
Modified
p. 251
• Test keys must not be injected using the production platform, and test keys must not be injected into production equipment.
Modified
p. 251
• Production keys must not be injected using a test platform, and production keys must not be injected into equipment that is to be used for testing purposes.
Modified
p. 251
• Keys used for signing of test certificates must be test keys.
Modified
p. 251
• Keys used for signing of production certificates must be production keys.
Modified
p. 251
• Private keys shall never be used to encrypt other keys.
Modified
p. 251
• 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).
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for POI devices).
Modified
p. 252
• Key used for production keys must never be present or used in a test system, and
Modified
p. 252
• 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. 253
• Known only to HSMs at the minimum number of facilities consistent with effective system operations.
Modified
p. 253
• Examine documented procedures for generating all types of keys and verify the procedures ensure that unique keys, or sets of keys, are used for each acquiring organization and are totally independent and not variants of one another.
Modified
p. 253
• Interview personnel and observe key-generation processes to verify that unique keys or sets of keys are generated for each acquiring organization.
Modified
p. 254
• Different BDKs for each financial institution • Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model • 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.
Modified
p. 254
• Unique data is used for the derivation process such that all transaction-originating POIs receive unique secret keys.
Modified
p. 254
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.
Modified
p. 254
• The POI must have a completely different and unique key, or set of keys, for each acquiring organization.
Modified
p. 254
• These different keys, or sets of keys, must be totally independent and not variants of one another.
Modified
p. 254
• The POI has a completely different and unique key, or set of keys, for each acquiring organization.
Modified
p. 254
• These different keys, or sets of keys, are totally independent and not variants of one another.
Modified
p. 255
• Keys must be uniquely identifiable in all hosts and POI Devices (e.g., EPPs/PEDs). Keys must be identifiable via cryptographically verifiable means (e.g., through the use of digital signatures or key check values).
Modified
p. 255
• Key pairs must be unique per POI device (e.g., EPPs and PEDs).
Modified
p. 255
• The mechanisms utilized for mutual device authentication for both the host and the POIPED.
Modified
p. 255
• Cryptographic mechanisms exist to uniquely identify the keys.
Modified
p. 255
• Key pairs used by POI devices are unique per device.
Modified
p. 256
• 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. 258
• Key components for different custodians are stored in separate secure containers.
Modified
p. 258
• Each secure container is accessible only by the custodian and/or designated backup(s).
Modified
p. 259
• Processing with that key is halted, and the key is replaced with a new unique key.
Modified
p. 259
• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key-replacement process.
Modified
p. 259
• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key.
Modified
p. 260
• Specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Modified
p. 260
• A damage assessment including, where necessary, the engagement of outside consultants.
Modified
p. 260
• Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Modified
p. 260
• 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. 260
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 6F-2.2 If attempts to load a secret key or key component into a KLD or POI fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original …
Modified
p. 262
• Variants used as KEKs must only be calculated from other key-encrypting keys.
Modified
p. 262
• Variants of working keys must only be calculated from other working keys.
Removed
p. 264
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 6F-5.1.3 Examine all key-custodian forms to verify that they include the following:
Modified
p. 264
• A primary and a backup key custodian are designated for each component.
Modified
p. 264
• The fewest number of key custodians is assigned as necessary to enable effective key management.
Modified
p. 264
• Assigned key custodians are employees or contracted personnel 6F-5.1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.
Modified
p. 265
• Key custodians that form the necessary threshold to create a key do not directly report to the same individual.
Modified
p. 265
• 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. 265
• Ensure key custodians do not report to each other.
Modified
p. 265
• Receive explicit training to instruct them from sharing key components with their direct manager.
Modified
p. 265
• Sign key-custodian agreement that includes an attestation to the requirement.
Modified
p. 265
• Ensure training includes whistleblower procedures to report any violations.
Modified
p. 266
• Loaded to an SCD 6F-6.1.b Review log files and audit log settings to verify that logs include the following:
Modified
p. 266
• 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. 266
• Tamper-evident package number (if applicable) 6F-7 Backups of secret and private keys must exist only for the purpose of reinstating keys that are accidentally destroyed or are otherwise inaccessible. The backups must exist only in one of the allowed storage forms for that key.
Modified
p. 266
• Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys.
Modified
p. 267
• Creation (including cloning) must require a minimum of two authorized individuals to enable the process.
Modified
p. 267
• The creation of any backup copies requires at least two authorized individuals to enable the process.
Modified
p. 267
• Management of personnel changes, including revocation of access control and other privileges when personnel move 6F-8.1.a Examine documented procedures for key-administration operations to verify they include:
Modified
p. 267
• Management of personnel changes, including revocation of access control and other privileges when personnel move 6F-8.1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
Modified
p. 268
• POIs have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 268
• POIs have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 269
• The authorizations are reviewed annually.
Modified
p. 269
• All personnel with access to POIs and other SCDs are documented in a formal list.
Modified
p. 269
• All personnel with access to POIs and other SCDs are authorized by management.
Modified
p. 270
• Transportation using a trusted courier service (e.g., via bonded carrier). The devices are then securely stored until key-insertion and deployment occurs.
Modified
p. 270
• 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.
Modified
p. 270
• A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. Before key-insertion, the SCD used for key-insertion verifies the presence of the correct “transport-protection token” before overwriting this value with the initial key, and the device is further protected until deployment.
Modified
p. 270
• Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been subject to any unauthorized access or modifications. (Note: Unauthorized access includes that by customs officials.) o Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised. (Note: This …
Modified
p. 273
• Each production run must be associated with a predefined inventory of identified POI devices to be injected or initialized with keys.
Modified
p. 273
• Unauthorized personnel must not be able to modify this inventory without detection.
Modified
p. 273
• All POI devices to be initialized with keys on a production run must be identified and accounted for against the inventory.
Modified
p. 273
• Unauthorized POI devices submitted for injection or initialized must be rejected by the injection platform and investigated.
Modified
p. 273
• Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices must be identified and accounted for against the inventory.
Modified
p. 273
• Each production run is associated with a predefined inventory of identified POI devices to be injected or initialized with keys.
Modified
p. 273
• Unauthorized personnel are not able to modify this inventory without detection.
Modified
p. 273
• All POI devices to be initialized with keys on a production run are identified and accounted for against the inventory.
Modified
p. 273
• Unauthorized POI devices submitted for injection or initialized are rejected by the injection platform and investigated.
Modified
p. 273
• Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices are identified and accounted for against the inventory.
Modified
p. 274
• Procedures cover requirements at 6G-3.1.1 through 6G-3.1.6 below.
Modified
p. 274
• Procedures require that all keys and key material stored within the device be securely destroyed.
Modified
p. 274
• Procedures cover all devices removed from service or for repair.
Modified
p. 276
• For all access to key-loading devices (KLDs 6G-4.1.3 Examine dual-control mechanisms and observe authorized personnel performing the defined activities to confirm that dual control is implemented for the following:
Modified
p. 277
• Under the continuous supervision of at least two authorized people who ensure that any unauthorized use of the device would be detected.
Modified
p. 277
• Locked in a secure cabinet and/or sealed in tamper-evident packaging at all times, or
Modified
p. 277
• Locked in a secure cabinet and/or sealed in tamper-evident packaging at all times, or
Modified
p. 278
• POI devices must validate authentication credentials of KDHs prior to any key transport, exchange, or establishment with that device.
Modified
p. 278
• KIFs must validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
Modified
p. 278
• 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.
Modified
p. 278
• KIFs validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
Modified
p. 278
• POI devices validate authentication credentials of KLDs prior to any key transport, exchange, or establishment with that device.
Modified
p. 278
• When a KLD is used as an intermediate device to establish keys between POIs and a KIF HSM, it is not possible to insert an unauthorized SCD into the flow without detection 6G-4.9.7 Mechanisms must exist to prevent a non- authorized host from injecting keys into POIs or an unauthorized POI from establishing a key with a legitimate KIF component.
Modified
p. 279
• Dual-access requirements for entry into the secure area, and
Modified
p. 279
• Anti-pass-back 6G-4.10.6 The badge-control system must support generation of an alarm when one person remains alone in the secure area for more than 30 seconds.
Modified
p. 280
• SCDs, both pre and post key injection, • Any safes that are present, and • The equipment used for key injection.
Modified
p. 280
• SCDs, both pre and post key injection, • Any safes that are present, and • The equipment used for key injection.
Modified
p. 282
• 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.
Modified
p. 282
• Details of any known or suspected compromised keys, per 6F-2.1 6I-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
Modified
p. 283
Algorithm DEA RSA Curve DSA AES Minimum key size in number of bits 4 168 2048 224 2048/224 128 The strength of a cryptographic key is a measure of the expected work effort an attacker would have to spend to discover the key. Cryptographic strength is measured in "bits of security" (see, e.g., NIST SP 800-57 Part 1). While the concept of bits of security originated with symmetric encryption algorithms, it extends to asymmetric algorithms as well. In neither case …
Algorithm TDEA RSA Curve DSA AES Minimum key size in number of bits 4 168 2048 224 2048/224 128 The strength of a cryptographic key is a measure of the expected work effort an attacker would have to spend to discover the key. Cryptographic strength is measured in "bits of security" (see, e.g., NIST SP 800-57 Part 1). While the concept of bits of security originated with symmetric encryption algorithms, it extends to asymmetric algorithms as well. In neither case …
Removed
p. 285
Scenario 1: Solution provider uses a third-party POI application, and manages all other solution functions.