Document Comparison
PCI_PIN_Security_Requirements_Testing_v3_Aug2018.pdf
→
PCI_PIN_Security_Requirements_Testing_v3_1.pdf
53% similar
237 → 230
Pages
90390 → 92796
Words
483
Content Changes
From Revision History
- October 2011 1.0 Initial release of PCI PIN Security Requirements.
Content Changes
483 content changes. 107 administrative changes (dates, page numbers) hidden.
Added
p. 2
March 2021 3.1 Minor revisions including errata. ISO PIN Block Format 4 support dates are suspended. Updates to 6-3, 10-1, 15-1, 26-1, 32-1.1, Annex A Introduction, 21-4, Annex B 1-2, 13-9.4.9, 32-9, Annex C, Glossary Additions, Appendix A.
Added
p. 8
The effective dates for supporting ISO Format 4 PIN Blocks that were previously communicated in v3.0 of the PCI PIN Security Requirements and Testing Procedures have been suspended at this time.
Due to the nature of TDEA-to-AES migration and its effect across the payment ecosystem, PCI SSC is reevaluating these dates. Revised effective dates will be communicated at a later time.
Due to the nature of TDEA-to-AES migration and its effect across the payment ecosystem, PCI SSC is reevaluating these dates. Revised effective dates will be communicated at a later time.
Added
p. 14
1-1.a Obtain the POI device information. Check for the completeness of the information.
Note: PCI approved HSMs may have their approvals restricted whereby the approval is valid only when the HSM is deployed in controlled environments or more robust (e.g., secure ) environments as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy. This information is noted in the Additional Information column of approved PTS devices.
b) All cardholder PINs processed offline using IC card technology must be protected in accordance with the requirements in Book 2 of the EMV IC Card Specifications for Payment Systems and ISO 9654.
Effective 1 January 2023: Fixed key for TDEA PIN encryption in POI devices is disallowed.
Effective 1 January 2023: Fixed key for TDEA PIN encryption in host-to-host connections is disallowed.
The effective dates for supporting ISO Format 4 PIN Blocks that were previously communicated in v3.0 of the PCI PIN Security Requirements and …
Note: PCI approved HSMs may have their approvals restricted whereby the approval is valid only when the HSM is deployed in controlled environments or more robust (e.g., secure ) environments as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy. This information is noted in the Additional Information column of approved PTS devices.
b) All cardholder PINs processed offline using IC card technology must be protected in accordance with the requirements in Book 2 of the EMV IC Card Specifications for Payment Systems and ISO 9654.
Effective 1 January 2023: Fixed key for TDEA PIN encryption in POI devices is disallowed.
Effective 1 January 2023: Fixed key for TDEA PIN encryption in host-to-host connections is disallowed.
The effective dates for supporting ISO Format 4 PIN Blocks that were previously communicated in v3.0 of the PCI PIN Security Requirements and …
Added
p. 27
6-3.b Observe blind mailers, tamper-evident and authenticable packaging, or other sealed containers used for key components to verify that components cannot be read from within and that tampering can be detected.
• Printers used for this purpose are not used for other purposes and are used only under dual control.
6-3.1 The room must have walls made of solid materials. The walls do not have to extend from true floor to true ceiling but do need to extend from floor to ceiling.
6-3.1 Inspect the secure room designated for printing clear-text key components to verify that the walls are made of solid materials and extend from floor to ceiling.
6-3.2 Any windows into the secure room must be:
• Printers used for this purpose are not used for other purposes and are used only under dual control.
6-3.1 The room must have walls made of solid materials. The walls do not have to extend from true floor to true ceiling but do need to extend from floor to ceiling.
6-3.1 Inspect the secure room designated for printing clear-text key components to verify that the walls are made of solid materials and extend from floor to ceiling.
6-3.2 Any windows into the secure room must be:
Added
p. 27
6-3.2.a Observe all windows in the secure room to verify they are:
6-3.2.b Examine configuration of window sensors to verify that the alarm mechanism is active.
6-3.3 An electronic access control system (for example, badge and/or biometrics) must be in place that:
• Enforces dual-access requirements for entry into the secure room, and anti-pass-back requirements.
6-3.3.a Observe authorized personnel entering the secure room to verify that a badge- control system is in place that enforces the following requirements:
• Dual access for entry to the secure room
• Supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds.
6-3.3.b Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds.
6-3.4 CCTV cameras must record all activity, including recording events during dark periods through the use of infrared …
6-3.2.b Examine configuration of window sensors to verify that the alarm mechanism is active.
6-3.3 An electronic access control system (for example, badge and/or biometrics) must be in place that:
• Enforces dual-access requirements for entry into the secure room, and anti-pass-back requirements.
6-3.3.a Observe authorized personnel entering the secure room to verify that a badge- control system is in place that enforces the following requirements:
• Dual access for entry to the secure room
• Supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds.
6-3.3.b Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds.
6-3.4 CCTV cameras must record all activity, including recording events during dark periods through the use of infrared …
Added
p. 28
6-3.7 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor:
PIN Security Requirements Testing Procedures 6-3.8 CCTV cameras must be positioned so they do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.
6-3.8 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.
6-3.9 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days. If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
6-3.9.a If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the …
PIN Security Requirements Testing Procedures 6-3.8 CCTV cameras must be positioned so they do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.
6-3.8 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.
6-3.9 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days. If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
6-3.9.a If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the …
Added
p. 32
b) Transmitting the key in ciphertext form.
Added
p. 35
E.g., in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such that any three key components or shares (i.e., m = 3) can be used to derive the key, no single individual can have access to more than two components/shares.
Added
p. 44
a) Unencrypted secret or private keys must be entered using the principles of dual control and split knowledge.
b) Key-establishment techniques using public-key cryptography must be implemented securely.
Note: For devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. Each half must be a minimum of five characters.
b) Key-establishment techniques using public-key cryptography must be implemented securely.
Note: For devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. Each half must be a minimum of five characters.
Added
p. 51
PIN Security Requirements Testing Procedures 13-5 (continued) The media upon which a component resides must be physically safeguarded at all times when removed from secure storage.
Added
p. 64
• for example, desk drawers
•are not sufficient to meet this requirement.
•are not sufficient to meet this requirement.
Added
p. 69
a) Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use; and
Added
p. 71
PIN Security Requirements Testing Procedures The components collectively held by an individual and his or her direct reports shall not constitute a quorum (or shall not provide any information about the value of the key that is not derivable from a single component).
• Loaded to an SCD 26-1.b Examine logs and verify they are:
• Archived for a minimum of two years subsequent to key destruction
• Loaded to an SCD 26-1.b Examine logs and verify they are:
• Archived for a minimum of two years subsequent to key destruction
Added
p. 75
Note: This applies to SCDS used for key injection or code signing, including display prompts.
Added
p. 83
a) Dual access controls required to enable the key-encryption function
b) Physical protection of the equipment (e.g., locked access to it) under dual control
c) Restriction of logical access to the equipment 32-1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, procedures must be documented and implemented to protect against unauthorized access and use.
PIN Security Requirements Testing Procedures 32-1.3 Dual control must be implemented for the following:
• ANSI TR 34 presents a methodology that is compliant with these requirements. TR 34 describes a method for transporting a symmetric key from one SCD to another over an uncontrolled channel. A typical example usage of TR 34 would be to load individual initial symmetric transport keys from a Key Distribution Host to a population of PEDs. TR 34 makes use of asymmetric cryptography to protect this key transport, which means that both the …
b) Physical protection of the equipment (e.g., locked access to it) under dual control
c) Restriction of logical access to the equipment 32-1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, procedures must be documented and implemented to protect against unauthorized access and use.
PIN Security Requirements Testing Procedures 32-1.3 Dual control must be implemented for the following:
• ANSI TR 34 presents a methodology that is compliant with these requirements. TR 34 describes a method for transporting a symmetric key from one SCD to another over an uncontrolled channel. A typical example usage of TR 34 would be to load individual initial symmetric transport keys from a Key Distribution Host to a population of PEDs. TR 34 makes use of asymmetric cryptography to protect this key transport, which means that both the …
Added
p. 96
• Sub-CAs used to produce certificates for POI firmware and POI application authentication must not be used for any other purpose.
Added
p. 100
• The CA will perform a damage assessment to determine the need to either:
• SCRP devices must have a minimum RSA 2048 bits or equivalent
• 1024 for POI devices
a) Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use, and
• SCRP devices must have a minimum RSA 2048 bits or equivalent
• 1024 for POI devices
a) Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use, and
Added
p. 112
a) Dual access controls are required to enable the key-encryption function.
b) Physical protection of the equipment (e.g., locked access to it) under dual control.
c) Restriction of logical access to the equipment.
b) Physical protection of the equipment (e.g., locked access to it) under dual control.
c) Restriction of logical access to the equipment.
Added
p. 122
• The distribution of symmetric keys using asymmetric techniques from a key-distribution host (KDH) to many key-receiving devices (KRDs⎯i.e., POI devices); or
• Could also be used to exchange keys between peers, where one is administratively designated as the KDH and one as the KRD (e.g., the transaction processing host).
If the key loading is not performed remotely and authentication is provided by another method
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates, Annex A does not apply. “Remotely” means whenever the key-loading device and the POI device are neither co-located nor connected via a direct mechanism, such as a cable.
• PCI approved. Note: PCI approved HSMs may have their approvals restricted whereby the approval is valid only when the HSM is deployed in controlled environments or more robust (e.g., secure) environments as defined in ISO 13491-2 and in the device’s PCI HSM Security …
• Could also be used to exchange keys between peers, where one is administratively designated as the KDH and one as the KRD (e.g., the transaction processing host).
If the key loading is not performed remotely and authentication is provided by another method
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates, Annex A does not apply. “Remotely” means whenever the key-loading device and the POI device are neither co-located nor connected via a direct mechanism, such as a cable.
• PCI approved. Note: PCI approved HSMs may have their approvals restricted whereby the approval is valid only when the HSM is deployed in controlled environments or more robust (e.g., secure) environments as defined in ISO 13491-2 and in the device’s PCI HSM Security …
Added
p. 126
• An approved key-generation function of a FIPS 140-2 or FIPS 140-3 Level 3 (or higher) HSM
• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 5-1.b Examine certification letters or technical documentation to verify that all devices used to generate cryptographic keys or key components meet one of the following
• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 5-1.b Examine certification letters or technical documentation to verify that all devices used to generate cryptographic keys or key components meet one of the following
Added
p. 130
6-3.1 The room must have walls made of solid materials. The walls do not have to extend from true floor to true ceiling but do need to extend from floor to ceiling.
6-3.1 Inspect the secure room designated for printing clear-text key components to verify that the walls are made of solid materials and extend from floor to ceiling.
6-3.2 Any windows into the secure room must be:
6-3.2.a Observe all windows in the secure room to verify they are:
6-3.2.b Examine configuration of window sensors to verify that the alarm mechanism is active.
6-3.3 An electronic access control system (for example, badge and/or biometrics) must be in place that:
• Enforces dual-access requirements for entry into the secure room, and anti-pass-back requirements.
6-3.3.a Observe authorized personnel entering the secure room to verify that a badge- control system is in place that enforces the following requirements:
• Dual access for entry to the secure room
6-3.c Observe processes for …
6-3.1 Inspect the secure room designated for printing clear-text key components to verify that the walls are made of solid materials and extend from floor to ceiling.
6-3.2 Any windows into the secure room must be:
6-3.2.a Observe all windows in the secure room to verify they are:
6-3.2.b Examine configuration of window sensors to verify that the alarm mechanism is active.
6-3.3 An electronic access control system (for example, badge and/or biometrics) must be in place that:
• Enforces dual-access requirements for entry into the secure room, and anti-pass-back requirements.
6-3.3.a Observe authorized personnel entering the secure room to verify that a badge- control system is in place that enforces the following requirements:
• Dual access for entry to the secure room
6-3.c Observe processes for …
Added
p. 135
b) Transmitting the key in ciphertext form.
Added
p. 152
PIN Security Requirements Testing Procedures device into two halves, each half controlled by a separate authorized custodian. Each half must be a minimum of five characters.
Note: Passwords/authentication codes to the same object may be assigned to a custodian group team⎯e.g., custodian team for component A.
Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings.
Note: Concatenation of key components together to form the key is unacceptable; e.g., concatenating two 8-hexadecimal character halves to form a 16-hexadecimal secret key.
Note: Passwords/authentication codes to the same object may be assigned to a custodian group team⎯e.g., custodian team for component A.
Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings.
Note: Concatenation of key components together to form the key is unacceptable; e.g., concatenating two 8-hexadecimal character halves to form a 16-hexadecimal secret key.
Added
p. 157
• 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 24.
• All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement 24.
Added
p. 176
• for example, desk drawers
•are not sufficient to meet this requirement.
•are not sufficient to meet this requirement.
Added
p. 182
a) Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use; and
• Loaded to an SCD 26-1.b Examine logs and verify they are:
• Archived for a minimum of two years subsequent to key destruction
• Loaded to an SCD 26-1.b Examine logs and verify they are:
• Archived for a minimum of two years subsequent to key destruction
Added
p. 187
Note: This applies to SCDS used for key injection or code signing, including display prompts.
• Upon tamper of the device it becomes infeasible to load any keying material.
• Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and
• HSMs used for acquiring functions shall not be configured to output clear- text PINs or support PIN-change functionality.
• Upon tamper of the device it becomes infeasible to load any keying material.
• Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and
• HSMs used for acquiring functions shall not be configured to output clear- text PINs or support PIN-change functionality.
Added
p. 195
a) Dual access controls required to enable the key-encryption function
b) Physical protection of the equipment (e.g., locked access to it) under dual control
c) Restriction of logical access to the equipment Key-injection facilities must ensure protection against unauthorized use for SCDs (e.g., HSMs) used in the key-injection platform that are capable of encrypting a key and producing cryptograms of that key.
b) Physical protection of the equipment (e.g., locked access to it) under dual control
c) Restriction of logical access to the equipment Key-injection facilities must ensure protection against unauthorized use for SCDs (e.g., HSMs) used in the key-injection platform that are capable of encrypting a key and producing cryptograms of that key.
Added
p. 203
• Hash functions: only algorithms from the SHA2 and SHA3 family are allowed on POI v3 and higher devices, with output size >2551
• Symmetric-Key Algorithms used for encryption and decryption: AES must be used, with key size >= 128 bits or TDEA with keys size >= 112 bits
• Message Authentication Codes (MACs): CMAC or GMAC can be used with AES, as well as HMAC with an approved hash function and a key size >=128
• Signature algorithms: DSA, RSA (with PKCS1-v1.5 or PSS) and ECDSA with key sizes specified below.
• Approved key establishment schemes are described in NIST SP800-56A (ECC/FCC2-based key agreement), NIST SP800-56B (IFC- based key agreement) and NIST SP800-38F (AES-based key encryption/wrapping).
• Symmetric-Key Algorithms used for encryption and decryption: AES must be used, with key size >= 128 bits or TDEA with keys size >= 112 bits
• Message Authentication Codes (MACs): CMAC or GMAC can be used with AES, as well as HMAC with an approved hash function and a key size >=128
• Signature algorithms: DSA, RSA (with PKCS1-v1.5 or PSS) and ECDSA with key sizes specified below.
• Approved key establishment schemes are described in NIST SP800-56A (ECC/FCC2-based key agreement), NIST SP800-56B (IFC- based key agreement) and NIST SP800-38F (AES-based key encryption/wrapping).
Added
p. 203
This includes certificates used by the device that are non-device-specific that are part of a vendor PKI, up to and including a vendor root certificate. The only exception to this is that the initial code on ROM that initiates upon the device start may authenticate itself using SHA-1, but all subsequent code must be authenticated using SHA-2.
SHA-2 or higher is recommended for other usages, but SHA-1 may be used in conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key derivation functions (i.e., KDFs) and random number generation. Where applicable, appropriate key length minimums as delineated in the Derived Test Requirements are also required.
SHA-2 or higher is recommended for other usages, but SHA-1 may be used in conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key derivation functions (i.e., KDFs) and random number generation. Where applicable, appropriate key length minimums as delineated in the Derived Test Requirements are also required.
Added
p. 205
TLS implementations must prevent the use of cipher suites that do not enforce the use of cryptographic ciphers, hash functions and key lengths as defined in the Technical FAQs.
• Entities must authenticate the FFC or ECC public keys using DSA, ECDSA, a certificate, or a MAC (see ISO 16609
IFC, FFC and ECC are vulnerable to attacks from large-scale quantum computers. In 2017, NIST initiated a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms, planned to end with a selection of new algorithms by 2023-2025.
• Entities must authenticate the FFC or ECC public keys using DSA, ECDSA, a certificate, or a MAC (see ISO 16609
IFC, FFC and ECC are vulnerable to attacks from large-scale quantum computers. In 2017, NIST initiated a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms, planned to end with a selection of new algorithms by 2023-2025.
Added
p. 214
Key Block Block containing a protected key, its usage constraints and other data, that is wrapped (encrypted) using a key wrapping mechanism Key Block Authentication Key The key that is derived from the Key Block Protection Key and that is used solely for calculating the MAC over the key block described in this document.
Key Block Encryption Key The key that is derived from the Key Block Protection Key and that is used solely for enciphering the key block described in this document.
Key Block Protection Key The derivation key from which the Key Block Encryption Key and the Key Block Authentication key are derived; this key is used for no other purpose. This is also known as a Key Wrapping Key.
Key-receiving device (KRD) The entity (e.g. POI device) that will receive the symmetric key.
Key Block Encryption Key The key that is derived from the Key Block Protection Key and that is used solely for enciphering the key block described in this document.
Key Block Protection Key The derivation key from which the Key Block Encryption Key and the Key Block Authentication key are derived; this key is used for no other purpose. This is also known as a Key Wrapping Key.
Key-receiving device (KRD) The entity (e.g. POI device) that will receive the symmetric key.
Added
p. 219
• Sign and verify for signature systems, and
• Encipher and decipher for encipherment systems.
Secret key A cryptographic key used with a secret key cryptographic algorithm that is uniquely associated with one or more entities and should not be made public. A secret key (symmetrical) cryptographic algorithm uses a single secret key for both encryption and decryption. The use of the term “secret” in this context does not imply a classification level; rather the term implies the need to protect the key from disclosure or substitution.
Service Provider An entity (that is not a payment brand), acting on behalf of an Acquiring organization for any of the following activities:
• Acquiring, processing, storage, or transmission of PIN-based payment transactions
• Management of cryptographic keys associated with PIN-based payments - (e.g., Certificate Authority, Key Injection Facility)
Note: If an entity provides a service that involves only the provision of public network access
•such as a telecommunications company …
• Encipher and decipher for encipherment systems.
Secret key A cryptographic key used with a secret key cryptographic algorithm that is uniquely associated with one or more entities and should not be made public. A secret key (symmetrical) cryptographic algorithm uses a single secret key for both encryption and decryption. The use of the term “secret” in this context does not imply a classification level; rather the term implies the need to protect the key from disclosure or substitution.
Service Provider An entity (that is not a payment brand), acting on behalf of an Acquiring organization for any of the following activities:
• Acquiring, processing, storage, or transmission of PIN-based payment transactions
• Management of cryptographic keys associated with PIN-based payments - (e.g., Certificate Authority, Key Injection Facility)
Note: If an entity provides a service that involves only the provision of public network access
•such as a telecommunications company …
Modified
p. 1
Payment Card Industry (PCI) PIN Security Requirements and Testing Procedures Version 3.0
Payment Card Industry (PCI) PIN Security Requirements and Testing Procedures Version 3.1
Modified
p. 2
October 2011 1.0 Initial release of PCI PIN Security Requirements
October 2011 1.0 Initial release of PCI PIN Security Requirements.
Modified
p. 2
December 2014 2.0 Initial release of requirements with test procedures
December 2014 2.0 Initial release of requirements with test procedures.
Modified
p. 5 → 6
Normative Annex A
• Symmetric Key Distribution using Asymmetric Keys For specific requirements pertaining toacquiring 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 Normative Annex A. Acquiring entities involved in remote key distribution are subject to both the requirements stipulated in the Technical Reference section of this document and the additional criteria stipulated in Annex A. Other entities
•e.g., point-of-interaction …
• Symmetric Key Distribution using Asymmetric Keys For specific requirements pertaining to
•e.g., point-of-interaction …
Normative Annex A
• Symmetric Key Distribution using Asymmetric Keys 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 Normative Annex A. Acquiring entities involved in remote key distribution are subject to both the requirements stipulated in the Transaction Processing Operations section of this document and the additional criteria stipulated in Annex A. Other entities
•e.g., point-of-interaction …
• Symmetric Key Distribution using Asymmetric Keys 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 Normative Annex A. Acquiring entities involved in remote key distribution are subject to both the requirements stipulated in the Transaction Processing Operations section of this document and the additional criteria stipulated in Annex A. Other entities
•e.g., point-of-interaction …
Modified
p. 6 → 7
• Must include the name/usage e.g.:
• Must include the name/usage, e.g.:
Removed
p. 7
Effective 1 January 2023: All hosts must support ISO PIN block format 4 decryption.
Effective 1 January 2025: All hosts must support ISO PIN block format 4 encryption.
Effective 1 January 2025: All hosts must support ISO PIN block format 4 encryption.
Modified
p. 7 → 8
• When used for the protection of PIN and account data when conveyed between non-integrated components of a POI device
•e.g., an SCR and a PIN pad.Note: When created and/or loaded by the acquiring entity, these keys are in scope of the Transaction Processing Operations section.
•e.g., an SCR and a PIN pad.
• When used for the protection of PIN and account data when conveyed between non-integrated components of a POI device
•e.g., an SCR and a PIN pad.
•e.g., an SCR and a PIN pad.
Modified
p. 7 → 8
Effective 1 January 2023: Fixed key for TDES PIN encryption in POI devices is disallowed.
Effective 1 January 2023: Fixed key for TDEA PIN encryption in POI devices is disallowed.
Modified
p. 7 → 8
Effective 1 January 2023: Fixed key for TDES PIN encryption in host-to-host connections is disallowed.
Effective 1 January 2023: Fixed key for TDEA PIN encryption in host-to-host connections is disallowed.
Modified
p. 8 → 9
• Device models whose approvals are valid are listed in the list “Approved PIN Transaction Security (PTS) Devices” under the “PIN- acceptance Device” tab and must belong to one of the PCI PTS Approval Classes: PED, EPP, and UPT.
• Device models whose approvals are valid are listed in the list “Approved PIN Transaction Security (PTS) Devices” under the “PIN- acceptance Device” tab and must belong to one of the PCI PTS Approval Classes: PED, EPP, SCRP and UPT.
Modified
p. 9 → 11
ANSI, EMV, ISO, FIPS, NIST, and PCI Standards Source Publication ANSI ANSI X3.92: Data Encryption Algorithm ANSI X9.24 (Part 1): Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques ANSI X9.24 (Part 2): Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for the Distribution of Symmetric Keys ANSI X9.24 (Part 3): Retail Financial Services Symmetric Key Management Part 3: Derived Unique Key Per Transaction ANSI X9.42: Public-key Cryptography for the Financial Service Industry: Agreement of …
ANSI, EMV, ISO, FIPS, NIST, and PCI Standards Source Publication ANSI ANSI X9.24 (Part 1): Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques ANSI X9.24 (Part 2): Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for the Distribution of Symmetric Keys ANSI X9.24 (Part 3): Retail Financial Services Symmetric Key Management Part 3: Derived Unique Key Per Transaction ANSI X9.42: Public-key Cryptography for the Financial Service Industry: Agreement of Symmetric Keys Using Discrete Logarithm …
Modified
p. 12 → 14
• One of the versions of the PCI PTS standard, as members of Approval Classes EPP, PED, or UPT (collectively known as POI Devices) and Approval Class HSMs, or
• One of the versions of the PCI PTS standard, as members of Approval Classes EPP, PED, SCRP or UPT (collectively known as POI Devices) and Approval Class HSMs, or
Modified
p. 12 → 14
• FIPS 140-2 level 3 or higher 1-1 The entity acquiring PIN-based transactions is responsible for maintaining information sufficient to demonstrate the use of approved devices. For each individual device, the minimal information elements are indicated below (in line with PCI PIN Requirement 30, PCI PIN Requirement 33, and PCI DSS Requirement 9.9.1):
• FIPS 140-2 or FIPS 140-3 level 3 or higher 1-1 The entity acquiring PIN-based transactions is responsible for maintaining information sufficient to demonstrate the use of approved devices. For each individual device, the minimal information elements are indicated below (in line with PCI PIN Requirement 30, PCI PIN Requirement 33, and PCI DSS Requirement 9.9.1):
Modified
p. 12 → 14
1-1.b Compare the information against the list of approved PTS devices at www.pcisecuritystandards.org to determine which POI devices used are PCI approved and are listed, with a valid PCI approval number on the PCI SSC website.
Modified
p. 14 → 16
• FIPS140-2 Level 3 or higher certified, or
• FIPS140-2 or FIPS 140-3 Level 3 or higher certified, or
Modified
p. 14 → 16
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140- 2 Level 3, or higher. Refer http://csrc.nist.gov.
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 or FIPS 140-3 Level 3, or higher. Refer http://csrc.nist.gov.
Modified
p. 14 → 16
1-3.b Examine documented procedures and interview personnel to verify that all PIN-translation operations are performed only by the FIPS- approved and/or PTS-approved HSMs identified above.
1-3.b Examine documented procedures and interview personnel to verify that all PIN-translation operations are performed only by the FIPS-approved and/or PTS-approved HSMs identified above.
Modified
p. 15 → 17
PIN Security Requirements Testing Procedures 1-4.b For all FIPS-approved HSMs used, examine HSM devices and examine 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:
PIN Security Requirements Testing Procedures 1-4.b For all FIPS-approved HSMs used, examine HSM devices and examine the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS140-2 or FIPS 140-3 Level 3 (or higher) approval listing for each HSM:
Modified
p. 15 → 17
a) All cardholder PINs processed online must be encrypted and decrypted using an approved cryptographic technique that provides a level of security compliant with international and industry standards. Any cryptographic technique implemented meets or exceeds the cryptographic strength of TDEA using double-length keys.
Modified
p. 15 → 17
2-2.b Examine system documentation, the summary of cryptographic keys, and the network schematic (see “Overview” section) to determine key-management methods used within each zone•e.g., terminal to host, host to next node, etc. Confirm only approved methods are in use.
2-2.b Examine system documentation, the summary of cryptographic keys, and the network schematic (see “Overview” section) to determine key- management methods used within each zone•e.g., terminal to host, host to next node, etc. Confirm only approved methods are in use.
Removed
p. 16
Effective 1 January 2023: All hosts must support ISO PIN block format 4 decryption.
Effective 1 January 2025: All hosts must support ISO PIN block format 4 encryption.
Effective 1 January 2023: Fixed key for TDES PIN encryption in POI devices is disallowed.
Effective 1 January 2023: Fixed key for TDES PIN encryption in host-to- host connections is disallowed.
Effective 1 January 2025: All hosts must support ISO PIN block format 4 encryption.
Effective 1 January 2023: Fixed key for TDES PIN encryption in POI devices is disallowed.
Effective 1 January 2023: Fixed key for TDES PIN encryption in host-to- host connections is disallowed.
Modified
p. 16 → 18
• The TDEA using the electronic code book (TECB) mode of operation,
• The TDEA using the electronic code book (TECB) mode of operation, and
Removed
p. 18
• For application packages, examine parameter files where the PIN- block format is specified (e.g., the KEYF file for Base 24). Verify the format is ISO Formats 0, 1, 3, or 4 as the online PIN-block type for compliance.
Modified
p. 18 → 20
• For internally developed systems, examine system design documentation, transaction logs, or source code for type of PIN- block format(s) used.
• For internally developed systems, examine system design documentation, transaction logs, or source code for type of PIN-block format(s) used.
Modified
p. 18 → 20
3-2.a Using the summary from Requirement 1, identify any non-PCI- approved devices and device types for which the ICC card reader is not integrated in the PIN entry device. For each of these device types, Interview applicable personnel to determine that PINs enciphered only for transmission between the PIN entry device and the ICCR use one of the PIN-block formats specified in ISO 9564. If format 2 is used, verify that a unique-key-per-transaction method in accordance with ISO 11568 is …
3-2.a Using the summary from Requirement 1, identify any non-PCI- approved devices and device types for which the ICC card reader is not integrated in the PIN entry device. For each of these device types, Interview applicable personnel to determine that PINs enciphered only for transmission between the PIN entry device and the ICCR use one of the PIN-block formats specified in ISO 9564. If format 2 is used, verify that a unique-key-per- transaction method in accordance with ISO 11568 …
Modified
p. 21 → 23
• An approved key-generation function of a PCI-approved HSM or POI
• An approved key-generation function of a PCI-approved HSM or
Modified
p. 21 → 23
Note: Random number generation is critical to the security and integrity of all cryptographic systems. All cryptographic key generation relies upon good quality, randomly generated values.
Note: Random number generation is critical to the security and integrity of all cryptographic systems. All cryptographic key generation relies upon good quality, randomly generated, values.
Modified
p. 21 → 23
• An approved key-generation function of a PCI
•approved HSM or
•approved HSM or
• An approved key-generation function of a PCI
•approved HSM or POI
•approved HSM or POI
Modified
p. 21 → 23
• An approved key-generation function of a PCI-approved HSM or
• An approved key-generation function of a PCI-approved HSM or POI
Modified
p. 23 → 25
•e.g.,
•must have key-generation capabilities disabled when not in use and other activities are continuing.
• e.g., providing services simultaneously to host systems, such as for transaction processing
•must have key-generation capabilities disabled when not in use and other activities are continuing.
•must have key-generation capabilities disabled when not in use and other activities are continuing.
Modified
p. 23 → 25
6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (for example, unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear- text key or key component (e.g., a tapping device) between the key- generation device and the device or medium receiving the key or key component.
6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (for example, unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear-text key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component.
Modified
p. 23 → 25
6-1.4.b Observe key-generation set-up processes for all key types to verify that key-generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
6-1.4.b Observe key-generation set-up processes for all key types to verify that key- generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
Modified
p. 23 → 25
6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during key-generation processes where clear-text keying material is in use. It must not be feasible to observe any clear-text keying material either directly or via camera monitoring.
6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during key- generation processes where clear-text keying material is in use. It must not be feasible to observe any clear-text keying material either directly or via camera monitoring.
Modified
p. 24 → 26
Single-purpose computers with an installed SCD or a modified PED where clear keying material is injected directly from a secure port on the key- generating SCD to the target SCD (e.g., a POI device) meet this requirement. Where the components pass through memory of the PC, Requirement 13 of Annex B must be met.
Single-purpose computers with an installed SCD or a modified PED where clear keying material is injected directly from a secure port on the key-generating SCD to the target SCD (e.g., a POI device) meet this requirement. Where the components pass through memory of the PC, Requirement 13 of Annex B must be met.
Modified
p. 24 → 26
6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any clear- text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
Removed
p. 25
Printers used for this purpose are not used for other purposes, are managed under dual control in a secure room that meets the requirements of 32-9 in Annex B, and are not networked.
• Printers are used only under dual control and only within a secure room that meets the requirements of 32-9 in Annex B; and
6-3.c Observe blind mailers, tamper-evident and authenticable packaging, or other sealed containers used for key components to verify that components cannot be read from within and that tampering can be detected.
• Printers are used only under dual control and only within a secure room that meets the requirements of 32-9 in Annex B; and
6-3.c Observe blind mailers, tamper-evident and authenticable packaging, or other sealed containers used for key components to verify that components cannot be read from within and that tampering can be detected.
Modified
p. 25 → 27
Printers used for this purpose must not be used for other purposes, must not be networked (i.e., locally connected), and must be managed under dual control, including use of a secure room that meets the requirements of 32-9 in Annex B.
Printers used for this purpose must not be used for other purposes, must not be networked (i.e., locally connected only), and must be managed under dual control. Location must be a secure room that meets the following requirements:
Modified
p. 25 → 27
6-3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed in tamper-evident and authenticable packaging immediately after printing such that:
6-3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed in tamper- evident and authenticable packaging immediately after printing such that:
Modified
p. 25 → 27
6-3.c Observe processes for printing key components to verify that:
Modified
p. 25 → 27
• Printers are not networked.
• Printers are not networked; and
Modified
p. 26 → 29
•depending on media
•immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual.
6-4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted
•depending on media
•immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual.
•depending on media
•immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual.
Modified
p. 26 → 29
Examples of where such key residue may exist include (but are not limited to): • Printing material, including ribbons and paper waste
Examples of where such key residue may exist include (but are not limited to):
Modified
p. 28 → 31
PIN Security Requirements Testing Procedures 6-6.b From observation of key-management processes verify that clear- text private or secret keys or their components are not transmitted across insecure channels, including but not limited to:
PIN Security Requirements Testing Procedures 6-6.b From observation of key-management processes verify that clear-text private or secret keys or their components are not transmitted across insecure channels, including but not limited to:
Modified
p. 29 → 31
7-2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs. The minimum log contents include date and time, object name/identifier, purpose, name and signature of individual(s) involved, tamper-evident package number(s), and serial number(s) of device(s) involved.
Modified
p. 29 → 31
7-2.c Examine logs of key generation to verify that exchanges of higher- level keys with other organizations have been recorded and that all required elements were captured.
7-2.c Examine logs of key generation to verify that exchanges of higher-level keys with other organizations have been recorded and that all required elements were captured.
Modified
p. 30 → 32
a) Physically forwarding the key as at least two separate key shares or full-length components (hard copy, smart card, SCD) using different communication channels, or
Modified
p. 31 → 33
PIN Security Requirements Testing Procedures 8-1 (continued)
PIN Security Requirements Testing Procedures
Modified
p. 31 → 33
8-1.b If key components are transmitted in clear text using pre-numbered, tamper-evident, authenticable packaging, perform the following:
8-1.b If key components are transmitted in clear text using pre-numbered, tamper- evident, authenticable packaging, perform the following:
Modified
p. 31 → 33
• Confirm through observation, interview, and inspection of the records of past key transfers that the process used to transport clear-text key components using pre-numbered, tamper-evident, authenticable packaging, is sufficient to ensure:
• Confirm through observation, interview, and inspection of the records of past key transfers that the process used to transport clear-text key components using pre- numbered, tamper-evident, authenticable packaging, is sufficient to ensure:
Modified
p. 31 → 33
− Each component was sent to/from only the custodian(s) authorized for the component − Prior to the use of the component, the serial number was confirmed.
− Each component was sent to/from only the custodian(s) authorized for the − Prior to the use of the component, the serial number was confirmed.
Modified
p. 32 → 34
• Examine documented procedures to verify that the SCD requires dual- control mechanisms to become operational.
• Examine documented procedures to verify that the SCD requires dual-control mechanisms to become operational.
Modified
p. 33 → 35
8-2.a Examine documented procedures to verify they include controls to ensure that no single person can gain access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. Verify procedures include:
Removed
p. 34
PIN Security Requirements Testing Procedures (i.e., m = 3) can be used to derive the key, no single individual can have access to more than two components/shares.
Modified
p. 34 → 36
8-3 E-mail shall not be used for the conveyance of secret or private keys or their components/shares, even if encrypted, unless the key (or component/share) has already been encrypted in accordance with these requirements•i.e., in an SCD. This is due to the existence of these key values in memory just prior to encryption or subsequent to decryption. In addition, corporate e-mail systems allow the recovery by support staff of the clear text of any encrypted text or files conveyed through …
PIN Security Requirements Testing Procedures 8-3 E-mail shall not be used for the conveyance of secret or private keys or their components/shares, even if encrypted, unless the key (or component/share) has already been encrypted in accordance with these requirements•i.e., in an SCD. This is due to the existence of these key values in memory just prior to encryption or subsequent to decryption. In addition, corporate e-mail systems allow the recovery by support staff of the clear text of any encrypted …
Modified
p. 35 → 36
8-4 Public keys must be conveyed in a manner that protects their integrity and authenticity.
Modified
p. 36 → 37
9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear- text key component must at all times be either:
9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear-text key component must at all times be either:
Modified
p. 36 → 37
• Sealed in a security container or courier mailer (including pre- numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or
• Sealed in a security container or courier mailer (including pre-numbered, tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or
Modified
p. 36 → 37
• Sealed in a security container or courier mailer (including pre- numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or
• Sealed in a security container or courier mailer (including pre-numbered, tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or
Modified
p. 36 → 37
9-1.b Observe key-management processes, examine associated logs, and interview responsible personnel to verify processes implemented ensure that any single clear-text key component is at all times either:
9-1.b Observe key-management processes, examine associated logs, and interview responsible personnel to verify processes implemented ensure that any single clear- text key component is at all times either:
Modified
p. 37 → 38
9-2.c Verify documented procedures require that any sign of package tampering is identified, reported, and ultimately results in the destruction and replacement of both:
9-2.c Verify documented procedures require that any sign of package tampering is identified, reported, and, if compromise is confirmed, ultimately results in the destruction and replacement of both:
Modified
p. 37 → 38
• Any keys encrypted under this (combined) key 9-2.d Interview responsible personnel and observe processes to verify that, if a package shows signs of tampering indicating a component was potentially compromised, processes are implemented to identify the tampering, report/escalate it, and ultimately result in the destruction and replacement of both:
• Any keys encrypted under this (combined) key 9-2.d Interview responsible personnel and observe processes to verify that if a package shows signs of tampering indicating a component was potentially compromised, processes are implemented to identify the tampering, report/escalate it, and, if compromise is confirmed, ultimately results in the destruction and replacement of both:
Modified
p. 37 → 38
9-2.e Examine records related to any escalated transmittal events. Verify that it resulted in the destruction and replacement of both:
9-2.e Examine records related to any escalated transmittal events. Verify that if compromise is confirmed it resulted in the destruction and replacement of both:
Modified
p. 38
9-3.b Observe implemented access controls and processes to verify that only those authorized key custodians⎯and designated backup(s)⎯have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
Modified
p. 38 → 39
9-3.c Examine physical access logs (e.g., to security containers for key components) to verify that only the authorized individual(s) have access to each component.
PIN Security Requirements Testing Procedures 9-3.c Examine physical access logs (e.g., to security containers for key components) to verify that only the authorized individual(s) have access to each component.
Modified
p. 39
9-5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components not in an SCD. Out-of- band mechanisms must be used to verify receipt of the appropriate bag numbers.
Modified
p. 39
• 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.
• 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. 39 → 40
9-6 If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that:
PIN Security Requirements Testing Procedures 9-6 If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that:
Modified
p. 39 → 40
• The components are repackaged at receipt into separate tamper- evident and authenticable packages for storage at the receiving location.
• The components are repackaged at receipt into separate tamper-evident and authenticable packages for storage at the receiving location.
Modified
p. 40 → 41
Note: Entities that are in the process of migrating from older devices to PCI devices approved against version 3 or higher of the PCI POI Security Requirements
•and thus have a mixed portfolio of devices
•may use RSA key sizes less than 2048 and use SHA-1 to help facilitate the migration. However, in all cases, version 3 or higher devices must implement RSA using key sizes of 2048 or higher and SHA-2 when used for key distribution using asymmetric techniques in accordance …
•and thus have a mixed portfolio of devices
•may
Note: Entities using POI version 1 and/or version 2 devices may use RSA key sizes of 1024 and/or SHA-1 if the devices do not support RSA key sizes of 2048 or SHA-2. However, in all cases, POI version 3 or higher devices must implement RSA using key sizes of 2048 or higher and SHA-2 when used for key distribution using asymmetric techniques in accordance with Annex A.
Modified
p. 40 → 41
10-1.b Using the network schematic and the summary listing of cryptographic keys and through interview of personnel, identify keys that protect other keys for transmission. Consider keys manually transferred (e.g., cryptograms sent to an ESO) as well as those that are system- generated and transferred (e.g., KEK or TMK encrypting working keys).
10-1.b Using the network schematic and the summary listing of cryptographic keys and through interview of personnel, identify keys that protect other keys for transmission. Consider keys manually transferred (e.g., cryptograms sent to an ESO) as well as those that are system-generated and transferred (e.g., KEK or TMK encrypting working keys).
Modified
p. 41 → 42
− TDEA 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.
− TDEA 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.
Modified
p. 43 → 44
Requirement 12: Secret and private keys must be input into hardware (host) security modules (HSMs) and POI PIN-acceptance devices in a secure manner. a. Unencrypted secret or private keys must be entered using the principles of dual control and split knowledge. b. Key-establishment techniques using public-key cryptography must be implemented securely.
Requirement 12: Secret and private keys must be input into hardware (host) security modules (HSMs) and POI PIN-acceptance devices in a secure manner.
Modified
p. 43 → 44
12-1.c Witness a structured walk-through/demonstration of various key- loading processes for all key types (MFKs, AWKs, TMKs, PEKs, etc. Verify the number and length of the key components against information provided through verbal discussion and written documentation.
12-1.c Witness a structured walk-through/demonstration of various key-loading processes for all key types (MFKs, AWKs, TMKs, PEKs, etc. Verify the number and length of the key components against information provided through verbal discussion and written documentation.
Modified
p. 44 → 45
Trace historical movement of higher-order keys (MFK, KEK, and BDK) in and out of secure storage to ensure there is no break in the package- number chain that would call into question authorized handling and sufficient storage of the component or share. This must address at a minimum the time frame from the date of the prior audit.
Trace historical movement of higher-order keys (MFK, KEK, and BDK) in and out of secure storage to ensure there is no break in the package-number chain that would call into question authorized handling and sufficient storage of the component or share. This must address at a minimum the time frame from the date of the prior audit.
Removed
p. 45
• Separate key-loading devices for each component/share Note that for devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. Each half must be a minimum of five characters.
Modified
p. 45
12-3 The loading of clear-text cryptographic keys using a key-loading device requires dual control to authorize any key-loading session. It shall not be possible for a single person to use the key-loading device to load clear keys alone.
Modified
p. 45
Note: Passwords/authentication codes to the same object may be assigned to a custodian group team⎯e.g., custodian team for component A.
Modified
p. 45
Note: The addition of applications that replace or disable the PCI- evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. If modified PEDs are not validated and approved to the KLD approval class, they must be managed in accordance with Annex B Requirement 13-9.
Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. If modified PEDs are not validated and approved to the KLD approval class, they must be managed in accordance with Annex B Requirement 13-9.
Modified
p. 45
12-3.a Identify instances where a key-loading device is used to load clear- text keys. Examine documented procedures for loading of clear-text cryptographic keys, to verify:
12-3.a Identify instances where a key-loading device is used to load clear-text keys. Examine documented procedures for loading of clear-text cryptographic keys, to verify:
Modified
p. 46
Note: Concatenation of key components together to form the key is unacceptable; e.g., concatenating two 8-hexadecimal character halves to form a 16-hexadecimal secret key.
Modified
p. 46
12-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.
12-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.
Modified
p. 46
12-5 Examine vendor documentation describing options for how the HSM MFK is created and verify the current MFK was created using AES or double- or triple-length TDEA. Corroborate this via observation of processes, with information gathered during the interview process, and procedural documentation provided by the entity under review.
12-5 Examine vendor documentation describing options for how the HSM MFK is created and verify the current MFK was created using AES or double- or triple- length TDEA. Corroborate this via observation of processes, with information gathered during the interview process, and procedural documentation provided by the entity under review.
Modified
p. 49
Note: The addition of applications that replace or disable the PCI- evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. If modified PEDs are not validated and approved to the KLD approval class, they must be managed in accordance with Annex B Requirement 13-9.
Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. If modified PEDs are not validated and approved to the KLD approval class, they must be managed in accordance with Annex B Requirement 13-9.
Modified
p. 49
13-2.a Examine documentation to verify that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. For example, ATM keyboards or keyboards attached to an HSM shall never be used for the loading of clear-text secret or private keys or their components.
13-2.a Examine documentation to verify that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key- loading facility, as delineated in this requirement. For example, ATM keyboards or keyboards attached to an HSM shall never be used for the loading of clear- text secret or private keys or their components.
Modified
p. 49
• The electronic media are placed into secure storage and managed under dual control (only if there is a possibility they will be required for future re-loading of the component into the cryptographic device); or
• The electronic media are placed into secure storage and managed under dual control (only if there is a possibility they will be required for future re- loading of the component into the cryptographic device); or
Modified
p. 49
• Instructions for the medium to be placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or
• Instructions 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. 50 → 49
13-3.b Observe key-loading processes to verify that the loading process results in one of the following:
Modified
p. 50 → 49
• 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
• 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. 50
13-4 For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device:
PIN Security Requirements Testing Procedures 13-4 For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device:
Modified
p. 50
Note: A PCI-approved KLD meets this requirement for a SCD.
Modified
p. 50
13-4.3 The key-loading device must be designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel must ensure that a key- recording device is not inserted between the SCDs.
13-4.3 The key-loading device must be designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel must ensure that a key-recording device is not inserted between the SCDs.
Modified
p. 50
13-4.3.b Verify that both authorized personnel involved in key-loading activity inspect the key-loading device prior to use to ensure that a key- recording device has not been inserted between the SCDs.
13-4.3.b Verify that both authorized personnel involved in key-loading activity inspect the key-loading device prior to use to ensure that a key-recording device has not been inserted between the SCDs.
Modified
p. 51 → 50
13-4.4 The key-loading device must not retain any information that might disclose the key (e.g., allow replay of the key for injection into a non-SCD) that was installed in the device or a key that it has successfully transferred.
Modified
p. 51 → 50
13-5.a Interview personnel and observe media locations to verify that the media is maintained in a secure storage location accessible only to custodian(s) authorized to access the key components.
(Continued on next page) 13-5.a Interview personnel and observe media locations to verify that the media is maintained in a secure storage location accessible only to custodian(s) authorized to access the key components.
Modified
p. 51
13-5.c Interview designated component holder(s) and examine key- management logs to verify that media or devices removed from secure storage are in the physical possession of only the designated component holder(s).
13-5.c Interview designated component holder(s) and examine key-management logs to verify that media or devices removed from secure storage are in the physical possession of only the designated component holder(s).
Modified
p. 51
13-6 If the component is in human-readable form (e.g., printed within a PIN-mailer type document), it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
13-6 If the component is in human-readable form (e.g., printed within a PIN- mailer type document), it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
Modified
p. 52 → 51
13-7 Written or printed key-component documents must not be opened until immediately prior to use.
Modified
p. 52 → 51
13-7.a Examine documented procedures and confirm that printed/written key-component documents are not opened until immediately prior to use.
13-7.a Examine documented procedures and confirm that printed/written key- component documents are not opened until immediately prior to use.
Modified
p. 53 → 52
14-1.b Observe key-loading environments and controls to verify the following:
Modified
p. 53 → 52
14-3 Key-loading equipment usage must be monitored and a log of all key-loading activities maintained for audit purposes containing at a minimum date, time, personnel involved, and number of devices keys are loaded to.
14-3 Key-loading equipment usage must be monitored, and a log of all key- loading activities maintained for audit purposes shall contain, at a minimum, date, time, personnel involved, and number of devices keys are loaded to.
Modified
p. 53
14-4 Any physical tokens (e.g., brass keys or chip cards) used to enable key-loading must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control. These tokens must be secured in a manner similar to key components, including tamper-evident, authenticable packaging and the use of access-control logs for when removed or placed into secure storage.
PIN Security Requirements Testing Procedures 14-4 Any physical tokens (e.g., brass keys or chip cards) used to enable key- loading must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control. These tokens must be secured in a manner similar to key components, including tamper-evident, authenticable packaging and the use of access-control logs for when removed or placed into secure storage.
Modified
p. 54 → 53
14-4.d Verify that access-control logs exist and are in use including notation of tamper-evident, authenticable bag numbers.
Modified
p. 54 → 53
14-5 Default passwords/authentication codes used to enforce dual-control must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change.
14-5 Default passwords/authentication codes used to enforce dual control must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change.
Modified
p. 54
15-1 A cryptographic-based validation mechanism must be in place to ensure the authenticity and integrity of keys and/or their components (for example, testing key check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO 11568. Where check values are used, recorded, or displayed, key- component check values and key check values shall be generated by a cryptographic process such that all portions of the key or key component are …
15-1 A cryptographic-based validation mechanism must be in place to ensure the authenticity and integrity of keys and/or their components (for example, testing key check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO 11568. Where check values are used, recorded, or displayed, key-component check values and key check values shall be generated by a cryptographic process such that all portions of the key or key component are involved …
Modified
p. 54
Note: Check values are computed by encrypting an all-zero block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). Either this method must be used for TDEA or TDEA must use, and AES shall use a technique where the KCV is calculated by MACing an all-zero block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The …
Note: Check values may be computed by two methods. TDEA may use either method. AES must only use the CMAC method. In the first method, check values are computed by encrypting an all binary zeros block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). In the second method the KCV is calculated by MACing an all binary zeros block using the …
Modified
p. 55 → 54
15-2 The public key must have its authenticity and integrity ensured. In order to ensure authenticity and integrity, a public key must be encrypted in accordance with Annex C, or if in plaintext form, must:
Modified
p. 55
16-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for all key- loading operations.
16-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for all key-loading operations.
Modified
p. 56
17-1.b For all keys shared between two organizations (including key- encryption keys used to encrypt a PIN-encryption key) perform the following:
17-1.b For all keys shared between two organizations (including key-encryption keys used to encrypt a PIN-encryption key) perform the following:
Modified
p. 56
• Generate or otherwise obtain key-check values for any key- encipherment keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than ten zone connections are in use. This is not intended to be based on values retained on paper or otherwise sent as part of the original conveyance of the keying material, but rather on values generated from stored zone production keys from the production host database. Cryptograms may be used …
• Generate or otherwise obtain key-check values for any key-encipherment keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than ten zone connections are in use. This is not intended to be based on values retained on paper or otherwise sent as part of the original conveyance of the keying material, but rather on values generated from stored zone production keys from the production host database. Cryptograms may be used for …
Modified
p. 57
18-2.a Verify that documented procedures are documented require that key-component packaging/containers showing signs of tampering indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
18-2.a Verify that documented procedures are documented require that key- component packaging/containers showing signs of tampering indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
Modified
p. 58
• Implement Key Blocks for internal connections and key storage within Service Provider Environments
• Implement Key Blocks for internal connections and key storage within Service Provider Environments • this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019.
Modified
p. 58
• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 June 2021.
• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 January 2023.
Modified
p. 58
• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 June 2023.
• Implement Key Block to extend to all merchant hosts, point-of- sale (POS) devices and ATMs. Effective date: 1 January 2025.
Modified
p. 58
• A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself,
• A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself, e.g., TR-31
Modified
p. 58
• A digital signature computed over that same data,
• A digital signature computed over that same data, e.g., TR-34
Modified
p. 59
PIN Security Requirements Testing Procedures
PIN Security Requirements Testing Procedures 19-2 Private keys:
Modified
p. 60 → 59
19-4 Keys must never be shared or substituted between production and test/development systems:
Modified
p. 60 → 59
• Key used for production must never be present or used in a test system, and
• Key used for production must never be present or used in a test system,
Modified
p. 60
19-5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements.
PIN Security Requirements Testing Procedures 19-5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge …
Modified
p. 60
• Subsequent to completion of testing, all keying materials must be deleted and the server/computer platforms must be wiped and rebuilt from read-only media.
• Subsequent to completion of testing, all keying materials must be deleted, and the server/computer platforms must be wiped and rebuilt from read-only media.
Modified
p. 61 → 60
This means not only the PIN-encryption key(s), but also keys that are used to protect other keys, firmware-authentication keys, payment- application authentication and display-prompt control keys. As stated in the requirement, this does not apply to public keys resident in the device.
This means not only the PIN-encryption key(s), but also keys that are used to protect other keys, firmware-authentication keys, payment-application authentication and display-prompt control keys. As stated in the requirement, this does not apply to public keys resident in the device.
Modified
p. 61
20-2 If a transaction-originating terminal (for example POI device) interfaces with more than one acquiring organization, the transaction- originating terminal SCD must have a completely different and unique key or set of keys for each acquiring organization. These different keys, or sets of keys, must be totally independent and not variants of one another.
PIN Security Requirements Testing Procedures 20-2 If a transaction-originating terminal (for example POI device) interfaces with more than one acquiring organization, the transaction-originating terminal SCD must have a completely different and unique key or set of keys for each acquiring organization. These different keys, or sets of keys, must be totally independent and not variants of one another.
Modified
p. 62 → 61
20-2b Observe processes for generation and injection of keys into a single POI for more than one acquiring organization, to verify:
Modified
p. 62 → 61
• Unique data is used for the derivation process such that all transaction-originating POIs receive unique secret keys.
• Unique data is used for the derivation process such that all transaction- originating POIs receive unique secret keys.
Modified
p. 62
20-4 Entities processing or injecting DUKPT or other key-derivation methodologies must incorporate a segmentation strategy in their environments. Segmentation must use one or more of the following techniques:
PIN Security Requirements Testing Procedures 20-4 Entities processing or injecting DUKPT or other key-derivation methodologies must incorporate a segmentation strategy in their environments. Segmentation must use one or more of the following techniques:
Modified
p. 62
• Different BDKs by geographic region, market segment, processing platform, or sales unit
• Different BDKs by geographic region, market segment, processing platform, or sales unit Control Objective 6: Keys are administered in a secure manner.
Modified
p. 63 → 62
• Encrypted with a key of equal or greater strength as delineated in
• Encrypted with a key of equal or greater strength as delineated in Annex C
Modified
p. 63
21-2.1 Knowledge of any one key component/share does not convey any knowledge of any part of the actual cryptographic key.
PIN Security Requirements Testing Procedures 21-2.1 Knowledge of any one key component/share does not convey any knowledge of any part of the actual cryptographic key.
Modified
p. 64 → 63
21-2.3.b Observe key-component/share access controls and key-custodian authorizations/assignments to verify that all individuals with access to key components/shares are designated as key custodians for those components/shares.
Modified
p. 64 → 63
21-3 Key components/shares must be stored as follows: 21-3 Examine documented procedures, interview responsible personnel, and inspect key-component/share storage locations to verify that key components/shares are stored as outlined in Requirements 21-3.1 through 21-3.3 below.
21-3 Key components/shares must be stored as follows: 21-3 Examine documented procedures, interview responsible personnel, and inspect key-component/share storage locations to verify that key components/shares are stored as outlined in Requirements 21-3.1 through 21- 3.3 below.
Modified
p. 65 → 64
Note: Furniture-based locks or containers with a limited set of unique keys •for example, desk drawers
•are not sufficient to meet this requirement.
•are not sufficient to meet this requirement.
Note: Furniture-based locks or containers with a limited set of unique keys
Modified
p. 66 → 65
22-1.1 Key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.
PIN Security Requirements Testing Procedures 22-1.1 Key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.
Modified
p. 66 → 65
• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key- replacement process.
• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key-replacement process.
Modified
p. 67 → 65
22-1.4 A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including:
Modified
p. 67 → 66
22-1.5 Identification of specific events that would indicate a compromise may have occurred. Such events must include but are not limited to:
PIN Security Requirements Testing Procedures 22-1.5 Identification of specific events that would indicate a compromise may have occurred. Such events must include but are not limited to:
Modified
p. 68 → 67
Note: Exposure of keys that are created using reversible transforms of another (key-generation) key can result in the exposure of all keys that have been generated under that key-generation key. To limit this risk posed by reversible key calculation, such as key variants, the reversible transforms of a key must be secured in the same way as the original key- generation key.
Note: Exposure of keys that are created using reversible transforms of another (key-generation) key can result in the exposure of all keys that have been generated under that key-generation key. To limit this risk posed by reversible key calculation, such as key variants, the reversible transforms of a key must be secured in the same way as the original key-generation key.
Modified
p. 68 → 67
23-1.a Examine documented procedures and interview responsible personnel to determine whether keys are generated using reversible key- calculation methods.
23-1.a Examine documented procedures and interview responsible personnel to determine whether keys are generated using reversible key-calculation methods.
Modified
p. 69 → 68
• Variants used as KEKs must only be calculated from other key- encrypting keys.
• Variants used as KEKs must only be calculated from other key-encrypting keys.
Modified
p. 70 → 68
24-2 The procedures for destroying key components or shares that are no longer used or have been replaced by a new key must be documented and sufficient to ensure that no part of the key or component can be recovered. For written components, this must be accomplished by use of a cross-cut shredder, pulping, or burning. Strip-shredding is not sufficient.
Modified
p. 70 → 69
24-2.1 Keys on all other storage media types in all permissible forms
PIN Security Requirements Testing Procedures 24-2.1 Keys on all other storage media types in all permissible forms
Modified
p. 70 → 69
The third-party witness must sign an affidavit of destruction.
The third-party witness must sign an affidavit of destruction, and this affidavit is retained for a minimum of two years.
Modified
p. 70 → 69
24-2.2.b Inspect key-destruction logs and verify that a third-party, non- key-custodian witness signs an affidavit as a witness to the key destruction process.
24-2.2.b Inspect key-destruction logs and verify that a third-party, non-key- custodian witness signs an affidavit as a witness to the key destruction process.
Modified
p. 71 → 69
Requirement 25: Access to secret and private cryptographic keys and key material must be: a. Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use; and b. Protected such that no other person (not similarly entrusted with that component) can observe or otherwise obtain the component.
Requirement 25: Access to secret and private cryptographic keys and key material must be:
Modified
p. 71 → 69
25-1 To reduce the opportunity for key compromise, limit the number of key custodians to the minimum required for operational efficiency.
25-1 To reduce the opportunity for key compromise, limit the number of key custodians to the minimum required for operational efficiency. Controls include:
Modified
p. 71 → 70
25-1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.
PIN Security Requirements Testing Procedures 25-1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.
Modified
p. 72 → 70
• Signature of management authorizing the access 25-1.4 In order for key custodians to be free from undue influence in discharging their custodial duties, key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual except as noted below for organizations of insufficient size.
Modified
p. 72 → 70
For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual. The components collectively held by an individual and his or her direct reports shall not constitute a quorum (or …
For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual.
Modified
p. 73 → 72
26-1 Logs must be kept whenever keys, key components, or related materials are removed from secure storage or loaded to an SCD. These logs must be archived for a minimum of two years subsequent to key destruction.
26-1 Logs must be kept whenever keys, key components, or related materials are removed from secure storage or loaded to an SCD. The logs must be securely stored, for example, in a secure container with the associated key components. These logs must be archived for a minimum of two years subsequent to key destruction.
Modified
p. 73 → 72
• Loaded to an SCD 26-1.b Examine log files and audit log settings to verify that logs include the following:
• Securely stored 26-1.c Examine log files and audit log settings to verify that logs include the following:
Modified
p. 76 → 75
29-1.1 All POIs must be protected against compromise. Any compromise must be detected. Loading and use of any financial keys after the compromise must be prevented.
29-1.1 All POIs and other SCDs must be protected against compromise. Any compromise must be detected. Loading and use of any financial keys after the compromise must be prevented.
Modified
p. 77 → 76
PIN Security Requirements Testing Procedures 29-1.1.3 All personnel with access to POIs and other SCDs prior to deployment are documented in a formal list and authorized by management. A documented security policy must exist that requires the specification of personnel with authorized access to all secure cryptographic devices. This includes documentation of all personnel with access to POIs and other SCDs as authorized by management. The list of authorized personnel is reviewed at least annually.
PIN Security Requirements Testing Procedures 29-1.1.2 All personnel with access to POIs and other SCDs prior to deployment are documented in a formal list and authorized by management. A documented security policy must exist that requires the specification of personnel with authorized access to all secure cryptographic devices. This includes documentation of all personnel with access to POIs and other SCDs as authorized by management. The list of authorized personnel is reviewed at least annually.
Modified
p. 77 → 76
29-1.1.2.a Examine documented authorizations for personnel with access to devices to verify that prior to deployment:
Modified
p. 77 → 76
29-1.1.2.b For a sample of POIs and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in an auditable manner have access to devices.
Modified
p. 77 → 76
Note: Chain of custody includes procedures, as stated in Requirement 29-1, that ensure that access to all POI devices and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
Note: Chain of custody includes procedures, as stated in Requirement 29- 1, that ensure that access to all POI devices and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
Modified
p. 78 → 77
• Transportation using a trusted courier service (for example, via bonded carrier). The devices are then securely stored until key- insertion and deployment occurs.
• Transportation using a trusted courier service (for example, via bonded carrier). The devices are then securely stored until key-insertion and deployment occurs.
Modified
p. 78 → 77
• Use of physically secure and trackable packaging (for example, 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.
• Use of physically secure and trackable packaging (for example, 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. 78 → 77
(continued on next page) 29-3.a Examine documented procedures to confirm that they require physical protection of devices from the manufacturer’s facility up to the point of key- insertion and deployment, through one or more of the defined methods.
(continued on next page) 29-3.a Examine documented procedures to confirm that they require physical protection of devices from the manufacturer’s facility up to the point of key-insertion and deployment, through one or more of the defined methods.
Modified
p. 79 → 78
Devices must not be re-installed unless there is assurance they have not been tampered with or compromised.
Modified
p. 80 → 78
29-4.1 HSM serial numbers must be compared to the serial numbers documented by the sender (sent using a different communication channel from the device) to ensure device substitution has not occurred. A record of device serial-number verification must be maintained.
Modified
p. 80 → 79
29-4.2 The security policy enforced by the HSM must not allow unauthorized or unnecessary functions. HSM API functionality and commands that are not required to support specified functionality must be disabled before the equipment is commissioned.
PIN Security Requirements Testing Procedures 29-4.2 The security policy enforced by the HSM must not allow unauthorized or unnecessary functions. HSM API functionality and commands that are not required to support specified functionality must be disabled before the equipment is commissioned.
Modified
p. 80 → 79
29-4.2.e Verify that functionality is not enabled to allow the outputting of clear- text PINs.
29-4.2.e Verify that functionality is not enabled to allow the outputting of clear-text PINs.
Modified
p. 80 → 79
29-4.2.f Examine documentation to verify:
Modified
p. 81 → 79
29-4.3 When HSMs are connected to online systems, controls are in place to prevent the use of an HSM to perform privileged or sensitive functions that are not available during routine HSM operations.
Modified
p. 81 → 80
29-4.4 Inspect and test all HSMs
•either new or retrieved from secure storage
•prior to installation to verify devices have not been tampered with or compromised.
•either new or retrieved from secure storage
•prior to installation to verify devices have not been tampered with or compromised.
PIN Security Requirements Testing Procedures 29-4.4 Inspect and test all HSMs
•either new or retrieved from secure storage
•prior to installation to verify devices have not been tampered with or compromised.
•either new or retrieved from secure storage
•prior to installation to verify devices have not been tampered with or compromised.
Modified
p. 81 → 80
29-5.b Observe a sample of received devices to verify they are maintained in tamper-evident packaging until ready for installation.
29-5.b Observe a sample of received devices to verify they are maintained in tamper- evident packaging until ready for installation.
Modified
p. 82 → 81
• Ensure that POI devices are physically secured or otherwise controlled to prevent unauthorized access, modification, or substitution while devices are deployed for use. This includes both attended and unattended devices (for example, kiosks, “pay- at-the-pump,” etc.).
• Ensure that POI devices are physically secured or otherwise controlled to prevent unauthorized access, modification, or substitution while devices are deployed for use. This includes both attended and unattended devices (for example, kiosks, “pay-at-the-pump,” etc.).
Modified
p. 84 → 82
31-1.5 Devices are tracked during the return process. 31-1.5 Interview responsible personnel and examine device-return records to verify that devices are tracked during the return process.
Modified
p. 84 → 83
Requirement 32: Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following: a. Dual access controls required to enable the key-encryption function b. Physical protection of the equipment (e.g., locked access to it) under dual control c. Restriction of logical access to the equipment 32-1 …
Requirement 32: Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following:
Modified
p. 85 → 83
32-1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
Modified
p. 85 → 83
Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented for logical access via two individuals with two different passwords/authentication codes, or for physical access via a physical lock that requires two individuals, each with a different high-security key.
Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented for logical access via two individuals with two different passwords/authentication codes (at least five characters in length), or for physical access via a physical lock that requires two individuals, each with a different high-security key.
Modified
p. 85 → 83
For devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian.
For devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. Each half must be a minimum of five characters.
Modified
p. 85 → 83
32-1.2 Observe password policies and configuration settings to confirm that passwords/authentication codes used for dual control must be at least five numeric and/or alphabetic characters 32-1.3 Dual control must be implemented for the following:
32-1.2 Observe password policies and configuration settings to confirm that passwords/authentication codes used for dual control must be at least five numeric and/or alphabetic characters.
Modified
p. 85 → 84
• To place the device into a state that allows for the input or output of clear- text key components;
• To place the device into a state that allows for the input or output of clear-text key components;
Removed
p. 86
PIN Security Requirements Testing Procedures 32-1.4 Devices must not use default passwords/authentication codes.
Modified
p. 86 → 84
32-1.4.a Examine password policies and documented procedures to confirm default passwords/authentication codes must not be used for HSMs, KLDs, and other SCDs used to generate or load cryptographic keys.
32-1.4 Devices must not use default passwords/authentication codes. 32-1.4.a Examine password policies and documented procedures to confirm default passwords/authentication codes must not be used for HSMs, KLDs, and other SCDs used to generate or load cryptographic keys.
Removed
p. 87
• ANSI TR-34 presents a methodology that is compliant with these requirements.
Modified
p. 89
• System implementations must be designed and implemented to prevent replay attacks•e.g., through the use of random nonces and time stamps as noted in ANSI TR-34.
• System implementations must be designed and implemented to prevent replay attacks•e.g., through the use of random nonces and time stamps as noted in ANSI TR 34.
Modified
p. 89
• There are no means available in the implementation design for “man- in-the-middle” attacks.
• There are no means available in the implementation design for “man-in-the- middle” attacks.
Modified
p. 90 → 89
15-5 Key pairs generated external to the device that uses the key pair must be securely transferred and loaded into the device and must provide for key protection in accordance with this document. That is, the secrecy of the private key and the integrity of the public key must be ensured. The process must ensure that once keys are injected, they are no longer available for injection into other POI devices•i.e., key pairs are unique per POI device.
Modified
p. 90
18-4 POIs shall only communicate with a Certification Authority (CA) for the purpose of certificate signing (or for key injection where the certificate-issuing authority generates the key pair on behalf of the POI); and with KDHs for key management, normal transaction processing, and certificate (entity) status checking.
18-4 POIs shall only communicate with a Certification Authority (CA) for the purpose of certificate signing (or for key injection where the certificate- issuing authority generates the key pair on behalf of the POI); and with KDHs for key management, normal transaction processing, and certificate (entity) status checking.
Modified
p. 91 → 90
18-4.b Interview responsible personnel and observe POI configurations to verify that:
Modified
p. 91
19-6 Key pairs must not be reused for certificate renewal or replacement•i.e., new key pairs must be generated.
19-6 Key pairs must not be reused for certificate renewal or replacement• i.e., new key pairs must be generated.
Modified
p. 91
• Each key pair generated results in only one certificate
• Each key pair generated results in only one certificate 19-6.b Interview responsible personnel and observe certificate issuing and replacement processes to verify that:
Removed
p. 92
PIN Security Requirements Testing Procedures 19-6.b Interview responsible personnel and observe certificate issuing and replacement processes to verify that:
Modified
p. 92 → 91
19-7 Examine documented processes to verify that KDH private keys are not permitted to be shared between devices, except for load balancing and disaster recovery.
Modified
p. 92 → 91
19-8 POI private keys must not be shared between devices. 19-11.a Examine documented processes to verify that POI private keys are not permitted to be shared between devices.
19-8 POI private keys must not be shared between devices. 19-8.a Examine documented processes to verify that POI private keys are not permitted to be shared between devices.
Modified
p. 92 → 91
19-8.b Inspect public key certificates on the host processing system to confirm that a unique certificate exists for each connected POI.
Modified
p. 93 → 92
• Within a secure cryptographic device that meets applicable PCI PTS requirements for such a device,
• Within a secure cryptographic device that meets applicable PCI PTS or FIPS 140-2/140-3 level 3 or higher requirements for such a device,
Modified
p. 93 → 92
• Encrypted within an SCD using an algorithm and key size of equivalent or greater strength, or
• Encrypted using an algorithm and key size of equivalent or greater strength as delineated in Annex C, or
Modified
p. 94 → 93
10-5 Key sizes and algorithms must be in accordance with Annex C.
10-5 Key sizes and algorithms must be in accordance with Annex C. 10-5 Observe key-generation processes to verify that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed.
Modified
p. 94 → 93
15-5 Key pairs generated external to the device that uses the key pair must be securely transferred and loaded into the device and must provide for key protection in accordance with this document. That is, the secrecy of the private key and the integrity of the public key must be ensured. The process must ensure that once keys are injected they are no longer available for injection into other POI devices•i.e., key pairs are unique per POI device.
15-5 Key pairs generated external to the device that uses the key pair must be securely transferred and loaded into the device and must provide for key protection in accordance with this document. That is, the secrecy of the private key and the integrity of the public key must be ensured. The process must ensure that once keys are injected, they are no longer available for injection into other POI devices•i.e., key pairs are unique per POI device.
Modified
p. 95 → 94
• Subsequent to completion of testing, all keying materials must be deleted, and the server/computer platforms must be wiped and rebuilt from read- only media.
• Subsequent to completion of testing, all keying materials must be deleted, and the server/computer platforms must be wiped and rebuilt from read-only media.
Modified
p. 96 → 95
• Status checking (for example, Certificate Revocation Lists) signature
• Status checking (for example, Certificate Revocation Lists) signature keys, or
Modified
p. 97 → 95
19-10 Public-key-based implementations must provide mechanisms for restricting and controlling the use of public and private keys. For example, this can be accomplished through the use of X.509 compliant certificate extensions.
Modified
p. 97 → 96
19-11 CA private keys must not be shared between devices except for load balancing and disaster recovery.
PIN Security Requirements Testing Procedures 19-11 CA private keys must not be shared between devices except for load balancing and disaster recovery.
Modified
p. 97 → 96
• Certificates associated with encryption for remote key- distribution functions must not be used for any other purpose.
• Certificates associated with encryption for remote key-distribution functions must not be used for any other purpose.
Modified
p. 97 → 96
• Sub-CAs used to produce certificates used for remote key- delivery functions must not be used to produce certificates used for any other purpose.
• Sub-CAs used to produce certificates used for remote key-delivery functions must not be used to produce certificates used for any other purpose.
Modified
p. 97 → 96
(continued on next page) 19-12.a Examine implementation schematics and other relevant documentation to identify PKI architecture and where certificates are used in the implementation.
Modified
p. 99 → 98
• Within a secure cryptographic device that meets applicable PCI requirements for such a device,
• Within a secure cryptographic device that meets applicable PCI PTS of FIPS 140-2/140-3 level 3 or higher requirements for such a device,
Modified
p. 99 → 98
• Encrypted using an algorithm and key size of equivalent or greater strength, or
• Encrypted using an algorithm and key size of equivalent or greater strength as delineated in Annex C, or
Modified
p. 99 → 98
21-4.b Observe key-management operations and interview key custodians and key-management supervisory personnel to verify that private keys used to sign certificates, certificate-status lists, messages, or for key protection must exist only in one or more of the approved forms at all times.
21-4.b Observe key-management operations and interview key custodians and key- management supervisory personnel to verify that private keys used to sign certificates, certificate-status lists, messages, or for key protection must exist only in one or more of the approved forms at all times.
Modified
p. 101 → 100
− Reissue and distribute certificates to affected parties, or − Notify the affected parties to apply for new certificates.
Modified
p. 102 → 101
• 1024 POI devices 22-5.c Verify that KDH keys expire every five years unless another mechanism exists to prevent the use of a compromised KDH private key.
• 2048 for SCRP devices 22-5.c Verify that KDH keys expire every five years unless another mechanism exists to prevent the use of a compromised KDH private key.
Modified
p. 102 → 101
Requirement 25: Access to secret or private cryptographic keys and key material must be: a. Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use, and b. Protected such that no other person (not similarly entrusted with that component) can observe or otherwise obtain the component.
Requirement 25: Access to secret or private cryptographic keys and key material must be:
Modified
p. 102 → 101
Note: Individual user IDs may be assigned to a role or group.
Modified
p. 103 → 102
25-3.3 For CAs operated online•e.g., POI-signing CAs: Non- console access must use multi-factor authentication. This also applies to the use of remote console access.
25-3.3 For CAs operated online•e.g., POI-signing CAs: Non-console access must use multi-factor authentication. This also applies to the use of remote console access.
Modified
p. 103 → 102
25-3.3 Examine remote-access mechanisms and system configurations to verify that all non-console access, including remote access, requires multi- factor authentication.
25-3.3 Examine remote-access mechanisms and system configurations to verify that all non-console access, including remote access, requires multi-factor authentication.
Modified
p. 103 → 102
25-3.4 For CAs operated online•e.g., POI-signing CAs: Non- console user access to the CA or RA system environments shall be protected by authenticated encrypted sessions. No other remote access is permitted to the CA or RA platform(s) for system or application administration.
25-3.4 For CAs operated online•e.g., POI-signing CAs: Non-console user access to the CA or RA system environments shall be protected by authenticated encrypted sessions. No other remote access is permitted to the CA or RA platform(s) for system or application administration.
Modified
p. 107 → 106
The signing/MACing key(s) used for this must be protected using a secure cryptographic device in accordance with the key- management requirements stipulated in this document.
The signing/MACing key(s) used for this must be protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
Modified
p. 107 → 106
25-7.b Examine documentation and interview personnel and observe to verify that signing/MACing key(s) used for this are protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
25-7.b Examine documentation, interview personnel, and observe to verify that signing/MACing key(s) used for this are protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
Modified
p. 108 → 106
25-7.2 Online certificate-processing systems must employ individually or in combination network and host-based intrusion detection systems (IDS) to detect inappropriate access. At a minimum, database servers and the application servers for RA and web, as well as the intervening segments, must be covered.
Modified
p. 108 → 107
25-8 Implement user-authentication management for all system components as follows:
PIN Security Requirements Testing Procedures 25-8 Implement user-authentication management for all system components as follows:
Modified
p. 109 → 107
25-8.4 Passwords must have a minimum length of eight characters using a mix of alphabetic, numeric, and special characters or equivalent strength as defined in NIST SP 800-63B.
Modified
p. 109 → 108
25-8.7 Passwords are not stored on any of the systems except in encrypted form or as part of a proprietary one-way transformation process, such as those used in UNIX systems.
PIN Security Requirements Testing Procedures 25-8.7 Passwords are not stored on any of the systems except in encrypted form or as part of a proprietary one-way transformation process, such as those used in UNIX systems.
Modified
p. 110 → 108
25-9 Implement a method to synchronize all critical system clocks and times for all systems involved in key-management operations.
Modified
p. 110 → 109
• All physical and logical CA system components must be separated from key-distribution systems.
• All physical and logical CA system components must be separated from key- distribution systems.
Modified
p. 110 → 109
28-2.c Observe system and network configurations and physical access controls to verify that all physical and logical CA system components are separated from key-distribution systems.
28-2.c Observe system and network configurations and physical access controls to verify that all physical and logical CA system components are separated from key- distribution systems.
Modified
p. 111 → 109
28-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. 111 → 110
28-4 Each CA operator must develop a certificate policy. (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.) 28-4 Examine documented certificate policy to verify that the CA has one in place.
PIN Security Requirements Testing Procedures 28-4 Each CA operator must develop a certificate policy. (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.) 28-4 Examine documented certificate policy to verify that the CA has one in place.
Modified
p. 111 → 110
28-5 Documented procedures exist and are demonstrably in use by CAs to validate the identity of the certificate requestor and recipient before issuing a digital certificate for the recipient’s associated public key where the certificate request is not generated within the same secure room meeting the requirements of the Level 3 environment 28-5.a Examine documented procedures to verify that unless the certificate request is generated within the same secure room meeting the requirements of the Level 3 environment, they include …
28-5 Documented procedures exist and are demonstrably in use by CAs to validate the identity of the certificate requestor and recipient before issuing a digital certificate for the recipient’s associated public key where the certificate request is not generated within the same secure room meeting the requirements of the Level 3 environment defined below. These procedures must include at a minimum, two or more of the following for KDH certificate requests:
Removed
p. 112
PIN Security Requirements Testing Procedures defined below. These procedures must include at a minimum, two or more of the following for KDH certificate requests:
Modified
p. 112 → 110
• Verification of the certificate applicant’s possession of the associated private key through the use of a digitally signed certificate request pursuant to PKCS #10 or another cryptographically-equivalent demonstration;
• Verification of the certificate applicant’s possession of the associated private key through the use of a digitally signed certificate request pursuant to PKCS #10 or another cryptographically equivalent demonstration;
Modified
p. 112 → 110
• 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;
• Determination that the organization exists by using at least one third- party identity-proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization;
Modified
p. 113 → 111
28-5.1.b Observe certificate-signing requests, including certificate or key- validity status changes, to verify they include validation that:
28-5.1.b Observe certificate-signing requests, including certificate or key-validity status changes, to verify they include validation that:
Modified
p. 114 → 112
Requirement 32: Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following: a. Dual access controls are required to enable the key-encryption function. b. Physical protection of the equipment (e.g., locked access to it) under dual control. c. Restriction of logical access to the equipment …
Requirement 32: Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following:
Modified
p. 116 → 113
32-2.3.2 Access logs must record all personnel entering the Level 2 environment.
Modified
p. 116 → 114
32-2.4 The Level 2 entrance must be monitored by a video-recording system.
PIN Security Requirements Testing Procedures 32-2.4 The Level 2 entrance must be monitored by a video-recording system.
Modified
p. 116 → 114
32-2.5.1 Observe Level 3 environment entrances to verify that all doors to the Level 3 environment have locking mechanisms.
Modified
p. 117 → 114
32-2.5.2 The Level 3 environment must be enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars.
Modified
p. 117 → 114
32-2.5.2.a Examine physical security documentation for the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as have true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars 32-2.5.2.b Examine the physical boundaries of the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars and protection from …
32-2.5.2.a Examine physical security documentation for the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as have true floor-to- ceiling (slab-to-slab) walls, steel mesh, or bars 32-2.5.2.b Examine the physical boundaries of the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars and protection …
Modified
p. 117 → 115
PIN Security Requirements Testing Procedures 32-2.6.b Interview responsible personnel to verify that the documented procedures are followed for:
Modified
p. 118 → 115
32-2.6.1.c Interview a sample of personnel authorized for access through the Level 3 barrier to verify that they are assigned resources of the CA with defined business needs and duties.
Modified
p. 118 → 116
32-2.7.1 The mechanism for enforcing dual-control and dual- occupancy must be automated.
PIN Security Requirements Testing Procedures 32-2.7.1 The mechanism for enforcing dual-control and dual-occupancy must be automated.
Modified
p. 119 → 116
32-2.7.3 Dual occupancy requirements are managed using electronic (for example, badge and/or biometric) systems.
Modified
p. 120 → 117
Note: Motion-activated systems that are separate from the intrusion-detection system may be used to activate recording activity.
Note: Motion-activated systems that are separate from the intrusion- detection system may be used to activate recording activity.
Modified
p. 121 → 117
32-2.9.5 Personnel with access to the Level 3 environment must not have access to the media (for example, VCR tapes, digital-recording systems, etc.) containing the recorded surveillance data.
Modified
p. 121 → 118
32-2.9.6 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days.
PIN Security Requirements Testing Procedures 32-2.9.6 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days.
Modified
p. 122 → 118
32-3.1 Any windows in the secure room must be locked and protected by alarmed sensors.
Modified
p. 122 → 119
32-3.3 The intrusion-detection system(s) must be connected to the alarm system and automatically activated every time all authorized personnel have performed an authenticated exit of the secure room. The system must be configured to activate within 30 seconds.
PIN Security Requirements Testing Procedures 32-3.3 The intrusion-detection system(s) must be connected to the alarm system and automatically activated every time all authorized personnel have performed an authenticated exit of the secure room. The system must be configured to activate within 30 seconds.
Modified
p. 122 → 119
32-4.a Examine security policies and procedures to verify they require all non-CA personnel to sign an access logbook when entering the Level 3 environment.
32-4.a Examine security policies and procedures to verify they require all non- CA personnel to sign an access logbook when entering the Level 3 environment.
Modified
p. 123 → 119
32-4.1 The access log must include the following details:
Modified
p. 123 → 119
32-5 Inspect uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems, including intrusion- detection systems, are powered through the UPS.
32-5 Inspect uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems, including intrusion-detection systems, are powered through the UPS.
Modified
p. 123 → 120
32-6 All alarm events must be documented.
PIN Security Requirements Testing Procedures 32-6 All alarm events must be documented.
Modified
p. 124 → 120
32-6.3 All alarms for physical intrusion necessitate an active response within 30 minutes by personnel assigned security duties.
Modified
p. 124 → 121
32-7 A process must be implemented for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems to ensure accuracy of logs. It must be ensured that synchronization errors between CCTV, intrusion detection, and access control cannot exceed one minute.
PIN Security Requirements Testing Procedures 32-7 A process must be implemented for synchronizing the time and date stamps of the access, intrusion-detection, and monitoring (camera) systems to ensure accuracy of logs. It must be ensured that synchronization errors between CCTV, intrusion detection, and access control cannot exceed one minute.
Modified
p. 125 → 122
2. Remote distribution of symmetric keys using asymmetric techniques to transaction-originating devices. These criteria pertain to the characteristics of the actual key-distribution methodology implemented. If the key loading is not performed remotely and authentication is provided by another method
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates, Annex A does not apply. “Remotely” means whenever the key-loading device and the POI device are neither co- located nor connected via a direct mechanism, …
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates, Annex A does not apply. “Remotely” means whenever the key-loading device and the POI device are neither co- located nor connected via a direct mechanism, …
2. Remote distribution of symmetric keys using asymmetric techniques to transaction-originating devices. These criteria pertain to the characteristics of the actual key-distribution methodology implemented. If the key loading is not performed remotely and authentication is provided by another method
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates, Annex A does not apply. “Remotely” means whenever the key-loading device and the POI device are neither co- located nor connected via a direct mechanism, …
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates, Annex A does not apply. “Remotely” means whenever the key-loading device and the POI device are neither co- located nor connected via a direct mechanism, …
Modified
p. 126 → 123
• FIPS140-2 Level 3 or higher certified, or
• FIPS140-2 or FIPS 140-3 Level 3 or higher certified, or
Modified
p. 126 → 123
1-2 Key-injection facilities must only inject keys into equipment that conforms to the requirements for SCDs.
1-2 Key-injection facilities must only inject keys using equipment that conforms to the requirements for SCDs.
Modified
p. 126 → 123
Note: Key-injection platforms and systems shall include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs. This includes SCDs used in key-injection facilities (e.g., modified PEDs). If modified PEDs are not validated and approved to the KLD approval class, they must be managed in accordance with Requirement 13- 9.
Note: Key-injection platforms and systems shall include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs. This includes SCDs used in key-injection facilities (e.g., modified PEDs). If modified PEDs are not validated and approved to the KLD approval class, they must be managed in accordance with Requirement 13-9.
Modified
p. 126 → 123
1-3 For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and examine the list of approved devices to verify that all HSMs are either:
Modified
p. 126 → 123
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 Level 3, or higher. Refer http://csrc.nist.gov.
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 or FIPS 140-3 Level 3, or higher. Refer http://csrc.nist.gov.
Modified
p. 127 → 124
• Any applications, including application version number, resident within the device which were included in the PTS assessment 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:
• Any applications, including application version number, resident within the device which were included in the PTS assessment 1-4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS140-2 or FIPS 140-3 Level 3 (or higher) approval listing for each HSM:
Modified
p. 128 → 125
1-5.b Interview relevant personnel and examine documentation that describes and/or illustrates the architecture of the KIF to verify that all KIF components, key-management flows, and personnel interaction with key- management flows are identified and documented.
1-5.b Interview relevant personnel and examine documentation that describes and/or illustrates the architecture of the KIF to verify that all KIF components, key-management flows, and personnel interaction with key-management flows are identified and documented.
Removed
p. 129
• An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM
Modified
p. 129 → 126
• An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM 5-1.a Examine key-management policy documentation to verify that it requires that all devices used to generate cryptographic keys meet one of the following
• An approved key-generation function of a FIPS 140-2 or FIPS 140-3 Level 3 (or higher) HSM
Modified
p. 130 → 126
5-1.a Examine key-management policy documentation to verify that it requires that all devices used to generate cryptographic keys meet one of the following
Modified
p. 131 → 127
6-1.1.b Observe key-generation process demonstration and interview responsible personnel to verify:
Modified
p. 131 → 128
6-1.3 Devices used for generation of clear-text key components that are output in the clear must either be powered off when not in use or require re-authentication whenever key generation is invoked.
PIN Security Requirements Testing Procedures 6-1.3 Devices used for generation of clear-text key components that are output in the clear must either be powered off when not in use or require re-authentication whenever key generation is invoked.
Modified
p. 132 → 128
6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (for example, unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear-text key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component.
Modified
p. 132 → 128
6-1.4.b Observe key-generation set-up processes for all key types to verify that key-generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering⎯including verification that there is a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
6-1.4.b Observe key-generation set-up processes for all key types to verify that key- generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering⎯including verification that there is a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
Modified
p. 132 → 128
6-1.5.b During the demonstration for 6-1.1.b, observe the physical security controls (e.g., partitions or barriers) used, and validate that they ensure the key-component/key-generation process cannot be observed or accessed by unauthorized personnel directly or via camera monitoring (including those on cellular phones).
6-1.5.b During the demonstration for 6-1.1.b, observe the physical security controls (e.g., partitions or barriers) used, and validate that they ensure the key- component/key-generation process cannot be observed or accessed by unauthorized personnel directly or via camera monitoring (including those on cellular phones).
Modified
p. 133 → 129
6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any clear- text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
Modified
p. 134 → 130
Printers used for this purpose must not be used for other purposes, must not be networked (i.e., locally connected), and must be managed under dual control, including use of a secure room that meets the requirements of 32-9 in Annex B.
Printers used for this purpose must not be used for other purposes, must not be networked (i.e., locally connected only), and must be managed under dual control. Location must be a secure room that meets the following requirements:
Modified
p. 134 → 130
PIN Security Requirements Testing Procedures 6-3 Key components must be printed within blind mailers or sealed in tamper-evident and authenticable packaging immediately after printing or transcription to ensure that:
PIN Security Requirements Testing Procedures 6-3 Printed key components must be printed within blind mailers or sealed in tamper-evident and authenticable packaging immediately after printing or transcription to ensure that:
Modified
p. 134 → 130
6-3.a Examine documented procedures for printed key components and verify that they require key components to be printed within blind mailers or sealed in tamper-evident and authenticable packaging immediately after printing such that:
6-3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed in tamper- evident and authenticable packaging immediately after printing such that:
Modified
p. 134 → 130
• Printers used for this purpose are not used for other purposes, are managed under dual control in a secure room that meets the requirements of 32-9 in Annex B, and are not networked.
• Printers used for this purpose are not used for other purposes and are used only under dual control.
Modified
p. 134 → 130
• Key components are printed within blind mailers or sealed in tamper-evident and authenticable packaging immediately after printing, such that no one but the authorized custodian ever has physical access to the output;
Modified
p. 134 → 130
6-3.b Observe blind mailers, tamper-evident and authenticable packaging, or other sealed containers used for key components to verify that components cannot be read from within and that tampering can be detected.
Modified
p. 135 → 132
•depending on media
•immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual.
6-4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted
•depending on media
•immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual.
•depending on media
•immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual.
Modified
p. 135 → 132
Examples of where such key residue may exist include (but are not limited to): • Printing material, including ribbons and paper waste
Examples of where such key residue may exist include (but are not limited to):
Modified
p. 138 → 134
7-2.c Examine logs of key generation to verify that exchanges of higher- level keys with other organizations have been recorded and that all required elements were captured.
7-2.c Examine logs of key generation to verify that exchanges of higher-level keys with other organizations have been recorded and that all required elements were captured.
Modified
p. 138 → 134
7-2 Logs must exist for the generation of higher-level keys such as KEKs exchanged with other organizations and MFKs and BDKs. The minimum log contents include date and time, object name/identifier, purpose, name and signature of individual(s) involved, and tamper- evident package number(s) and serial number(s) of device(s) involved.
Modified
p. 138 → 134
7-2.a Examine documented key-generation procedures to verify that all key- generation events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components and MFKs and BDKs) must be logged.
7-2.a Examine documented key-generation procedures to verify that all key-generation events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components and MFKs and BDKs) must be logged.
Modified
p. 139 → 135
a) Physically forwarding the key as at least two separate key shares or full-length components (hard copy, smart card, SCD) using different communication channels, or
Modified
p. 140 → 136
PIN Security Requirements Testing Procedures 8-1 Keys must be transferred either encrypted, as two or more full- length clear-text components, key shares, or within an SCD.
PIN Security Requirements Testing Procedures 8-1 Keys must be transferred either encrypted, as two or more full-length clear-text components, key shares, or within an SCD.
Modified
p. 140 → 136
• Where key components are transmitted in clear-text using tamper- evident, authenticable mailers:
• Where key components are transmitted in clear-text using tamper-evident, authenticable mailers:
Modified
p. 140 → 136
• Where an SCD (i.e,, HSM or KLD) is conveyed with pre-loaded secret and/or private keys, the SCD must require dual-control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
• Where an SCD (i.e., HSM or KLD) is conveyed with pre-loaded secret and/or private keys, the SCD must require dual-control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
Modified
p. 141 → 137
PIN Security Requirements Testing Procedures 8-1.b If key components are transmitted in clear text using pre-numbered, tamper-evident, authenticable packaging, perform the following:
PIN Security Requirements Testing Procedures 8-1.b If key components are transmitted in clear text using pre-numbered, tamper- evident, authenticable packaging, perform the following:
Modified
p. 142 → 138
• Examine documented procedures to verify that the SCD requires dual- control mechanisms to become operational.
• Examine documented procedures to verify that the SCD requires dual-control mechanisms to become operational.
Modified
p. 144 → 139
8-2.b Observe key-transfer processes and interview personnel to verify that controls are implemented to ensure that no single person can gain access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. Verify the implemented controls ensure the following:
Modified
p. 144 → 140
8-3 E-mail shall not be used for the conveyance of secret or private keys or their components/shares, even if encrypted, unless the key (or component/share) has already been encrypted in accordance with these requirements•i.e., in an SCD. This is due to the existence of these key values in memory just prior to encryption or subsequent to decryption. In addition, corporate e-mail systems allow the recovery by support staff of the clear text of any encrypted text or files conveyed through …
PIN Security Requirements Testing Procedures 8-3 E-mail shall not be used for the conveyance of secret or private keys or their components/shares, even if encrypted, unless the key (or component/share) has already been encrypted in accordance with these requirements•i.e., in an SCD. This is due to the existence of these key values in memory just prior to encryption or subsequent to decryption. In addition, corporate e-mail systems allow the recovery by support staff of the clear text of any encrypted …
Modified
p. 146 → 142
9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear- text key component must at all times be either:
9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear-text key component must at all times be either:
Modified
p. 146 → 142
• Sealed in a security container or courier mailer (including pre- numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access would be detected, or
• Sealed in a security container or courier mailer (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access would be detected, or
Modified
p. 147 → 143
9-2.c Verify documented procedures require that any sign of package tampering is identified, reported and ultimately results in the destruction and replacement of both:
9-2.c Verify documented procedures require that any sign of package tampering is identified, reported and if compromise is confirmed ultimately results in the destruction and replacement of both:
Modified
p. 147 → 143
• Any keys encrypted under this (combined) key 9-2.d Interview responsible personnel and observe processes to verify that, if a package shows signs of tampering indicating a component was potentially compromised, processes are implemented to identify the tampering, report/escalate it, and ultimately result in the destruction and replacement of both:
• Any keys encrypted under this (combined) key 9-2.d Interview responsible personnel and observe processes to verify that if a package shows signs of tampering indicating a component was potentially compromised, processes are implemented to identify the tampering, report/escalate it, and ,if compromise is confirmed, ultimately results in the destruction and replacement of both:
Modified
p. 148 → 143
9-2.e Examine records related to any escalated transmittal event. Verify that if compromise is confirmed it resulted in the destruction and replacement of both:
Modified
p. 148 → 144
PIN Security Requirements Testing Procedures 9-3 Only an authorized key custodian⎯and designated backup(s)⎯shall have physical access to a key component prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
Modified
p. 150 → 146
• The components are repackaged at receipt into separate tamper- evident and authenticable packages for storage at the receiving location.
• The components are repackaged at receipt into separate tamper-evident and authenticable packages for storage at the receiving location.
Modified
p. 151 → 147
Note: Entities that are in the process of migrating from older devices to PCI devices approved against version 3 or higher of the PCI POI Security Requirements
•and thus have a mixed portfolio of devices
•they may use RSA key sizes less than 2048 and use SHA-1 to help facilitate the migration. However, in all cases, version 3 or higher devices must implement RSA using key sizes of 2048 or higher and SHA-2 when used for key distribution using asymmetric techniques in …
•and thus have a mixed portfolio of devices
•they
Note: Entities using POI version1 and/or version 2 devices may use RSA key sizes of 1024 and/or SHA-1 if the devices do not support RSA key sizes of 2048 or SHA-2. However, in all cases, version 3 or higher devices must implement RSA using key sizes of 2048 or higher and SHA-2 when used for key distribution using asymmetric techniques in accordance with Annex A.
Modified
p. 155 → 150
12-1 The loading of secret or private keys, when loaded from the individual key components, must be managed using the principles of dual control and split knowledge.
Modified
p. 155 → 150
12-1.c Witness a structured walk-through/demonstration of various key- loading processes for all key types (MFKs, TMKs, PEKs. etc.). Verify the number and length of the key components against information provided through verbal discussion and written documentation.
12-1.c Witness a structured walk-through/demonstration of various key-loading processes for all key types (MFKs, TMKs, PEKs. etc.). Verify the number and length of the key components against information provided through verbal discussion and written documentation.
Modified
p. 155 → 151
Trace historical movement of higher-order keys (MFK, KEK, and BDK) in and out of secure storage to ensure there is no break in the package- number chain that would call into question authorized handling and sufficient storage of the component or share. This must address at a minimum the time frame from the date of the prior audit.
Trace historical movement of higher-order keys (MFK, KEK, and BDK) in and out of secure storage to ensure there is no break in the package-number chain that would call into question authorized handling and sufficient storage of the component or share. This must address at a minimum the time frame from the date of the prior audit.
Modified
p. 155 → 151
12-1.d Verify that the process includes the entry of individual key components by the designated key custodians.
PIN Security Requirements Testing Procedures 12-1.d Verify that the process includes the entry of individual key components by the designated key custodians.
Removed
p. 156
• Separate key-loading devices for each component/share Note that for devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. Each half must be a minimum of five characters.
Note that passwords/authentication codes to the same object may be assigned to a custodian group team⎯e.g., custodian team for component A.
Note: The addition of applications that replace or disable the PCI- evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings.
Note that passwords/authentication codes to the same object may be assigned to a custodian group team⎯e.g., custodian team for component A.
Note: The addition of applications that replace or disable the PCI- evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings.
Modified
p. 156 → 151
12-3 The loading of clear-text cryptographic keys using a key-loading device requires dual control to authorize any key-loading session. It shall not be possible for a single person to use the key-loading device to load clear keys alone.
Modified
p. 156 → 151
• Multiple cryptographic tokens (such as smartcards), or physical
• Multiple cryptographic tokens (such as smartcards), or physical keys,
Modified
p. 156 → 151
12-3.a Identify instances where a key-loading device is used to load clear- text keys. Examine documented procedures for loading of clear-text cryptographic keys, including public keys, to verify:
Note: For devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the 12-3.a Identify instances where a key-loading device is used to load clear-text keys. Examine documented procedures for loading of clear-text cryptographic keys, including public keys, to verify:
Modified
p. 156 → 151
For each types of production SCDs loaded with a key-loading device, observe the processes (e.g., a demonstration) of loading clear-text cryptographic keys and interview personnel. Verify that:
12-3.b For each type of production SCDs loaded with a key-loading device, observe the processes (e.g., a demonstration) of loading clear-text cryptographic keys and interview personnel. Verify that:
Modified
p. 157 → 152
12-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.
12-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.
Modified
p. 157 → 152
12-5 Examine vendor documentation describing options for how the HSM MFK is created and verify the current MFK was created using AES or double- or triple-length TDEA. Corroborate this via observation of processes, with information gathered during the interview process, and procedural documentation provided by the entity under review.
12-5 Examine vendor documentation describing options for how the HSM MFK is created and verify the current MFK was created using AES or double- or triple- length TDEA. Corroborate this via observation of processes, with information gathered during the interview process, and procedural documentation provided by the entity under review.
Modified
p. 157 → 152
12-4 Key components for symmetric keys must be combined using a process such that no active bit of the key can be determined without knowledge of the remaining components. (For example, via XOR‘ing of full-length components.)
Modified
p. 157 → 153
PIN Security Requirements Testing Procedures 12-7 The initial terminal master key (TMK) or initial DUKPT key must be loaded to the device using either asymmetric key-loading techniques or manual techniques•e.g., the device keypad, IC cards, key-loading device, etc. Subsequent loading of the terminal master key may use techniques described in this document such as:
Modified
p. 158 → 153
12-8 If key-establishment protocols using public-key cryptography are used to distribute secret keys, these must meet the requirements detailed in Annex A of this document. For example:
Modified
p. 158 → 153
• A public-key technique for the distribution of symmetric secret keys
• A public-key technique for the distribution of symmetric secret keys must:
Modified
p. 159 → 154
PIN Security Requirements Testing Procedures 12-9 Key-injection facilities must implement dual control and split- knowledge controls for the loading of keys into devices (for example, POIs and other SCDs).
PIN Security Requirements Testing Procedures 12-9 Key-injection facilities must implement dual control and split-knowledge controls for the loading of keys into devices (for example, POIs and other SCDs).
Modified
p. 159 → 154
• Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to key injection such that the badge-access system enforces the presence of at least two authorized individuals at all times in the room so no one person can singly access the key-loading equipment. Access is restricted to only appropriate personnel involved in the key-loading process.
• Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to key injection such that the badge-access system enforces the presence of at least two authorized individuals at all times in the room so no one person can singly access the key-loading equipment. Access is restricted to only appropriate personnel involved in the key-loading process.
Modified
p. 159 → 154
• 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.
• 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.
Modified
p. 159 → 154
• Key-injection platform applications that force the entry of multiple key components and the implementation of procedures that involve multiple key custodians who store and access key components under dual-control and split-knowledge mechanisms.
• Key-injection platform applications that force the entry of multiple key components and the implementation of procedures that involve multiple key custodians who store and access key components under dual- control and split-knowledge mechanisms.
Modified
p. 161 → 156
Note: The addition of applications⎯e.g., component, share, or key- loading applications⎯that replace or disable the PCI evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings.
Note: The addition of applications⎯e.g., component, share, or key-loading applications⎯that replace or disable the PCI evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings.
Modified
p. 161 → 156
13-2.a Examine documentation to verify that only SCDs are used in the loading of clear-text secret or private keys or their components, outside of a secure key-loading facility, as delineated in this Annex. For example, ATM keyboards or keyboards attached to an HSM shall never be used for the loading of clear-text secret or private keys or their components.
13-2.a Examine documentation to verify that only SCDs are used in the loading of clear-text secret or private keys or their components, outside of a secure key- loading facility, as delineated in this Annex. For example, ATM keyboards or keyboards attached to an HSM shall never be used for the loading of clear-text secret or private keys or their components.
Modified
p. 162 → 157
• Instructions for the medium to be placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or
• Instructions 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. 162 → 157
• 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
• 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. 162 → 157
PIN Security Requirements Testing Procedures 13-3 The loading of plaintext secret or private key components or shares from an electronic medium
•e.g., smart card, thumb drive, fob or other devices used for data transport
•directly into a cryptographic device (and verification of the correct receipt of the component, if applicable) results in either of the following:o 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- …
•e.g., smart card, thumb drive, fob or other devices used for data transport
•directly into a cryptographic device (and verification of the correct receipt of the component, if applicable) results in either of the following:
PIN Security Requirements Testing Procedures 13-3 The loading of plaintext secret or private key components or shares from an electronic medium
•e.g., smart card, thumb drive, fob or other devices used for data transport
•directly into 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
•directly into a cryptographic device (and verification of the correct receipt of the component, if applicable) results in either of the following:
Modified
p. 162 → 157
13-4 Examine documented procedures and observe processes for the use of key-loading devices. Perform the following:
13-4 Examine documented procedures and observe processes for the use of key- loading devices. Perform the following:
Modified
p. 163 → 157
13-4.2 The key-loading device must be under the supervision of a person authorized by management or stored in a secure container such that no unauthorized person can have access to it.
Modified
p. 163 → 158
13-4.3.b Verify that both authorized personnel involved in key-loading activity inspect the key-loading device prior to use to ensure that a key- recording device has not been inserted between the SCDs.
13-4.3.b Verify that both authorized personnel involved in key-loading activity inspect the key-loading device prior to use to ensure that a key-recording device has not been inserted between the SCDs.
Modified
p. 163 → 158
13-4.3 The key-loading device must be designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel must ensure that a key-recording device is not inserted between the SCDs.
PIN Security Requirements Testing Procedures 13-4.3 The key-loading device must be designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel must ensure that a key-recording device is not inserted between the SCDs.
Modified
p. 163 → 158
13-4.4 The key-loading device must not retain any information that might disclose the key⎯e.g., allow replay of the key for injection into a non-SCD⎯that was installed in the device or a key that it has successfully transferred.
13-4.4 The key-loading device must not retain any information that might disclose the key⎯e.g., allow replay of the key for injection into a non- SCD⎯that was installed in the device or a key that it has successfully transferred.
Modified
p. 164 → 158
13-5.c Interview designated component holder(s) and examine key-management logs to verify that media or devices removed from secure storage are in the physical possession of only the designated component holder.
Modified
p. 164 → 159
13-7.a Examine documented procedures and confirm that printed/written key-component documents are not opened until immediately prior to use.
13-7.a Examine documented procedures and confirm that printed/written key- component documents are not opened until immediately prior to use.
Modified
p. 164 → 159
13-6 If the component is in human-readable form (e.g., printed within a PIN-mailer type document), it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
PIN Security Requirements Testing Procedures 13-6 If the component is in human-readable form (e.g., printed within a PIN- mailer type document), it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
Modified
p. 165 → 159
13-9 Key-injection facilities that use PC-based key-loading software platforms or similar devices (e.g., modified PEDs) that allow clear-text secret and/or private keys and/or their components to exist in memory outside the secure boundary of an SCD must minimally implement the following additional controls:
Modified
p. 165 → 160
13-9.1 PCs and similar devices must be:
PIN Security Requirements Testing Procedures 13-9.1 PCs and similar devices must be:
Modified
p. 165 → 160
• Located in a physically secure room meeting the criteria of
• Located in a physically secure room meeting the criteria of Requirement 32-9 that is dedicated to key-loading activities.
Modified
p. 165 → 160
Requirement 32-9 that is dedicated to key loading activities 13-9.2 All hardware used in key loading (including the PC) must be managed under dual control. Key-injection must not occur unless there are minimally two individuals in the key-injection room at all times during the process. If a situation arises that would cause only one person to be in the room, all individuals must exit until at least two can be inside.
• Located in a physically secure room meeting the criteria of Requirement 32-9 that is dedicated to key loading activities 13-9.2 All hardware used in key loading (including the PC) must be managed under dual control. Key-injection must not occur unless there are minimally two individuals in the key-injection room at all times during the process. If a situation arises that would cause only one person to be in the room, all individuals must exit until at least two can …
Removed
p. 166
• Retained for a minimum of three years.
• Regularly reviewed by an authorized person who does not have access to the room or to the PC.
• The reviews are documented.
• Regularly reviewed by an authorized person who does not have access to the room or to the PC.
• The reviews are documented.
Modified
p. 166 → 160
13-9.3 PC access and use must be monitored, and logs of all key loading must be maintained. These logs must be retained for a minimum of three years. The logs must be regularly (no less frequently than weekly) reviewed by an authorized person who does not have access to the room or to the PC. The reviews must be documented. The logs must include but not be limited to:
Modified
p. 166 → 160
• Logs of the device IDs and serial numbers that are loaded, along with the date and time and the individuals performing the key- injection;
• Logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key-injection;
Modified
p. 166 → 160
− Access to the room from a badge access system, − Access to the room from a manual sign-in sheet, − User sign-on logs on the PC at the operating system level, − User sign-on logs on the PC at the application level, − Logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key- injection, − Video surveillance logs with a minimum retention period of 45 days.
− Access to the room from a badge access system, − Access to the room from a manual sign-in sheet, − User sign-on logs on the PC at the operating system level, − User sign-on logs on the PC at the application level, − Logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key-injection, − Video surveillance logs with a minimum retention period of 45 days.
Modified
p. 166 → 161
13-9.4 Additionally: 13-9.2 Verify through interviews and observation that:
PIN Security Requirements Testing Procedures 13-9.4 Additionally: 13-9.4 Verify through interviews and observation that:
Modified
p. 167 → 161
13-9.4.3 The software application must load keys without recording any clear-text values on portable media or other unsecured devices.
Modified
p. 167 → 161
13-9.4.5 The personnel responsible for the systems administration of the PC (e.g., a Windows administrator who configures the PC’s user IDs and file settings, etc.) must not have authorized access into the room
•they must be escorted by authorized key-injection personnel
•and they must not have user IDs or passwords/authentication codes to operate thekey-injection application.
•they must be escorted by authorized key-injection personnel
•and they must not have user IDs or passwords/authentication codes to operate the
13-9.4.5 The personnel responsible for the systems administration of the PC (e.g., a Windows administrator who configures the PC’s user IDs and file settings, etc.) must not have authorized access into the room
•they must be escorted by authorized key-injection personnel
•and they must not have user IDs or passwords/authentication codes to operate the key- injection application.
•they must be escorted by authorized key-injection personnel
•and they must not have user IDs or passwords/authentication codes to operate the key- injection application.
Modified
p. 167 → 161
13-9.4.8 Key-injection facilities must cover all openings on the PC that are not used for key-injection with security seals that are tamper-evident and serialized. Examples include but are not limited to PCMCIA, network, infrared and modem connections on the PC, and access to the hard drive and memory. The seals must be recorded in a log, and the log must be maintained along with the other key-loading logs in a dual-control safe. Verification of the seals must be performed prior …
13-9.4.8 Key-injection facilities must cover all openings on the PC that are not used for key-injection with security seals that are tamper-evident and serialized. Examples include but are not limited to PCMCIA, network, infrared and modem connections on the PC, and access to the hard drive and memory. The seals must be recorded in a log, and the log must be maintained along with the other key-loading logs in a dual- control safe. Verification of the seals must be performed …
Modified
p. 167 → 161
13-9.4.8 All openings on the PC that are not used for key-injection are covered with security seals that are tamper-evident and serialized. The seals are recorded in a log, and the log is maintained along with the other key-loading logs in a dual-control safe. Verification of the seals must be performed prior to key-loading activities.
13-9.4.8 All openings on the PC that are not used for key-injection are covered with security seals that are tamper-evident and serialized. The seals are recorded in a log, and the log is maintained along with the other key- loading logs in a dual-control safe. Verification of the seals must be performed prior to key-loading activities.
Modified
p. 168 → 162
PIN Security Requirements Testing Procedures 13-9.4.9 If the PC application stores clear-text key components (e.g., BDKs or TMKs) on portable electronic media (e.g., smart cards), the media must be secured as components under dual control when not in use. The key components must be manually entered at the start of each key-injection session from components that are maintained under dual control and split knowledge.
PIN Security Requirements Testing Procedures 13-9.4.9 If the PC application reads or stores clear-text key components, for example, BDKs or TMKs, from portable electronic media (e.g., smart cards), the media must be secured as components under dual control when not in use. The key components must be manually entered at the start of each key-injection session from components that are maintained under dual control and split knowledge.
Modified
p. 168 → 162
Note: For DUKPT implementations, the BDK should be loaded from components each time and this requires manual tracking of the device ID counter and serial numbers from the previous key-loading session. Key-injection facilities with PC applications that require passwords/authentication codes to be used to initiate decryption of keys on portable electronic media (e.g., smart cards) must ensure the passwords/authentication codes are maintained under dual control and split knowledge.
Note: For DUKPT implementations, the BDK must be loaded from components each time and this requires manual tracking of the device ID counter and serial numbers from the previous key-loading session. Key-injection facilities with PC applications that require passwords/authentication codes to be used to initiate decryption of keys on portable electronic media (e.g., smart cards) must ensure the passwords/authentication codes are maintained under dual control and split knowledge.
Modified
p. 168 → 162
13-9.4.9 If the PC application stores keys (e.g., BDKs or TMKs) on portable electronic media (e.g., smart cards), the media is secured as components under dual control when not in use. The key components are manually entered at the start of each key-injection session from components that are maintained under dual control and split knowledge.
13-9.4.9 If the PC application reads or stores keys (e.g., BDKs or TMKs) from portable electronic media (e.g., smart cards), the media is secured as components under dual control when not in use. The key components are manually entered at the start of each key-injection session from components that are maintained under dual control and split knowledge.
Modified
p. 168 → 162
14-1 Any hardware and passwords/authentication codes used in the key- loading function must be controlled and maintained in a secure environment under dual control. Resources (e.g., passwords/authentication codes and associated hardware must be managed such that no single individual has the capability to enable key loading. This is not to imply that individual access authentication mechanisms must be managed under dual control.
14-1 Any hardware and passwords/authentication codes used in the key- loading function must be controlled and maintained in a secure environment under dual control. Resources (e.g., passwords/authentication codes and associated hardware) must be managed such that no single individual has the capability to enable key loading. This is not to imply that individual access authentication mechanisms must be managed under dual control.
Modified
p. 169 → 163
14-3 Key-loading equipment usage must be monitored, and a log of all key-loading activities maintained for audit purposes containing at a minimum date, time, personnel involved, and number of devices keys are loaded to.
14-3 Key-loading equipment usage must be monitored, and a log of all key- loading activities maintained for audit purposes containing at a minimum date, time, personnel involved, and number of devices keys are loaded to.
Modified
p. 170 → 164
PIN Security Requirements Testing Procedures 14-4 Any physical tokens (e.g., brass keys or chip cards) used to enable key-loading must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control. These tokens must be secured in a manner similar to key components including tamper-evident authenticable packaging and the use of access-control logs for when removed or placed into secure storage.
PIN Security Requirements Testing Procedures 14-4 Any physical tokens (e.g., brass keys or chip cards) used to enable key- loading must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control. These tokens must be secured in a manner similar to key components including tamper-evident authenticable packaging and the use of access-control logs for when removed or placed into secure storage.
Modified
p. 170 → 164
14-5 Default passwords/authentication codes used to enforce dual- control must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change.
14-5 Default passwords/authentication codes used to enforce dual control must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change.
Modified
p. 171 → 165
Note:. Check values may be computed by two methods. TDEA may use either method. AES must only use the CMAC method. In the first method, check values are computed by encrypting an all binary zeros block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). In the second method the KCV is calculated by MACing an all binary zeros block using the …
Modified
p. 171 → 165
15-1.b Observe the key-loading processes to verify that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and are verified by the applicable key custodians.
15-1.b Observe the key-loading processes to verify that the defined cryptographic- based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and are verified by the applicable key custodians.
Modified
p. 172 → 166
16-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for all key- loading operations.
16-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for all key-loading operations.
Modified
p. 173 → 166
18-2.b Interview personnel and observe processes to verify procedures are implemented to require that key-component packaging/containers showing signs of tampering indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, it results in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
Modified
p. 173 → 167
• Implement Key Blocks for internal connections and key storage within Service Provider Environments
• Implement Key Blocks for internal connections and key storage within Service Provider Environments • this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019.
Modified
p. 173 → 167
• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 June 2021.
• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 January 2023.
Modified
p. 173 → 167
18-3 Encrypted symmetric keys must be managed in structures called key blocks. The key usage must be cryptographically bound to the key using accepted methods The phased implementation dates are as follows:
PIN Security Requirements Testing Procedures 18-3 Encrypted symmetric keys must be managed in structures called key blocks. The key usage must be cryptographically bound to the key using accepted methods The phased implementation dates are as follows:
Modified
p. 173 → 167
• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 June 2023.
• Implement Key Block to extend to all merchant hosts, point-of- sale (POS) devices, and ATMs. Effective date: 1 January 2025.
Modified
p. 173 → 167
• A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself⎯e.g. TR-31;
• A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself⎯e.g. TR 31;
Modified
p. 173 → 167
• A digital signature computed over that same data;
• A digital signature computed over that same data e.g., TR-34;
Removed
p. 174
• are implemented to prevent and detect the loading of keys by any one single person.
Modified
p. 174 → 168
PIN Security Requirements Testing Procedures 18-4 Controls must be in place to prevent and detect the loading of unencrypted private and secret keys or their components by any one single person.
PIN Security Requirements Testing Procedures 18-6 Controls must be in place to prevent and detect the loading of unencrypted private and secret keys or their components by any one single person.
Modified
p. 174 → 168
Note: Controls include physical access to the room, logical access to the key-loading application, video surveillance of activities in the key-injection room, physical access to secret or private cryptographic key components or shares, etc.
Note: Controls include physical access to the room, logical access to the key- loading application, video surveillance of activities in the key-injection room, physical access to secret or private cryptographic key components or shares, etc.
Modified
p. 174 → 168
18-6.a Examine documented key-injection procedures to verify that controls are defined to prevent and detect the loading of keys by any one single person.
Modified
p. 174 → 168
•for example, viewing CCTV images
18-6.b Interview responsible personnel and observe key-loading processes and controls to verify that controls
•for example, viewing CCTV images •are implemented to prevent and detect the loading of keys by any one single person.
•for example, viewing CCTV images •are implemented to prevent and detect the loading of keys by any one single person.
Modified
p. 174 → 168
18-7 Key-injection facilities must implement controls to protect against unauthorized substitution of keys and to prevent the operation of devices without legitimate keys.
Modified
p. 174 → 168
18-7.a Examine documented procedures to verify they include:
Modified
p. 174 → 168
18-7.b Interview responsible personnel and observe key-loading processes and controls to verify that:
Modified
p. 174 → 168
• Controls are implemented that protect against unauthorized substitution of keys, and
• Controls are implemented that protect against unauthorized substitution of
Modified
p. 175 → 169
PIN Security Requirements Testing Procedures 19-1 Encryption keys must be used only for the purpose they were intended⎯i.e., key-encryption keys must not to be used as PIN- encryption keys, PIN-encryption keys must not be used for account data, etc. Derivation Keys may be derived into multiple keys, each with its own purpose. For example, a DUKPT Initial Key may be used to derive both a PIN encryption key and a data encryption key. The derivation key would only be used …
PIN Security Requirements Testing Procedures 19-1 Encryption keys must be used only for the purpose they were intended⎯i.e., key-encryption keys must not to be used as PIN-encryption keys, PIN-encryption keys must not be used for account data, etc. Derivation Keys may be derived into multiple keys, each with its own purpose. For example, a DUKPT Initial Key may be used to derive both a PIN encryption key and a data encryption key. The derivation key would only be used for …
Modified
p. 176 → 170
19-5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the key-injection server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these …
19-5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the key- injection server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in …
Modified
p. 176 → 170
Note: This does not apply to HSMs that are never intended to be used for production.
Modified
p. 176 → 170
• Prior to reuse for production purposes the HSM is returned to factory
• Prior to reuse for production purposes the HSM is returned to factory state,
Modified
p. 177 → 171
20-1.a Examine documented procedures for the generation, loading, and usage of all keys used in transaction-originating POI devices. Verify the procedures ensure that all private and secret keys used in transaction- originating POI devices are:
20-1.a Examine documented procedures for the generation, loading, and usage of all keys used in transaction-originating POI devices. Verify the procedures ensure that all private and secret keys used in transaction-originating POI devices are:
Modified
p. 177 → 171
20-2 If a transaction-originating terminal (for example POI device) interfaces with more than one acquiring organization, the transaction- originating terminal SCD must have a completely different and unique key or set of keys for each acquiring organization. These different keys, or sets of keys, must be totally independent and not variants of one another.
20-2 If a transaction-originating terminal (for example POI device) interfaces with more than one acquiring organization, the transaction-originating terminal SCD must have a completely different and unique key or set of keys for each acquiring organization. These different keys, or sets of keys, must be totally independent and not variants of one another.
Modified
p. 178 → 171
20-2b Observe processes for generation and injection of keys into a single POI for more than one acquiring organization, to verify:
Modified
p. 178 → 172
• Unique data is used for the derivation process such that all transaction-originating POIs receive unique secret keys.
• Unique data is used for the derivation process such that all transaction- originating POIs receive unique secret keys.
Modified
p. 178 → 172
20-3 Keys that are generated by a derivation process and derived from the same Base (master) Derivation Key must use unique data for the derivation process as defined in ISO 11568 so that all such cryptographic devices receive unique initial secret keys. Base derivation keys must not ever be loaded onto POI devices•i.e., only the derived key is loaded to the POI device.
PIN Security Requirements Testing Procedures 20-3 Keys that are generated by a derivation process and derived from the same Base (master) Derivation Key must use unique data for the derivation process as defined in ISO 11568 so that all such cryptographic devices receive unique initial secret keys. Base derivation keys must not ever be loaded onto POI devices•i.e., only the derived key is loaded to the POI device.
Modified
p. 179 → 172
20-4 Entities processing or injecting DUKPT or other key-derivation methodologies must incorporate a segmentation strategy in their environments. Segmentation must use one or more of the following techniques:
Modified
p. 179 → 172
• Different BDKs by geographic region, market segment, processing platform, or sales unit Examine documented key-generation and injection procedures to verify that key-injection vendors use at least one unique Base Derivation Key (BDK) per acquiring organization and are able to support segmentation of multiple BDKs of acquiring organizations.
• Different BDKs by geographic region, market segment, processing platform, or sales unit 20-4.b Examine documented key-generation and injection procedures to verify that key-injection vendors use at least one unique Base Derivation Key (BDK) per acquiring organization and are able to support segmentation of multiple BDKs of acquiring organizations.
Modified
p. 179 → 173
20-5 Key-injection facilities that load DUKPT keys for various POI types for the same entity must use separate BDKs per terminal type if the terminal IDs can be duplicated among the multiple types of terminals. In other words, the key-injection facility must ensure that any one given key cannot be derived for multiple devices except by chance.
PIN Security Requirements Testing Procedures 20-5 Key-injection facilities that load DUKPT keys for various POI types for the same entity must use separate BDKs per terminal type if the terminal IDs can be duplicated among the multiple types of terminals. In other words, the key-injection facility must ensure that any one given key cannot be derived for multiple devices except by chance.
Modified
p. 180 → 174
• Encrypted with a key of equal or greater strength as delineated in
• Encrypted with a key of equal or greater strength as delineated in Annex C
Modified
p. 181 → 175
21-3 Key components/shares must be stored as follows: 21-3 Examine documented procedures, interview responsible personnel, and inspect key-component/share storage locations to verify that key components/shares are stored as outlined in Requirements 21-3.1 through 21-3.3 below:
21-3 Key components/shares must be stored as follows: 21-3 Examine documented procedures, interview responsible personnel, and inspect key-component/share storage locations to verify that key components/shares are stored as outlined in Requirements 21-3.1 through 21- 3.3 below:
Modified
p. 182 → 176
Note: Furniture-based locks or containers with a limited set of unique keys •for example, desk drawers
•are not sufficient to meet this requirement.
•are not sufficient to meet this requirement.
Note: Furniture-based locks or containers with a limited set of unique keys
Modified
p. 182 → 176
21-3.1.a Examine key components and storage locations to verify that components are stored in individual opaque, pre-numbered, tamper- evident packaging that prevents the determination of the key component without noticeable damage to the packaging.
21-3.1.a Examine key components and storage locations to verify that components are stored in individual opaque, pre-numbered, tamper-evident packaging that prevents the determination of the key component without noticeable damage to the packaging.
Modified
p. 183 → 177
22-1 Procedures for known or suspected compromised keys must include the following:
PIN Security Requirements Testing Procedures 22-1 Procedures for known or suspected compromised keys must include the following:
Modified
p. 184 → 177
• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key- replacement process.
• Any systems, devices, or processing involving subordinate keys that have been calculated, derived, or otherwise generated, loaded, or protected using the compromised key are included in the key-replacement process.
Modified
p. 184 → 177
22-1.3 A secret or private cryptographic key must be replaced with a new key whenever the compromise of the original key is known. Suspected compromises must be assessed, and the analysis formally documented. If compromise is confirmed, the key must be replaced. In addition, all keys encrypted under or derived using that key must be replaced with a new key within the minimum feasible time. The replacement key must not be a variant or an irreversible transformation of the original …
Modified
p. 184 → 178
22-1.4 A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including:
PIN Security Requirements Testing Procedures 22-1.4 A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including:
Modified
p. 185 → 178
22-1.5 Identification of specific events that would indicate a compromise may have occurred. Such events must include but are not limited to:
Modified
p. 186 → 179
Note: Exposure of keys that are created using reversible transforms of another (key-generation) key can result in the exposure of all keys that have been generated under that key-generation key. To limit this risk posed by reversible key calculation, such as key variants, the reversible transforms of a key must be secured in the same way as the original key- generation key.
Note: Exposure of keys that are created using reversible transforms of another (key-generation) key can result in the exposure of all keys that have been generated under that key-generation key. To limit this risk posed by reversible key calculation, such as key variants, the reversible transforms of a key must be secured in the same way as the original key-generation key.
Modified
p. 186 → 179
23-1.a Examine documented procedures and interview responsible personnel to determine whether keys are generated using reversible key- calculation methods.
23-1.a Examine documented procedures and interview responsible personnel to determine whether keys are generated using reversible key-calculation methods.
Modified
p. 187 → 180
• Variants used as KEKs must only be calculated from other key- encrypting keys.
• Variants used as KEKs must only be calculated from other key-encrypting keys.
Modified
p. 187 → 180
Note: Using transformations of keys across different levels of a key hierarchy •for example, generating a PEK key from a key-encrypting key
Note: Using transformations of keys across different levels of a key hierarchy
Modified
p. 187 → 180
• increases the risk of exposure of each of those keys.
• for example, generating a PEK key from a key-encrypting key
•increases the risk of exposure of each of those keys.
•increases the risk of exposure of each of those keys.
Removed
p. 188
• physically secured, enciphered, or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
Modified
p. 188 → 181
24-2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media types in all permissible forms
24-2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media types in all permissible forms •physically secured, enciphered, or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
Modified
p. 189 → 181
24-2.2 The key-destruction process must be observed by a third party other than the custodians of any component of that key. I.e., the third party must not be a key custodian for any part of the key being destroyed.
Modified
p. 189 → 181
The third-party witness must sign an affidavit of destruction.
The third-party witness must sign an affidavit of destruction and this affidavit is retained for a minimum of two years.
Modified
p. 189 → 182
Requirement 25: Access to secret and private cryptographic keys and key material must be: a. Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use; and b. Protected such that no other person (not similarly entrusted with that component) can observe or otherwise obtain the component.
Requirement 25: Access to secret and private cryptographic keys and key material must be:
Modified
p. 189 → 182
25-1 To reduce the opportunity for key compromise, limit the number of key custodians to the minimum required for operational efficiency.
25-1 To reduce the opportunity for key compromise, limit the number of key custodians to the minimum required for operational efficiency. Controls include:
Modified
p. 189 → 182
24-2.3 Key components for keys other than the HSM or KLD MFKs that have been successfully loaded and confirmed as operational must also be destroyed, unless the HSM does not store the encrypted values on a database but only stores the subordinate keys internal to the HSM. BDKs used in KLDs may also be stored as components where necessary to reload the KLD.
PIN Security Requirements Testing Procedures 24-2.3 Key components for keys other than the HSM or KLD MFKs that have been successfully loaded and confirmed as operational must also be destroyed, unless the HSM does not store the encrypted values on a database but only stores the subordinate keys internal to the HSM. BDKs used in KLDs may also be stored as components where necessary to reload the KLD.
Modified
p. 189 → 182
• Assigned key custodians are employees or contracted personnel
• Assigned key custodians are employees or contracted personnel 25-1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.
Modified
p. 191 → 183
For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual. The components collectively held by an individual and his or her direct reports shall not constitute a quorum (or …
For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual.
Modified
p. 192 → 184
• Loaded to an SCD 26-1.b Examine log files and audit log settings to verify that logs include the following:
• Securely stored 26-1.c Examine log files and audit log settings to verify that logs include the following:
Modified
p. 195 → 187
29-1.1 All POIs must be protected against compromise. Any compromise must be detected. Loading and use of any financial keys after the compromise must be prevented.
29-1.1 All POIs and other SCDs must be protected against compromise. Any compromise must be detected. Loading and use of any financial keys after the compromise must be prevented.
Removed
p. 196
PIN Security Requirements Testing Procedures The minimum log contents include date and time, object name/identifier, purpose, name of individual(s) involved, signature or electronic capture (e.g., badge) of individual involved and if applicable, tamper-evident package number(s) and serial number(s) of device(s) involved. Electronic logging⎯e.g., using bar codes⎯is acceptable for device tracking.
Modified
p. 196 → 188
29-1.1.2.a Examine documented authorizations for personnel with access to devices to verify that prior to deployment:
Modified
p. 196 → 188
29-1.1.2.b For a sample of POIs and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in an auditable manner have access to devices.
Modified
p. 196 → 188
PIN Security Requirements Testing Procedures 29-1.1.2 All personnel with access to POIs and other SCDs prior to deployment are documented in a formal list and authorized by management. A documented security policy must exist that requires the specification of personnel with authorized access to all secure cryptographic devices. This includes documentation of all personnel with access to POIs and other SCDs as authorized by management. The list of authorized personnel is reviewed at least annually.
Modified
p. 197 → 189
• Can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.
Modified
p. 197 → 189
(continued on next page) 29-3.a Examine documented procedures to confirm that they require physical protection of devices from the manufacturer’s facility up to the point of key-insertion and deployment, through one or more of the defined methods.
(continued on next page) 29-3.a Examine documented procedures to confirm that they require physical protection of devices from the manufacturer’s facility up to the point of key- insertion and deployment, through one or more of the defined methods.
Removed
p. 198
• throughout their life cycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs but must not supplant the implementation of dual-control mechanisms.
Modified
p. 198 → 190
29-4 Dual-control mechanisms must exist to prevent substitution or tampering of HSMs
•both deployed and spare or back-up devices
•both deployed and spare or back-up devices
29-4 Dual-control mechanisms must exist to prevent substitution or tampering of HSMs
•both deployed and spare or back-up devices •throughout their life cycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs but must not supplant the implementation of dual-control mechanisms.
•both deployed and spare or back-up devices •throughout their life cycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs but must not supplant the implementation of dual-control mechanisms.
Modified
p. 199 → 191
29-4.2.f Examine documentation to verify:
Modified
p. 199 → 191
For example, for HSMs used in transaction processing operations:
• PIN-block format translation functionality is in accordance with
• PIN-block format translation functionality is in accordance with
For example, for HSMs used in transaction processing operations:
• PIN-block format translation functionality is in accordance with Requirement 3, or non-ISO PIN-block formats must not be supported without a defined documented and approved business need.
• PIN-block format translation functionality is in accordance with Requirement 3, or non-ISO PIN-block formats must not be supported without a defined documented and approved business need.
Modified
p. 199 → 191
Documentation (e.g., a checklist or similar suitable to use as a log) of configuration settings must exist and be signed and dated by personnel responsible for the implementation. This documentation must include identifying information for the HSM, such as serial number and/or asset identifiers. This documentation must be retained and updated for each affected HSM any time changes to configuration settings would impact security.
Modified
p. 199 → 191
29-4.2.e Verify that functionality is not enabled to allow the outputting of clear-text PINs.
29-4.2.e Verify that functionality is not enabled to allow the outputting of clear- text PINs.
Modified
p. 200 → 192
29-4.4.3 Physical and/or functional tests and visual inspection to confirm that physical and logical controls and anti-tamper mechanisms are not modified or removed 29-4.4.3 Observe inspection processes and interview responsible personnel to confirm processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti- tamper mechanisms are not modified or removed.
29-4.4.3 Physical and/or functional tests and visual inspection to confirm that physical and logical controls and anti-tamper mechanisms are not modified or removed 29-4.4.3 Observe inspection processes and interview responsible personnel to confirm processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not modified or removed.
Modified
p. 203 → 195
31-1.6 Records of the tests and inspections maintained for at least one year.
31-1.6 Records of the tests and inspections maintained for at least one year. 31-1.6 Interview personnel and observe records to verify that records of the tests and inspections are maintained for at least one year.
Modified
p. 203 → 195
Requirement 32: Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following: a. Dual access controls required to enable the key-encryption function b. Physical protection of the equipment (e.g., locked access to it) under dual control c. Restriction of logical access to the equipment Key-injection …
Requirement 32: Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following:
Modified
p. 204 → 196
• To enable any manual key-encryption functions and any key- encryption functions that occur outside of normal transaction processing;
• To enable any manual key-encryption functions and any key-encryption functions that occur outside of normal transaction processing;
Modified
p. 204 → 196
• To place the device into a state that allows for the input or output of clear-text key components;
• To place the device into a state that allows for the input or output of clear- text key components;
Modified
p. 204 → 196
• To enable any manual key-encryption functions, and any key- encryption functions that occur outside of normal transaction processing;
• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;
Modified
p. 205 → 196
32-1.4 Devices must not use default passwords/authentication codes.
Modified
p. 205 → 197
32-1.5 To detect any unauthorized use, devices are at all times within a secure room and either:
PIN Security Requirements Testing Procedures 32-1.5 To detect any unauthorized use, devices are at all times within a secure room and either:
Modified
p. 205 → 197
• Locked in a secure cabinet and/or sealed in tamper-evident packaging,
• Locked in a secure cabinet and/or sealed in tamper-evident packaging, or
Modified
p. 205 → 197
32-1.5.a Examine documented procedures to confirm that they require devices are either:
32-1.5.a Examine documented procedures to confirm that the documented procedures require devices are within a secure room and either:
Modified
p. 206 → 197
32-8.1 The KIF must ensure that keys are transmitted between KIF components in accordance with Control Objective 3.
Modified
p. 206 → 198
32-8.3 The KIF must ensure that injection of enciphered secret or private keys into POI devices meets the requirements of Control Objective 4.
PIN Security Requirements Testing Procedures 32-8.3 The KIF must ensure that injection of enciphered secret or private keys into POI devices meets the requirements of Control Objective 4.
Modified
p. 206 → 198
32-8.4.b Interview responsible personnel and observe key-loading processes to verify that the documented procedures are followed for key conveyance or transmittal for keys used between KIF components.
Modified
p. 206 → 198
32-8.5 Examine documented procedures to confirm they specify the establishment of a mutually authenticated channel for establishment of enciphered secret or private keys between sending and receiving devices•e.g., POI devices and HSMs.
32-8.5 Examine documented procedures to confirm they specify the establishment of a mutually authenticated channel for establishment of enciphered secret or private keys between sending and receiving devices• e.g., POI devices and HSMs.
Modified
p. 207 → 198
32-8.6 Mutual authentication of the sending and receiving devices must be performed.
Modified
p. 208 → 199
• Effective 1 January 2021 the injection of clear-text secret or private keying material shall not be allowed for entities engaged in key injection on behalf of others. Only encrypted key injection shall be allowed for POI v3 and higher devices.
• Effective 1 January 2024, the injection of clear-text secret or private keying material shall not be allowed for entities engaged in key injection on behalf of others. This applies to new deployments of POI v5 and higher devices. Subsequent to that date, only encrypted key injection shall be allowed for POI v5 and higher devices.
Modified
p. 208 → 199
• Effective 1 January 2023, the same restriction applies to entities engaged in key injection of devices for which they are the processors.
• Effective 1 January 2026, the same restriction applies to entities engaged in key injection of devices for which they are the processors.
Modified
p. 208 → 199
Note: This does not apply to key components entered into the keypad of a secure cryptographic device, such as a device approved against the PCI PTS POI Security Requirements. It does apply to all other methods of loading of clear-text keying material for POI v3 and higher devices.
Note: This does not apply to key components entered into the keypad of a secure cryptographic device, such as a device approved against the PCI PTS POI Security Requirements. It does apply to all other methods of loading of clear-text keying material for POI v5 and higher devices.
Modified
p. 208 → 199
Note: In KIF environments where Level 1 and Level 2 physical barrier controls are in place and confirmed, the secure room may be implemented within a “caged” environment. A caged environment is an enclosed secure room that meets the criteria of Requirement 32 but is not made of solid walls. Refer to Normative Annex A: A2 for additional information on Level 1 and Level 2 physical barrier controls. All other criteria stated in Requirements 13-9 and 32-10 relating to clear-text …
Note: In KIF environments where Level 1 and Level 2 physical barrier controls are in place and confirmed, the secure room may be implemented within a “caged” environment. A caged environment is an enclosed secure room that meets the criteria of Requirement 32 but is not made of solid walls. Refer to Normative Annex A: A2 for additional information on Level 1 and Level 2 physical barrier controls. All other criteria stated in Requirements 13-9 and 32-9 relating to clear-text …
Modified
p. 209 → 199
32-9.2.b Examine configuration of window sensors to verify that the alarm mechanism is active.
Modified
p. 209 → 200
32-9.3 Any windows must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
PIN Security Requirements Testing Procedures 32-9.3 Any windows must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
Modified
p. 209 → 200
• Dual-access for entry to the secure room
• Dual access for entry to the secure room
Modified
p. 209 → 200
32-9.7 Inspect CCTV configuration and examine a sample of recordings to verify that CCTV monitoring is in place on a 24/7 basis.
32-9.7 Inspect CCTV configuration and examine a sample of recordings to verify that CCTV monitoring is in place on a 24/7 basis, including the ability to record events during dark periods, and if motion activated verify that recording continues for at least a minute after the last pixel of activity subsides.
Modified
p. 210 → 200
32-9.9 The CCTV server and digital storage must be secured in a separate secure location that is not accessible to personnel who have access to the key- injection secure room.
Modified
p. 210 → 200
32-9.9.a Inspect location of the CCTV server and digital-storage to verify they are located in a secure location that is separate from the key- injection secure room.
32-9.9.a Inspect location of the CCTV server and digital-storage to verify they are located in a secure location that is separate from the key-injection secure room.
Modified
p. 210 → 201
32-9.10 The CCTV cameras must be positioned to monitor:
PIN Security Requirements Testing Procedures 32-9.10 The CCTV cameras must be positioned to monitor:
Removed
p. 212
The following table, which is consistent with NIST SP 800-57 Part 1, Table 2, and with ISO TR-14742, lists the cryptographic strength of the most common key lengths for the relevant symmetric and asymmetric cryptographic algorithms. The RSA key size below refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. The DSA key sizes refer to the size of the modulus and the minimum size of a large subgroup.
Bits of security Symmetric encryption algorithms RSA Elliptic Curve 80 Double-length TDEA (§) 1024 160 1024/160 112 Double-length TDEA (§) Triple-length TDEA 2048 224 2048/224 128 AES-128 3072 256 3072/256 192 AES-192 7680 384 7680/384 256 AES-256 15360 512 15360/512 1 The requirement for longer DH, ECDH, ECC, and DSA keys reflects an industry transition to …
Bits of security Symmetric encryption algorithms RSA Elliptic Curve 80 Double-length TDEA (§) 1024 160 1024/160 112 Double-length TDEA (§) Triple-length TDEA 2048 224 2048/224 128 AES-128 3072 256 3072/256 192 AES-192 7680 384 7680/384 256 AES-256 15360 512 15360/512 1 The requirement for longer DH, ECDH, ECC, and DSA keys reflects an industry transition to …
Removed
p. 213
In general, the weakest algorithm and key size used to provide cryptographic protection determines the strength of the protection. For example, if a 2048-bit RSA key is used to encipher an AES-128 key, henceforth that AES key will only have 112-bit strength, not 128-bit. Intuitively this is because once you break the key-encryption key, you have access to the encrypted key. The strength hence reflects the expected amount of effort an attacker needs to spend in order to discover the key.
This applies to any key-encipherment keys used for the protection of secret or private keys that are stored, or for keys used to encrypt any secret or private keys for loading or transport.
This applies to any key-encipherment keys used for the protection of secret or private keys that are stored, or for keys used to encrypt any secret or private keys for loading or transport.
Modified
p. 213 → 205
For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH):
For implementations using FFC or ECC:
Modified
p. 213 → 205
• FFC implementations entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity must generate a private key x and a public key y using the domain parameters (p, q, g).
Modified
p. 213 → 205
• ECC implementations entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (see FIPS 186-4). The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entity must generate a private key d and a public key Q using the specified elliptic curve domain parameters. (See FIPS 186-4 for methods of generating d and Q.)
Modified
p. 213 → 205
• Each private key must be statistically unique, unpredictable and created using an approved random number generator as described in this document.
Modified
p. 213 → 205
• Requirements for message authentication using symmetric techniques. One of the following should be used: MAC algorithm 1 using padding method 3, MAC algorithm 5 using padding method 4).
Modified
p. 215 → 208
Check value A computed value that is the result of passing a data value through a non-reversible algorithm; a value used to identify a key without revealing any bits of the actual key itself. Check values are computed by encrypting an all-zero block using the key or component as the encryption key, using the leftmost n-bits of the result⎯where n is at most 24 bits (6 hexadecimal digits/3 bytes). This method may be used for TDEA. TDEA may optionally use, …
Check value A computed value that is the result of passing a data value through a non-reversible algorithm; a value used to identify a key without revealing any bits of the actual key itself. Check values may be computed by two methods. TDEA may use either method. AES must only use the CMAC method. In the first method, check values are computed by encrypting an all binary zeros block using the key or component as the encryption key, using the …
Modified
p. 216 → 209
Cryptographic key A parameter used in conjunction with a cryptographic algorithm that determines:
Cryptographic key A parameter used in conjunction with a cryptographic algorithm that is used for operations such as:
Modified
p. 218 → 211
DUKPT (Derived Unique Key Per Transaction) A key-management method that uses a unique key for each transaction and prevents the disclosure of any past key used by the transaction-originating TRSM. The unique transaction keys are derived from a Base Derivation Key using only non-secret data transmitted as part of each transaction.
DUKPT (Derived Unique Key Per Transaction) A key-management method that uses a unique key for each transaction and prevents the disclosure of any past key used by the transaction-originating POI device. The unique transaction keys are derived from a Base Derivation Key using only non-secret data transmitted as part of each transaction.
Modified
p. 220 → 213
• It is computationally infeasible to find any input that maps to any pre-specified output.
1. One-Way
• It is computationally infeasible to find any input that maps to any pre-specified output.
• It is computationally infeasible to find any input that maps to any pre-specified output.
Modified
p. 220 → 213
• It is computationally infeasible to find any two distinct inputs (e.g., messages) that map to the same output.
2. Collision Resistant
• It is computationally infeasible to find any two distinct inputs (e.g., messages) that map to the same output.
• It is computationally infeasible to find any two distinct inputs (e.g., messages) that map to the same output.
Modified
p. 225 → 218
Point of interaction (POI) An electronic-transaction-acceptance product. A POI consists of hardware and software and is hosted in acceptance equipment to enable a cardholder to perform a card transaction. Thereby the POI may be attended or unattended. POI transactions include IC, magnetic-stripe, and contactless payment-card-based payment transactions.
Point of interaction (POI) An electronic-transaction-acceptance product. A POI consists of hardware and software and is hosted in acceptance equipment to enable a cardholder to perform a card transaction. Thereby the POI may be attended or unattended. POI transactions include Integrated Circuit (IC) and magnetic-stripe contact cards, and contactless payment-card-based payment transactions.
Modified
p. 225 → 218
Private key A cryptographic key, used with a public-key cryptographic algorithm that is uniquely associated with an entity and is not made public.
Private key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and is not made public.
Modified
p. 226 → 219
The signature and the decipherment transformation are kept private by the owning entity, whereas the corresponding verification and encipherment transformations are published. There exist asymmetric crypto- systems (e.g., RSA) where the four elementary functions may be achieved by only two transformations: one private transformation suffices for both signing and decrypting messages, and one public transformation suffices for both verifying and encrypting messages. However, this does not conform to the principle of key separation, and where used, the four elementary transformations …