Document Comparison
PCI_PIN_Security_v2_audit_techniques_Dec_2014_d.pdf
→
PCI_PIN_Security_Requirements_Testing_v3_Aug2018.pdf
72% similar
192 → 237
Pages
78200 → 90390
Words
1206
Content Changes
Content Changes
1206 content changes. 127 administrative changes (dates, page numbers) hidden.
Added
p. 5
The individual payment brands are responsible for defining and managing compliance programs associated with these requirements. Contact the payment brand(s) of interest for any additional criteria.
Entities may be subject to requirements in multiple sections as delineated below, depending on the activities performed.
Transaction Processing Operations For specific requirements pertaining to the acquiring and related processing of PIN-based transactions, see the section on Transaction Processing Operations.
A summary listing of these keys:
• Must include the name/usage e.g.:
− TMK: Terminal Master Key − POI key-encipherment key; − PEK: POI PIN-encipherment key; − MFK: HSM Master File Key; − KEK-A: Zone key-encipherment key shared with organization A; − ZPK: Zone PIN Key-A
• PIN-encipherment key shared with organization A; − Etc.
• Must also include keys such as any asymmetric key pairs used for remote key-establishment and distribution as delineated in Annex A, and other keys used in the message flow such as MAC and keys associated …
Entities may be subject to requirements in multiple sections as delineated below, depending on the activities performed.
Transaction Processing Operations For specific requirements pertaining to the acquiring and related processing of PIN-based transactions, see the section on Transaction Processing Operations.
A summary listing of these keys:
• Must include the name/usage e.g.:
− TMK: Terminal Master Key − POI key-encipherment key; − PEK: POI PIN-encipherment key; − MFK: HSM Master File Key; − KEK-A: Zone key-encipherment key shared with organization A; − ZPK: Zone PIN Key-A
• PIN-encipherment key shared with organization A; − Etc.
• Must also include keys such as any asymmetric key pairs used for remote key-establishment and distribution as delineated in Annex A, and other keys used in the message flow such as MAC and keys associated …
Added
p. 7
• When used in connection with vendor-operated PKIs used for remote key loading using asymmetric techniques. This applies specifically to the distribution of acquirer keys to transaction-originating devices (POIs) for use in connection with PIN and account-data encryption, whether the actual distribution of acquirer keys occurs from the transaction-processing host or is distributed directly by the vendor. This includes:
− Root and Subordinate Certification Authority keys and keys used in connection with associated Registration Authority activities − Device-specific key pairs used for that purpose − Keys associated with protection of the aforementioned keys during storing, loading, and usage − The generation of the aforementioned keys
• When used in connection with KIF activities for loading and/or distribution of acquirer keys to transaction-originating devices (POIs) for use in connection with PIN and account-data encryption.
• When used for the protection of PIN and account data when conveyed between non-integrated components of a POI device
•e.g., …
− Root and Subordinate Certification Authority keys and keys used in connection with associated Registration Authority activities − Device-specific key pairs used for that purpose − Keys associated with protection of the aforementioned keys during storing, loading, and usage − The generation of the aforementioned keys
• When used in connection with KIF activities for loading and/or distribution of acquirer keys to transaction-originating devices (POIs) for use in connection with PIN and account-data encryption.
• When used for the protection of PIN and account data when conveyed between non-integrated components of a POI device
•e.g., …
Added
p. 8
• Compliance with a specific SCD standard
• The types of devices
• The time windows for the deployment (and removal) of such devices
• Sunset (retirement) dates for specific models or SCD standards The lists of device models compliant with a version of the PCI PTS standard can be found at www.pcisecuritystandards.org under “Assessors and Solutions”
• 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.
• The types of devices
• The time windows for the deployment (and removal) of such devices
• Sunset (retirement) dates for specific models or SCD standards The lists of device models compliant with a version of the PCI PTS standard can be found at www.pcisecuritystandards.org under “Assessors and Solutions”
• 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.
Added
p. 12
• 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
• The company name (vendor) of the device model
• The device model name
• The PCI PTS Approval Number The POI device information must include the following summary information
• List of models used
• Total number of devices, broken down by model.
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.
1-1 Testing Procedures applicable to POI devices (PCI PTS standards):
• The company name (vendor) of the device model
• The device model name
• The PCI PTS Approval Number The POI device information must include the following summary information
• List of models used
• Total number of devices, broken down by model.
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.
1-1 Testing Procedures applicable to POI devices (PCI PTS standards):
Added
p. 13
1-1.e Using the sample above, identify all other software (applications) on the device and that software’s functionality and verify that the software does not replace or disable the PCI-evaluated firmware functionality unless that software is also validated and PCI approved as shown on the PCI website.
Note: The entity acquiring PIN-based transactions is responsible for identifying all software on the device that has been added subsequent to the device’s approval. Any such software should be developed in accordance with the device vendor’s security guidance, which stipulates what is and is not allowed⎯e.g., replacing the device’s PCI evaluated IP stack with an IP stack bundled with the add-on application would invalidate the approval. See PTS POI Technical Frequently Asked Questions, General FAQ #42, for additional information.
• Model name and number
• The PCI PTS HSM or FIPS 140 approval number
• The PCI PTS HSM number
• Any applications, including application version number, resident within …
Note: The entity acquiring PIN-based transactions is responsible for identifying all software on the device that has been added subsequent to the device’s approval. Any such software should be developed in accordance with the device vendor’s security guidance, which stipulates what is and is not allowed⎯e.g., replacing the device’s PCI evaluated IP stack with an IP stack bundled with the add-on application would invalidate the approval. See PTS POI Technical Frequently Asked Questions, General FAQ #42, for additional information.
• Model name and number
• The PCI PTS HSM or FIPS 140 approval number
• The PCI PTS HSM number
• Any applications, including application version number, resident within …
Added
p. 19
Translation 3-3.b Where translated to format 2, verify that the PIN block is only submitted to the IC card.
Note: For offline PIN this is verified for PCI-approved POI devices:
a) The PIN that is submitted by the ICC reader to the IC shall be contained in a PIN block conforming to ISO format 2 PIN block. This applies whether the PIN is submitted in plaintext or enciphered using an encipherment key of the IC.
b) Where the ICC reader is not integrated into the PIN entry device and PINs are enciphered only for transmission between the PIN entry device and the ICC reader, the device shall use one of the PIN-block formats specified in ISO 9564-1. Where ISO format 2 PIN blocks are used, a unique-key-per-transaction method in accordance with ISO 11568 shall be used.
To → From ISO Format ISO Format ISO Format ISO Format 0, 3, 4 − Permitted anywhere …
Note: For offline PIN this is verified for PCI-approved POI devices:
a) The PIN that is submitted by the ICC reader to the IC shall be contained in a PIN block conforming to ISO format 2 PIN block. This applies whether the PIN is submitted in plaintext or enciphered using an encipherment key of the IC.
b) Where the ICC reader is not integrated into the PIN entry device and PINs are enciphered only for transmission between the PIN entry device and the ICC reader, the device shall use one of the PIN-block formats specified in ISO 9564-1. Where ISO format 2 PIN blocks are used, a unique-key-per-transaction method in accordance with ISO 11568 shall be used.
To → From ISO Format ISO Format ISO Format ISO Format 0, 3, 4 − Permitted anywhere …
Added
p. 21
• An approved key-generation function of a PCI
•approved HSM or
• An approved key-generation function of a PCI-approved HSM or
6-1.1 Any clear-text output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the clear text of any key component/share. Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.
• Any key-generation process with clear-text output is performed under dual control
•approved HSM or
• An approved key-generation function of a PCI-approved HSM or
6-1.1 Any clear-text output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the clear text of any key component/share. Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.
• Any key-generation process with clear-text output is performed under dual control
Added
p. 22
Note: Key shares derived using a recognized secret-sharing algorithm or full-length key components are not considered key parts and do not provide any information regarding the actual cryptographic key.
• The documented procedures were followed, and
• At least two individuals performed the key-generation processes.
• If the device used for key generation is logically partitioned for concurrent use in other processes, the key-generation capabilities are enabled for execution of the procedure and disabled when the procedure is complete.
Note: This does not apply to logically partitioned devices located in data centers that are concurrently used for other purposes, such as transaction processing.
6-1.4.a Examine documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering prior to use. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
6-1.5.b During the demonstration …
• The documented procedures were followed, and
• At least two individuals performed the key-generation processes.
• If the device used for key generation is logically partitioned for concurrent use in other processes, the key-generation capabilities are enabled for execution of the procedure and disabled when the procedure is complete.
Note: This does not apply to logically partitioned devices located in data centers that are concurrently used for other purposes, such as transaction processing.
6-1.4.a Examine documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering prior to use. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
6-1.5.b During the demonstration …
Added
p. 27
6-6 Policy and procedures must exist to ensure that clear-text private or secret keys or their components/shares are not transmitted across insecure channels. Preclusions include but are not limited to:
Added
p. 27
• Faxing, e-mailing, or otherwise electronically conveying clear-text secret or private keys or components
Added
p. 27
• Affixing (e.g., taping) key or component values to or inside devices
• Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that they include language that prohibits transmitting clear-text private or secret keys or their components/shares across insecure channels, including but not limited to:
• Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that they include language that prohibits transmitting clear-text private or secret keys or their components/shares across insecure channels, including but not limited to:
Added
p. 28
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
It is the responsibility of both the sending and receiving parties to ensure these keys are managed securely during transport.
• Where key components are transmitted in clear-text using pre- numbered, tamper-evident, authenticable mailers:
− Details of the serial number of the package are conveyed separately from the package itself.
• Examine documented procedures for sending components in tamper- evident, authenticable packaging to verify that:
− They define how the details of the package serial number are to be transmitted.
− There is a requirement that the package serial number is to be sent separately from the package itself.
− Each component is to be sent to/from only the custodian(s) authorized for the component.
− At least two communication channels are used to send the components of a given key (not just separation by sending on different days).
− Prior to the use of …
It is the responsibility of both the sending and receiving parties to ensure these keys are managed securely during transport.
• Where key components are transmitted in clear-text using pre- numbered, tamper-evident, authenticable mailers:
− Details of the serial number of the package are conveyed separately from the package itself.
• Examine documented procedures for sending components in tamper- evident, authenticable packaging to verify that:
− They define how the details of the package serial number are to be transmitted.
− There is a requirement that the package serial number is to be sent separately from the package itself.
− Each component is to be sent to/from only the custodian(s) authorized for the component.
− At least two communication channels are used to send the components of a given key (not just separation by sending on different days).
− Prior to the use of …
Added
p. 35
Self-signed root certificates protect the integrity of the data within the certificate but do not guarantee the authenticity of the data. The authenticity of the root certificate is based on the use of secure procedures to distribute them. Specifically, they must be directly installed into the PIN pad of the ATM or POS device and not remotely loaded to the device subsequent to manufacture.
• Use of public-key certificates created by a trusted CA that meets the requirements of Annex A
• Validation of a hash of the public key sent by a separate channel (for example, mail)
• Using a MAC (message authentication code) created using the algorithm defined in ISO 16609
• Encrypted 8-4.b Validate that procedures dictate that self-signed certificates must not be used as the sole method of authentication.
• Use of public-key certificates created by a trusted CA that meets the requirements of Annex A
• Validation of a hash of the public key sent by a separate channel (for example, mail)
• Using a MAC (message authentication code) created using the algorithm defined in ISO 16609
• Encrypted 8-4.b Validate that procedures dictate that self-signed certificates must not be used as the sole method of authentication.
Added
p. 36
These requirements also apply to keys moved between locations of the same organization.
Added
p. 36
• 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
Added
p. 36
• 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
• 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
Added
p. 37
• Any keys encrypted under this (combined) key.
9-2.e Examine records related to any escalated transmittal events. Verify that it resulted in the destruction and replacement of both:
• Any keys encrypted under this (combined) key 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.
9-3.a Verify the existence of a list(s) of key custodians⎯and designated backup(s)⎯authorized to have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
PIN Security Requirements Testing Procedures 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.
Note: See Requirement 26 …
9-2.e Examine records related to any escalated transmittal events. Verify that it resulted in the destruction and replacement of both:
• Any keys encrypted under this (combined) key 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.
9-3.a Verify the existence of a list(s) of key custodians⎯and designated backup(s)⎯authorized to have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
PIN Security Requirements Testing Procedures 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.
Note: See Requirement 26 …
Added
p. 39
9-6.a If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that:
• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or within PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened.
• Records reflect the receipt of the shipped bag and association with subsequent individual bags 9-6.b Examine logs to verify that procedures are followed.
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).
− TDEA …
• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or within PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened.
• Records reflect the receipt of the shipped bag and association with subsequent individual bags 9-6.b Examine logs to verify that procedures are followed.
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).
− TDEA …
Added
p. 45
• Two or more passwords/authentication codes of five characters or more (vendor default values must be changed)
• Multiple cryptographic tokens (such as smartcards), or physical keys
• Physical access controls
• 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. If modified PEDs are not validated and approved …
• Multiple cryptographic tokens (such as smartcards), or physical keys
• Physical access controls
• 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. If modified PEDs are not validated and approved …
Added
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 check value will be the leftmost n-bits of the result, where n is at most 40 bits (10 hexadecimal digits). The block cipher used in the CMAC function is the same as the block cipher of the key itself. A TDEA key or a component of a TDEA key will be MACed using the TDEA block cipher, while a 128-bit AES key or component will be MACed using the AES-128 …
Added
p. 62
• Different BDKs by geographic region, market segment, processing platform, or sales unit 20-4 Examine documented key-generation and injection procedures to verify that entities processing or injecting DUKPT or other key-derivation methodologies incorporate a segmentation strategy in their environments using one or more of the following techniques:
• Different BDKs by geographic region, market segment, processing platform, or sales unit
• Different BDKs by geographic region, market segment, processing platform, or sales unit
Added
p. 67
• Identification of key personnel
• A damage assessment including, where necessary, the engagement of outside consultants
• Missing secure cryptographic devices
• A damage assessment including, where necessary, the engagement of outside consultants
• Missing secure cryptographic devices
Added
p. 67
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 22-1.5 Interview responsible personnel and examine documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
Added
p. 70
PIN Security Requirements Testing Procedures 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.
Added
p. 71
• Signature of management authorizing the access 25-1.3 Examine all key-custodian forms to verify that they include the following:
• Signature of management authorizing the access
Custodians must not become a custodian for a component/share of a key where the custodian has previously been or is currently a custodian for another component/share of that key if that would collectively constitute a quorum to form the actual key.
• Key custodians are not and have not been a custodian for another component/share of a key where that collectively would constitute a quorum to form the actual key.
• Signature of management authorizing the access
Custodians must not become a custodian for a component/share of a key where the custodian has previously been or is currently a custodian for another component/share of that key if that would collectively constitute a quorum to form the actual key.
• Key custodians are not and have not been a custodian for another component/share of a key where that collectively would constitute a quorum to form the actual key.
Added
p. 73
• Tamper-evident and authenticable package number (if applicable) 26-1.a Examine log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:
• Removed from secure storage
• Tamper-evident and authenticable package number (if applicable)
− Securely stored with proper access controls − Under at least dual control − Subject to at least the same level of security control as operational keys as specified in this document 27-2 If backup copies are created, the following must be in place:
• Removed from secure storage
• Tamper-evident and authenticable package number (if applicable)
− Securely stored with proper access controls − Under at least dual control − Subject to at least the same level of security control as operational keys as specified in this document 27-2 If backup copies are created, the following must be in place:
Added
p. 76
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.
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.
29-1.2 POIs and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords/authentication codes.
29-1.2.a Examine vendor documentation or other information sources to identify default keys (such as keys that are pre-installed for testing purposes), passwords, or data.
29-1.2.b Observe implemented processes and interview personnel to verify that default keys or passwords are not used.
Note: Chain of custody includes procedures, as stated in Requirement 29-1, that ensure that access to all POI devices …
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.
29-1.2 POIs and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords/authentication codes.
29-1.2.a Examine vendor documentation or other information sources to identify default keys (such as keys that are pre-installed for testing purposes), passwords, or data.
29-1.2.b Observe implemented processes and interview personnel to verify that default keys or passwords are not used.
Note: Chain of custody includes procedures, as stated in Requirement 29-1, that ensure that access to all POI devices …
Added
p. 78
• Shipped and stored containing a secret that:
− Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and − Can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.
PIN Security Requirements Testing Procedures 29-3 (continued)
− Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised.
For example, for HSMs used in transaction processing operations:
• PIN-block format translation functionality is in accordance with
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 …
− Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and − Can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.
PIN Security Requirements Testing Procedures 29-3 (continued)
− Devices incorporate self-tests to ensure their correct operation. Devices must not be re-installed unless there is assurance they have not been tampered with or compromised.
For example, for HSMs used in transaction processing operations:
• PIN-block format translation functionality is in accordance with
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 …
Added
p. 85
• For all access to key-loading devices (KLDs).
• To place the device into a state that allows for the input or output of clear- text key components;
• For all access to KLDs.
PIN Security Requirements Testing Procedures 32-1.4 Devices must not use default passwords/authentication codes.
• Locked in a secure cabinet and/or sealed in tamper-evident packaging, or
• To place the device into a state that allows for the input or output of clear- text key components;
• For all access to KLDs.
PIN Security Requirements Testing Procedures 32-1.4 Devices must not use default passwords/authentication codes.
• Locked in a secure cabinet and/or sealed in tamper-evident packaging, or
Added
p. 87
A1
• Remote Key-Distribution Using Asymmetric Techniques Operations Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key distribution using asymmetric techniques for the distribution of acquirer keys to transaction-originating devices (POIs) for use in connection with PIN encryption, whether the actual distribution of acquirer keys occurs from the transaction-processing host or is distributed directly by the vendor.
• ANSI TR-34 presents a methodology that is compliant with these requirements.
A2
• Certification and Registration Authority Operations Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
If the key loading is not performed remotely and authentication is provided by another method
•such as properly implemented dual control using 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 …
• Remote Key-Distribution Using Asymmetric Techniques Operations Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key distribution using asymmetric techniques for the distribution of acquirer keys to transaction-originating devices (POIs) for use in connection with PIN encryption, whether the actual distribution of acquirer keys occurs from the transaction-processing host or is distributed directly by the vendor.
• ANSI TR-34 presents a methodology that is compliant with these requirements.
A2
• Certification and Registration Authority Operations Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
If the key loading is not performed remotely and authentication is provided by another method
•such as properly implemented dual control using 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 …
Added
p. 111
• The CPS must be consistent with the requirements described within this document.
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 validating the identity of the certificate requestor and recipient before issuing a digital certificate for the recipient’s associated public key.
• Verification of the certificate applicant’s possession of the associated private key through the use of a digitally signed certificate request pursuant to PKCS #10 or another cryptographically-equivalent demonstration;
• Determination that the organization exists by using at least one …
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 validating the identity of the certificate requestor and recipient before issuing a digital certificate for the recipient’s associated public key.
• Verification of the certificate applicant’s possession of the associated private key through the use of a digitally signed certificate request pursuant to PKCS #10 or another cryptographically-equivalent demonstration;
• Determination that the organization exists by using at least one …
Added
p. 116
32-2.5.1 Doors to the Level 3 secure room must have locking mechanisms.
Added
p. 120
• The system records to time-lapse VCRs or similar mechanisms.
• Unauthorized entry attempts
• Name and signature of the individual
• Name and signature of the individual
• Date and time in and out
• Date and time in and out
• Reason for access or purpose of visit
• Reason for access or purpose of visit
• Unauthorized entry attempts
• Name and signature of the individual
• Name and signature of the individual
• Date and time in and out
• Date and time in and out
• Reason for access or purpose of visit
• Reason for access or purpose of visit
Added
p. 126
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.
• Model name and number
• The FIPS 140 approval number
• The PCI PTS or FIPS 140 Approval Number
• The PCI PTS HSM approval number
• Model name and number
• The FIPS 140 approval number
• The PCI PTS or FIPS 140 Approval Number
• The PCI PTS HSM approval number
Added
p. 129
• An approved key-generation function of a PCI-approved HSM or POI
• An approved key-generation function of a PCI-approved HSM or
• 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 SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22
6-1.1 Any clear-text output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the clear text of any key component/share. Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.
• An approved key-generation function of a PCI
•approved HSM or POI
• An SCD that has an approved random number generator that has …
• An approved key-generation function of a PCI-approved HSM or
• 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 SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22
6-1.1 Any clear-text output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the clear text of any key component/share. Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.
• An approved key-generation function of a PCI
•approved HSM or POI
• An SCD that has an approved random number generator that has …
Added
p. 135
• Memory storage of a key-loading device, after loading the key to a different device or system
• Specific direction as to the method of destruction is included in the procedure.
• The method of destruction is consistent with Requirement 24.
• Other types of displaying or recording 6-4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures ensure the following:
Examine logs of past destructions and deletions to verify that procedures are followed.
• Generated by the device that will use the key pair; or
• Faxing, e-mailing, or otherwise electronically conveying clear-text secret or private keys or components
• Affixing (e.g., taping) key or component values to or inside devices
• Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that they include language that prohibits transmitting clear-text private or secret keys or their components/shares across insecure channels, including but not limited to:
• Conveying …
• Specific direction as to the method of destruction is included in the procedure.
• The method of destruction is consistent with Requirement 24.
• Other types of displaying or recording 6-4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures ensure the following:
Examine logs of past destructions and deletions to verify that procedures are followed.
• Generated by the device that will use the key pair; or
• Faxing, e-mailing, or otherwise electronically conveying clear-text secret or private keys or components
• Affixing (e.g., taping) key or component values to or inside devices
• Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that they include language that prohibits transmitting clear-text private or secret keys or their components/shares across insecure channels, including but not limited to:
• Conveying …
Added
p. 161
• Examine documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that:
− SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.
− An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device.
− There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys.
13-2.b Observe a demonstration of key loading to verify that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility.
• The sending and receiving SCDs must be inspected prior to key loading to ensure that they …
− SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.
− An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device.
− There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys.
13-2.b Observe a demonstration of key loading to verify that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility.
• The sending and receiving SCDs must be inspected prior to key loading to ensure that they …
Added
p. 165
Note: Effective 1 January 2021, entities engaged in key loading on behalf of others shall not be allowed to use PC based key-loading methodologies where clear-text secret and/or private keying material appears in the clear in memory outside the secure boundary of an SCD.
Effective 1 January 2023, entities only performing key loading for devices for which they are the processor shall no longer have this option.
• Dedicated to only the key-loading function (e.g., there must not be any other application software installed); and
• Located in a physically secure room meeting the criteria of
• Located in a physically secure room meeting the criteria of
Requirement 32-9 that is dedicated to key-loading activities.
• Dedicated to only key loading
• Logs of access to the room from a badge-access system;
• Logs of access to the room from a manual sign-in sheet;
• User sign-on logs on the PC at the operating-system level;
• User sign-on logs on …
Effective 1 January 2023, entities only performing key loading for devices for which they are the processor shall no longer have this option.
• Dedicated to only the key-loading function (e.g., there must not be any other application software installed); and
• Located in a physically secure room meeting the criteria of
• Located in a physically secure room meeting the criteria of
Requirement 32-9 that is dedicated to key-loading activities.
• Dedicated to only key loading
• Logs of access to the room from a badge-access system;
• Logs of access to the room from a manual sign-in sheet;
• User sign-on logs on the PC at the operating-system level;
• User sign-on logs on …
Added
p. 171
• Be within a certificate as defined in Annex A; or
• Be within a PKCS#10 (authentication and integrity occurs via other mechanisms); or
• Be within an SCD; or
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 check value will be the leftmost n-bits of the result, where n is at most 40 bits (10 hexadecimal digits). The block cipher used in the CMAC function is the same as the block cipher of the key itself. A TDEA key or a …
• Be within a PKCS#10 (authentication and integrity occurs via other mechanisms); or
• Be within an SCD; or
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 check value will be the leftmost n-bits of the result, where n is at most 40 bits (10 hexadecimal digits). The block cipher used in the CMAC function is the same as the block cipher of the key itself. A TDEA key or a …
Added
p. 184
• Identification of key personnel
• A damage assessment including, where necessary, the engagement of outside consultants
• Missing secure cryptographic devices
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 22-1.5 Interview responsible personnel and examine documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
• increases the risk of exposure of each of those keys.
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.
• physically secured, enciphered, or components
•must be …
• A damage assessment including, where necessary, the engagement of outside consultants
• Missing secure cryptographic devices
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 22-1.5 Interview responsible personnel and examine documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
• increases the risk of exposure of each of those keys.
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.
• physically secured, enciphered, or components
•must be …
Added
p. 204
• For all access to key-loading devices (KLDs).
• For all access to KLDs.
• To enable any manual key-encryption functions and any key- encryption functions that occur outside of normal transaction processing;
PIN Security Requirements Testing Procedures 32-1.4 Devices must not use default passwords/authentication codes.
• Locked in a secure cabinet and/or sealed in tamper-evident packaging,
• For all access to KLDs.
• To enable any manual key-encryption functions and any key- encryption functions that occur outside of normal transaction processing;
PIN Security Requirements Testing Procedures 32-1.4 Devices must not use default passwords/authentication codes.
• Locked in a secure cabinet and/or sealed in tamper-evident packaging,
Added
p. 208
• 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 2023, the same restriction applies to entities engaged in key injection of devices for which they are the processors.
Note: This does not apply to key components entered into the keypad of a secure cryptographic device, such as a device approved against the PCI PTS POI Security Requirements. It does apply to all other methods of loading of clear-text keying material for POI v3 and higher devices.
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 …
• Effective 1 January 2023, the same restriction applies to entities engaged in key injection of devices for which they are the processors.
Note: This does not apply to key components entered into the keypad of a secure cryptographic device, such as a device approved against the PCI PTS POI Security Requirements. It does apply to all other methods of loading of clear-text keying material for POI v3 and higher devices.
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 …
Added
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.
Added
p. 214
Audit Logs The minimum manual log contents include date and time, object name/identifier, purpose, name and signature of individual(s) involved, and if applicable, tamper-evident package number(s) and serial number(s) of device(s) involved. Electronic logs contain similar information and must be protected from alteration by cryptographic mechanisms⎯e.g., digital signature or MACing.
Authentication code See Password.
Certificate Processor An entity that generates key pairs and that may also issue certificates on behalf of other entities, including Certificate Authorities.
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 …
Authentication code See Password.
Certificate Processor An entity that generates key pairs and that may also issue certificates on behalf of other entities, including Certificate Authorities.
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 …
Added
p. 219
Hardware Management Device (HMD) A non-SCD device used to provide cryptographic services but which requires usage restrictions and additional controls to address inherent security limitations. Examples of HMDs include, but are not limited to:
1. Smart cards used for component or share transport or storage
2. Smart cards containing public/private key pair(s) used to facilitate management of HSMs
3. Devices used to authorize or enable key-management functions
Interchange The exchange of Items for value between acquirers and issuers, as a result of the use of an issuer’s card by a cardholder to generate a transaction.
1. Smart cards used for component or share transport or storage
2. Smart cards containing public/private key pair(s) used to facilitate management of HSMs
3. Devices used to authorize or enable key-management functions
Interchange The exchange of Items for value between acquirers and issuers, as a result of the use of an issuer’s card by a cardholder to generate a transaction.
Added
p. 223
Multi-factor authentication Method of authenticating a user whereby at least two factors are verified. These factors include something the user has (such as a smart card or dongle), something the user knows (such as a password, passphrase, or PIN) or something the user is or does (such as fingerprints, other forms of biometrics, etc.).
Added
p. 226
Public key infrastructure (PKI) A set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.
Secure Room An access-controlled room requiring the use of an electronic access-control system (for example, badge and/or biometrics) to enter. Additional controls may apply as specified in individual requirements.
Secure Room An access-controlled room requiring the use of an electronic access-control system (for example, badge and/or biometrics) to enter. Additional controls may apply as specified in individual requirements.
Added
p. 229
• Are reasonably secure from intrusion and misuse;
• Are reasonably suited to performing their intended functions.
• Automated Fuel Dispenser
• Automated fuel dispensers
• Transaction Processing Operations (main body)
• Symmetric Key Distribution using Asymmetric Techniques (Normative Annex A)
• Key-Injection Facilities (Normative Annex B) In addition, as delineated below by a red “X,” requirements stated in the main body are additionally applicable to the two sub-annexes of Symmetric Key Distribution using Asymmetric Techniques.
Organizations may be engaged in one or more of these activities and are subject to requirements for all activities in which they engage.
PIN Security Requirements Requirement Transaction Processing Operations Symmetric Key Distribution using Asymmetric Techniques (Normative Annex A) Key-Injection Facilities (Normative Annex B) Conditions Remote Key Distribution Using Asymmetric Techniques Operations Certification and Registration Authority Operations Control Objective 1 1-3 X X X X 1-4 X X X X
• Are reasonably suited to performing their intended functions.
• Automated Fuel Dispenser
• Automated fuel dispensers
• Transaction Processing Operations (main body)
• Symmetric Key Distribution using Asymmetric Techniques (Normative Annex A)
• Key-Injection Facilities (Normative Annex B) In addition, as delineated below by a red “X,” requirements stated in the main body are additionally applicable to the two sub-annexes of Symmetric Key Distribution using Asymmetric Techniques.
Organizations may be engaged in one or more of these activities and are subject to requirements for all activities in which they engage.
PIN Security Requirements Requirement Transaction Processing Operations Symmetric Key Distribution using Asymmetric Techniques (Normative Annex A) Key-Injection Facilities (Normative Annex B) Conditions Remote Key Distribution Using Asymmetric Techniques Operations Certification and Registration Authority Operations Control Objective 1 1-3 X X X X 1-4 X X X X
Modified
p. 1
Payment Card Industry (PCI) PIN Security Requirements and Testing Procedures Version 2.0
Payment Card Industry (PCI) PIN Security Requirements and Testing Procedures Version 3.0
Removed
p. 5
For specific requirements pertaining to entities that operate key-injection facilities for the injection of keys (KEKs, PEKs, etc.) used for the acquisition of PIN data, see Normative Annex B.
• POI key-encipherment key, PEK
• POI PIN-encipherment key, MFK
• HSM Master File Key, KEK-A
• Zone key-encipherment key shared with organization A, ZWK-A
• PIN- encipherment key shared with organization A, etc.). This also must include keys such as any asymmetric key pairs used for remote key- establishment and distribution as delineated in Annex A, and other keys used in the message flow such as MAC and keys associated with account data encryption. It is not required to include vendor keys such as those used for firmware authentication, but shall include acquirer-controlled private or secret keys used to sign payment applications that handle PIN data, display prompt control data, etc. The algorithm (e.g., AES, TDEA, RSA) used and key size (e.g., 128, 2048) for …
• POI key-encipherment key, PEK
• POI PIN-encipherment key, MFK
• HSM Master File Key, KEK-A
• Zone key-encipherment key shared with organization A, ZWK-A
• PIN- encipherment key shared with organization A, etc.). This also must include keys such as any asymmetric key pairs used for remote key- establishment and distribution as delineated in Annex A, and other keys used in the message flow such as MAC and keys associated with account data encryption. It is not required to include vendor keys such as those used for firmware authentication, but shall include acquirer-controlled private or secret keys used to sign payment applications that handle PIN data, display prompt control data, etc. The algorithm (e.g., AES, TDEA, RSA) used and key size (e.g., 128, 2048) for …
Modified
p. 5
The 33 requirements presented in this document are organized into seven logically related groups, referred to as “Control Objectives.” These requirements are intended for use by all acquiring institutions and agents responsible for PIN transaction processing on the payment card industry participants’ denominated accounts and should be used in conjunction with applicable industry standards. These requirements do not apply to issuers and their agents.
Organization The requirements presented in this document are organized into seven related groups, referred to as “Control Objectives.” These requirements are intended for use by all acquiring institutions and agents (e.g., key-injection facilities and certificate processors) responsible for PIN transaction processing on the payment card industry participants’ denominated accounts and should be used in conjunction with other applicable industry standards.
Modified
p. 5
• Identifies minimum security requirements for PIN-based interchange transactions.
Modified
p. 5
• Outlines the minimum acceptable requirements for securing PINs and encryption keys.
Modified
p. 5
• Assists all retail electronic payment system participants in establishing assurances that cardholder PINs will not be compromised.
Modified
p. 5
For specific requirements pertaining to acquiring 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.
Normative Annex A
• Symmetric Key Distribution using Asymmetric Keys For specific requirements pertaining to acquiring 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 acquiring 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 …
Modified
p. 5 → 6
The key sizes specified in this document are the minimums for the specified algorithms. PCI shall specify larger key sizes as appropriate at a future date. Individual payment brands may specify the use of larger key size minimums in connection with the processing of their transactions.
Keys and Key-Size Specifications The key sizes specified in this document are the minimums for the specified algorithms. PCI shall specify larger key sizes as appropriate at a future date. Individual payment brands may specify the use of larger key size minimums in connection with the processing of their transactions.
Modified
p. 5 → 6
For acquiring entities, the scope of these requirements includes all cryptographic keys used in connection with the acquiring and processing of PIN data. This includes keys used by POI devices, HSMs, and those shared with other internal network nodes or with other organizations that are used for the conveyance of PIN data and associated messages. Note that MAC and account-data encryption keys are not in scope except to ensure they are not used for functions that are in scope, such …
Removed
p. 6
Compliance with a specific SCD standard The types of devices The time windows for the deployment (and removal) of such devices Sunset (retirement) dates for specific models or SCD standards The lists of device models compliant with a version of the PCI PTS standard can be found at www.pcisecuritystandards.org under “Approved Companies & Providers.” Device models whose certificates 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.
Modified
p. 6 → 8
• Device models whose PCI PTS approvals are expired are listed under “PTS Devices with Expired Approvals.” For specific considerations, contact the payment brand(s) of interest.
Modified
p. 6 → 8
Effective Date The effective date for this document is December 2014. The individual payment brands shall set the effective date for compliance. For further details, contact the payment brand(s) of interest.
Effective Date The individual payment brands shall set the effective date for compliance. For further details, contact the payment brand(s) of interest.
Modified
p. 7 → 9
This Technical Reference refers to Triple-DEA (TDEA) with at least double-length key and AES as the cryptographic standard for PIN encryption.
This Technical Reference refers to Triple-DEA (TDEA) with at least double-length keys and AES as the cryptographic standard for PIN encryption.
Modified
p. 7 → 9
As of this date, the following standards are reflected in the composite PIN Security Requirements.
As of this date, the standards in the following list are reflected in the composite PIN Security Requirements.
Modified
p. 8 → 10
• Part 3: Block Ciphers ISO TR 19038: Guidelines on Triple DEA Modes of Operation NIST NIST Special Publication 800-22: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications NIST Special Publication 800-57: Recommendation for Key Management NIST Special Publication 800-131: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths
• Part 3: Block Ciphers ISO TR 19038: Guidelines on Triple DEA Modes of Operation ISO 20038: Banking and related financial services -- Key wrap using AES NIST NIST Special Publication 800-22: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications NIST Special Publication 800-57: Recommendation for Key Management NIST Special Publication 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management NIST Special Publication 800-131: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key …
Removed
p. 9
The device unique identifier The company name (vendor) of the device model The device model name The PCI PTS standard(s) and version with which the model complies The PCI PTS Approval Number The PCI PTS POI Product Type associated to the device The location of device The device status (in operation, in warehouse, etc.) (continued on next page) 1-1 Procedures applicable to POI devices (PCI PTS standards):
Modified
p. 9 → 12
A secure cryptographic device (SCD) must meet the requirements of a “Physically Secure Device” as defined in ISO 9564. For POI PIN-acceptance devices this is evidenced by their being validated and PCI approved against one of the following:
A secure cryptographic device (SCD) must meet the requirements of a “Physically Secure Device” as defined in ISO 13491. This is evidenced by their being validated and approved against one of the following:
Modified
p. 9 → 12
• 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):
Modified
p. 9 → 12
1-1.a Obtain the POI Device Inventory. Check for the correct population of the fields 1-1.b Compare the inventory 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.
1-1.a Obtain the POI device information. Check for the correct population of the fields 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. 9 → 12
1-1.c For devices in the inventory identified as PCI approved, verify that all of the following POI device characteristics in the inventory listing match the PCI PTS listing.
1-1.c For devices identified as PCI approved, verify that all of the following POI device characteristics match the PCI PTS listing.
Modified
p. 9 → 12
• Name and application version number of any applications resident within the device that were included in the PTS assessment
Modified
p. 10 → 13
PIN Security Requirements Testing Procedures The date of deployment or installation of the device The brand payment schemes accepted by the device The acquiring financial institution The dates of placement into service, initialization, deployment, use, and decommissioning (where applicable) The POI Device inventory must include the following summary information List of models used Total number of devices, broken down by PCI PTS POI Product Type Total number of devices, broken down by model …
PIN Security Requirements Testing Procedures 1-1.d For a sample of the PCI-approved devices, verify that the device displays the firmware version and either displays or has a label with the hardware version number.
Modified
p. 10 → 13
Note: PCI-approved devices must show the version numbers of hardware and firmware like they have been approved and they are shown in the list of approved devices. The hardware number must be shown on a label attached to the device. The firmware and application version numbers, and optionally the hardware version number, must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open Protocols.
Note: PCI-approved devices must show the same version numbers of hardware and firmware as have been approved and are shown in the list of approved devices. If it is not displayed, the hardware number must be shown on a label attached to the device. The firmware and application version numbers, and optionally the hardware version number, must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open …
Modified
p. 10 → 13
1-2 Not used in core requirements and testing procedures.
1-2 Not used in Transaction Process Operations procedures.
Modified
p. 10 → 14
1-3 Ensure that all hardware security modules (HSMs) are either:
PIN Security Requirements Testing Procedures 1-3 All hardware security modules (HSMs) shall be either:
Modified
p. 10 → 14
• FIPS140-2 Level 3 or higher certified, or
Modified
p. 10 → 14
1-3.a For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and review the list of approved devices to verify that all HSMs are either:
1-3.a For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and examine the list of approved devices to verify that all HSMs are either:
Modified
p. 10 → 14
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140- 2 Level 3, or higher. Refer http://csrc.nist.gov.
Modified
p. 10 → 14
• Listed on the PCI SSC website, with a valid SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Refer to https://www.pcisecuritystandards.org.
Modified
p. 10 → 14
1-3.b Examine documented procedures and interview personnel to verify that all decryption 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.
Removed
p. 11
Vendor name Model name/number Hardware version number Firmware version number
2-1 No procedure shall require or permit the cardholder to disclose the PIN in an oral or written manner.
2-1 Interview responsible personnel to determine that no procedures require or permit the cardholder to disclose their PIN in an oral or written manner.
2-1 No procedure shall require or permit the cardholder to disclose the PIN in an oral or written manner.
2-1 Interview responsible personnel to determine that no procedures require or permit the cardholder to disclose their PIN in an oral or written manner.
Modified
p. 11 → 14
1-4 The approval listing must match the deployed devices in the following characteristics:
Modified
p. 11 → 14
• For PCI-approved HSMs, any applications resident within the device, including application version number, that were included in the PTS assessment.
Modified
p. 11 → 14
1-4.a For all PCI-approved HSMs used, examine HSM devices and review the PCI SSC List of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
1-4.a For all PCI-approved HSMs used, examine HSM devices and examine the PCI SSC List of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
Modified
p. 11 → 15
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:
Modified
p. 11 → 15
Requirement 2a: Cardholder PINs shall be processed in accordance with approved standards. 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. 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 …
Requirement 2: Cardholder PINs shall be processed in accordance with approved standards. 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. 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 …
Modified
p. 12 → 15
2-2 Online PIN translation must only occur using one of the allowed key- management methods: DUKPT, fixed key, master key/session key.
Modified
p. 12 → 15
2-2.b Review system documentation to determine key-management methods used within each zone•e.g., terminal to host, host to next node, etc.
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.
Modified
p. 12 → 16
2-3 Online PINs must be encrypted using an algorithm and key size that is specified in ISO 9564. Currently, the only approved algorithms for online PIN are:
PIN Security Requirements Testing Procedures 2-3 Online PINs must be encrypted using an algorithm and key size that is specified in ISO 9564. Currently, the only approved algorithms for online PIN are:
Modified
p. 12 → 16
• AES as described in ISO 18033-3 For purposes of these requirements, all references to TECB are using key options 1 or 2, as defined in ISO 18033-3.
Modified
p. 12 → 16
2-3.b Examine system documentation to verify information provided during the aforementioned interviews:
2-3.b Examine system documentation, the list of cryptographic keys, and the network schematic to verify information provided during the aforementioned interviews:
Modified
p. 12 → 16
• For internally developed systems, examine system design documentation or source code for type of key (algorithm) and key sizes used to encrypt the PIN blocks. Examine the point in the code where the calls are made to the hardware security module.
Modified
p. 12 → 16
• For application packages, examine parameter files (e.g., the Base24 KEYF file) to determine type of key (algorithm) and key sizes used to encrypt PIN blocks.
Modified
p. 12 → 16
2-3.d Examine the algorithm type parameter (to ensure it denotes TDEA and/or AES) and hardware-encryption-required parameter (to ensure it indicates hardware encryption•not software encryption) on every terminal link, network link, and if applicable, internal path (i.e., if using an intermediate key) for the host application.
2-3.d Examine the algorithm type parameter (to ensure it denotes TDEA and/or AES) and hardware-encryption-required parameter (if applicable, to ensure it indicates hardware encryption•not software encryption) on every terminal link, network link, and if applicable, internal path (i.e., if using an intermediate key) for the host application.
Modified
p. 13 → 17
2-4.a Interview the responsible personnel to determine which POI devices identified in Requirement 1 are used for offline PIN acquiring.
2-4.a Interview the responsible personnel to determine which POI device models identified in Requirement 1 summary are used for offline PIN acquiring.
Modified
p. 13 → 17
PIN submission PED and IC reader integrated as a device meeting the requirements of PED and IC reader not integrated as a device meeting the requirements of ISO 9564 2-4.b Validate that the POI devices used for offline PIN, including both the ICCR and the PED, where non-integrated, are approved for “Offline PIN” on the PTS Approved Devices Listing at www.pcisecuritystandards.org
PIN submission PIN entry device and IC reader integrated as a device meeting the requirements of PIN entry device and IC reader not integrated as a device meeting the requirements of ISO 9564 2-4.b Validate that the POI device models used for offline PIN
•including both the ICCR and the PIN entry device where non-integrated
•are approved for “Offline PIN” on the PTS Approved Devices Listing at www.pcisecuritystandards.org
•including both the ICCR and the PIN entry device where non-integrated
•are approved for “Offline PIN” on the PTS Approved Devices Listing at www.pcisecuritystandards.org
Modified
p. 13 → 17
1. Enciphered PIN block submitted to the IC The PIN block shall be submitted to the IC enciphered using an authenticated encipherment key of the IC.
1. Enciphered PIN block submitted to the IC card The PIN block shall be submitted to the IC card enciphered using an authenticated encipherment key of the IC card.
Modified
p. 13 → 17
The PIN block shall be enciphered between the PED and the IC reader in accordance with ISO 9564 or enciphered using an authenticated encipherment key of the IC.
The PIN block shall be enciphered between the PIN entry device and the IC reader in accordance with ISO 9564 or enciphered using an authenticated encipherment key of the IC card.
Modified
p. 13 → 17
The PIN block shall be submitted to the IC enciphered using an authenticated encipherment key of the IC.
The PIN block shall be submitted to the IC card enciphered using an authenticated encipherment key of the IC card.
Modified
p. 13 → 17
2. Plaintext PIN block submitted to the IC No encipherment of the PIN block is required.
2. Plaintext PIN block submitted to the IC card No encipherment of the PIN block is required.
Modified
p. 13 → 17
The PIN block shall be enciphered from the PED to the IC reader in accordance with ISO 9564.
The PIN block shall be enciphered from the PIN entry device to the IC reader in accordance with ISO 9564.
Modified
p. 14 → 18
3-1 For secure transmission of the PIN from the point of PIN entry to the card issuer, the encrypted PIN-block format must comply with ISO 9564 format 0, ISO 9564 format 1, ISO 9564 format 3 or ISO 9564 format 4.
3-1 For secure transmission of the PIN from the point of PIN entry to the card issuer, the encrypted PIN-block format must comply with ISO 9564 format 0, ISO 9564 format 1, ISO 9564 format 3, or ISO 9564 format 4.
Modified
p. 14 → 18
3-1.a Interview responsible personnel to determine the PIN-block format(s) utilized for “not-on-us” traffic from point of acquisition through routing of the transaction to another entity. Develop or obtain a network schematic to illustrate.
3-1.a Interview responsible personnel to determine the PIN-block format(s) utilized for “not-on-us” traffic from point of acquisition through routing of the transaction to another entity. Examine and verify the accuracy of the network schematic.
Modified
p. 14 → 18
• For internally developed systems, examine system design documentation, transaction logs, or source code for type of PIN- block format(s) used.
Modified
p. 14 → 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. 14 → 18
3-2 PINs enciphered only for transmission between the PIN entry device and the IC reader must use one of the PIN-block formats specified in ISO 9564. Where ISO format 2 is used, a unique key per transaction method in accordance with ISO 11568 shall be used. Format 2 shall only be used in connection with either offline PIN verification or PIN change operations in connection with ICC environments.
3-2 PINs enciphered only for transmission between the PIN entry device and the IC reader must use one of the PIN-block formats specified in ISO 9564. Where ISO format 2 is used, a unique-key-per-transaction method in accordance with ISO 11568 shall be used. Format 2 shall only be used in connection with either offline PIN verification or PIN change operations in connection with ICC environments.
Modified
p. 14 → 18
3-2.a For any non-PCI-approved devices identified in Requirement 1, and for which the ICC card reader is not integrated in the PIN entry device, 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 used.
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 …
Modified
p. 14 → 18
3-2.b Review device documentation to validate that the device functions as described above.
3-2.b Examine device documentation to validate that the device functions as described above.
Removed
p. 15
Translation 3-3.b The PIN block shall be submitted to the IC enciphered using an authenticated encipherment key of the IC. To From ISO Format ISO Format ISO Format ISO Format 0, 3, 4 Permitted anywhere without change of PAN Change of PAN only permitted in sensitive state for card issuance Not permitted Permitted for submission to an IC card ISO Format 1 Permitted Permitted Permitted for submission to an IC card ISO Format 2 Not permitted Not permitted Permitted for submission to an IC card
Modified
p. 15 → 19
3-3.a Verify the following, using information obtained in the prior step:
3-3.a Verify the following, using information obtained in the prior steps of Requirement 3:
Modified
p. 15 → 19
• ISO PIN-block formats are not translated into non-ISO formats.
Modified
p. 15 → 19
• ISO PIN-block formats 0, 3, and 4 are not translated into any PIN-block formats other than 0, 3, or 4 except for submission to an IC payment card.
Modified
p. 15 → 19
• If ISO format 1 is translated to ISO format 0, 3, or 4, it is not translated back to ISO format 1.
Modified
p. 15 → 19
• If ISO format 1 is translated to ISO format 2, it is only for submission to an IC payment card.
Modified
p. 15 → 19
• PIN-block translations from ISO format 0, 3, or 4 to any of ISO format 0, 3, or 4 do not support a change in PAN.
Modified
p. 16 → 20
4-1 Transactions may be stored and forwarded under certain conditions as noted in ISO 9564. PIN blocks, even encrypted, must not be retained in transaction journals or logs. PIN blocks are required in messages sent for authorization, but must not be retained for any subsequent verification of the transaction. PIN blocks may be temporarily stored as a system-recovery mechanism in order to recover authorization processing. For the storage of other data elements, see the PCI Data Security Standards.
4-1 Transactions may be stored and forwarded under certain conditions as noted in ISO 9564. PIN blocks, even encrypted, must not be retained in transaction journals or logs. PIN blocks are required in messages sent for authorization but must not be retained for any subsequent verification of the transaction. Transaction PINs shall only exist for the duration of a single transaction (the time between PIN entry and verification, i.e. store and forward). For the storage of other data elements, see …
Modified
p. 16 → 20
4-1 Interview appropriate personnel to determine whether PINs are stored or retained for some period of time as part of a store-and-forward environment. Based upon that, perform the following steps as necessary:
4-1 Interview appropriate personnel to determine whether PINs are stored or retained for some period of time as part of a store-and-forward environment:
Modified
p. 16 → 20
•whether enciphered or not
•must be masked before the record is logged. For environments using online transaction monitors (e.g., CICS), specifically note how management is ensuring that PINs are not stored in online transaction journals.
• Examine transaction journals/logs to determine the presence of PIN blocks. If present, PIN blocks
•whether enciphered or not
•must be masked before the record is logged. For environments using online transaction monitors (e.g., CICS), specifically note how management is ensuring that PINs are not stored in online transaction journals.
•whether enciphered or not
•must be masked before the record is logged. For environments using online transaction monitors (e.g., CICS), specifically note how management is ensuring that PINs are not stored in online transaction journals.
Modified
p. 16 → 20
• For entities that drive POS devices, examine documentation (operating procedures) to verify the disposition of PIN blocks when communication links are down.
Modified
p. 17 → 21
Requirement 5: All keys and key components must be generated using an approved random or pseudo-random process.
Requirement 5: All keys, key components, and key shares must be generated using an approved random or pseudo-random process.
Modified
p. 17 → 21
5-1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Cryptographic keys or key components must be generated by one of the following:
5-1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Generation of cryptographic keys or key components must occur within an SCD. They must be generated by one of the following:
Modified
p. 17 → 21
• An SCD that has an approved random number generator that has been certified by an independent laboratory to comply with NIST SP 800-22
Modified
p. 17 → 21
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. 17 → 21
5-1.a Examine key-management policy document and to verify that it requires that all devices used to generate cryptographic keys meet one of the following:
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. 17 → 21
• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.
Modified
p. 17 → 21
• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.
Modified
p. 17 → 21
5-1.c Verify devices used for key generation are those as noted above, including validation of the firmware used.
5-1.c Examine procedures to be used for future generations and logs of past key generations to verify devices used for key generation are those as noted above, including validation of the firmware used.
Removed
p. 18
6-1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component.
There is no unauthorized mechanism that might disclose a clear- text key or key component between the key-generation device and the device or medium receiving the key or key component.
There is no mechanism including connectivity that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Note: Full-length key components or key shares derived using a recognized key-splitting algorithm are not considered key parts and do not provide any information regarding the actual cryptographic key.
There is no unauthorized mechanism that might disclose a clear- text key or key component between the key-generation device and the device or medium receiving the key or key component.
There is no mechanism including connectivity that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Note: Full-length key components or key shares derived using a recognized key-splitting algorithm are not considered key parts and do not provide any information regarding the actual cryptographic key.
Modified
p. 18 → 22
6-1 Implement security controls, including dual control and tamper protection, to prevent the unauthorized disclosure of keys/key components.
6-1 Implement security controls, including dual control and tamper detection, to prevent the unauthorized disclosure of keys or key components.
Modified
p. 18 → 22
• Any output of a clear-text component or share is overseen by only the assigned key custodian(s) for that component/share
Modified
p. 18 → 22
6-1.1.b Observe key-generation processes and interview responsible personnel to verify:
6-1.1.b Observe key-generation process demonstration and interview responsible personnel to verify:
Modified
p. 18 → 22
• Any output of a clear-text component or share is overseen by only the assigned key custodian(s) for the component/share.
Modified
p. 18 → 22
6-1.2 There must be no point in the process where a single individual has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
6-1.2 There must be no point in the key-generation process where a single individual has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
Modified
p. 18 → 22
6-1.2.a Observe the process from end-to-end to verify there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
6-1.2.a Examine documented procedures for all key-generation methods and observe demonstrations of the key-generation process from end-to-end to verify there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
Modified
p. 18 → 22
6-1.2.b Examine key-generation logs to verify that at least two individuals performed the key-generation processes.
6-1.2.b Examine key-generation logs to verify that:
Removed
p. 19
6-1.4.a Review documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering, prior to use.
6-1.5.b Observe the physical security controls to verify that key- component/key-generation process cannot be observed or accessed by unauthorized personnel.
6-2.b Observe generation process and review vendor documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory.
6-1.5.b Observe the physical security controls to verify that key- component/key-generation process cannot be observed or accessed by unauthorized personnel.
6-2.b Observe generation process and review vendor documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory.
Modified
p. 19 → 23
PIN Security Requirements Testing Procedures 6-1.3 Devices used for generation of clear-text key components that are output in the clear must be powered off when not in use.
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. 19 → 23
• Key-generation devices that generate clear-text key components are powered off when not in use or require re-authentication whenever key generation is invoked; or
Modified
p. 19 → 23
6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (for example, unnecessary cables).
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. 19 → 23
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.
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. 19 → 23
6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the key-generation area. It must not be feasible to observe the key-component/key-generation process whereby clear-text keying material is observable either directly or via camera monitoring.
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. 19 → 23
6-1.5.a Examine documentation to verify that physical security controls are defined to ensure the key component/key-generation process cannot be observed or accessed by unauthorized personnel.
6-1.5.a Examine documentation to verify that physical security controls (e.g., partitions or barriers) are defined to ensure the key component/ cannot be observed or accessed by unauthorized personnel.
Modified
p. 19 → 24
6-2 Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory.
PIN Security Requirements Testing Procedures 6-2 Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
Modified
p. 19 → 24
6-2.a Examine documented procedures to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory.
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. 20
Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device), or Where clear keying material passes through unprotected memory of the PC, the PC requirements of Requirement 13 of Annex B are met 6-3 Printed key components must be printed within blind mailers or sealed immediately after printing to ensure that:
Modified
p. 20 → 24
Additionally, this requirement excludes from its scope computers used only for administration of SCDs, or key-generation devices that do not have the ability to access clear-text cryptographic keys or components. 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 …
Modified
p. 20 → 25
• Tampering can be visually detected.
Modified
p. 20 → 25
Printers used for this purpose must not be used for other purposes.
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.
Modified
p. 20 → 25
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 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. 20 → 25
• Tampering can be detected.
Modified
p. 20 → 25
6-3.b Observe processes for printing key components to verify that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output.
6-3.b Observe processes for printing key components to verify that:
Modified
p. 20 → 25
6-3.c Observe blind mailers or other sealed containers used for key components to verify that tampering can be detected.
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. 20 → 26
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.
PIN Security Requirements Testing Procedures 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. 20 → 26
Examples of where such key residue may exist include (but are not limited to):
Examples of where such key residue may exist include (but are not limited to): • Printing material, including ribbons and paper waste
Modified
p. 20 → 26
• Other types of displaying or recording 6-4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures ensure the following:
Modified
p. 20 → 26
• Any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation.
Modified
p. 20 → 26
• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key.
Removed
p. 21
Devices used for key generation or key injection are securely stored when not in use.
Modified
p. 21 → 26
• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device immediately after the transfer to the device(s) that will use the key.
Modified
p. 21 → 26
• Any residue that may contain clear-text keys or components is destroyed immediately after generation.
Modified
p. 21 → 27
PIN Security Requirements Testing Procedures 6-4.b Observe the destruction process of the identified key residue and verify the following:
PIN Security Requirements Testing Procedures 6-5 Asymmetric-key pairs must either be:
Modified
p. 21 → 27
• If generated externally, the private key of the key pair and all related critical security parameters (for example, secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair.
Modified
p. 21 → 27
6-5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:
6-5.a Examine documented procedures for asymmetric key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either:
Modified
p. 21 → 27
• If generated externally, the key pair and all related critical security parameters are deleted (zeroized) immediately after the transfer to the device that will use the key pair 6-5.b Observe key-generation processes to verify that asymmetric-key pairs are either:
Modified
p. 21 → 27
• If generated externally, the key pair and all related critical security parameters are deleted (for example, zeroized) immediately after the transfer to the device that will use the key pair.
Removed
p. 22
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text secret or private keys or components Conveying clear-text private or secret keys or their components without containing them within tamper-evident, authenticable packaging Writing key or component values into startup instructions Taping key or component values to or inside devices Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that key components are prohibited from being transmitted across insecure channels, including but not limited to:
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text keys or components Writing key or component values into startup instructions Taping key or component values to or inside devices Writing key or component values in procedure manual 6-6.b From observation …
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text keys or components Writing key or component values into startup instructions Taping key or component values to or inside devices Writing key or component values in procedure manual 6-6.b From observation …
Modified
p. 22 → 28
PIN Security Requirements Testing Procedures 6-6 Policy and procedures must exist to ensure that key components are prohibited from being transmitted across insecure channels. These include but are 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. 23 → 28
Requirement 7: Documented procedures must exist and be demonstrably in use for all key-generation processing.
Requirement 7: Documented procedures must exist and be demonstrably in use for all key-generation processes.
Modified
p. 23 → 28
7-1 Written key-creation procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. Procedures for creating all keys must be documented.
7-1 Written key-generation policies and procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. Procedures for creating all keys must be documented.
Modified
p. 23 → 28
7-1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations.
7-1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations and address all keys in scope.
Modified
p. 23 → 29
7-2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs.
PIN Security Requirements Testing Procedures 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. 23 → 29
7-2.c Examine logs of key generation to verify that exchanges of higher- level keys with other organizations have been recorded.
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.
Removed
p. 24
Note this does not apply to keys installed in POI devices meeting Requirement 1 when shipped from the key-injection facility.
Observe the method used to transport clear-text key components using pre-numbered 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 pre-numbered 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. 24 → 30
8-1 Keys must be transferred either encrypted or
•if clear text
•as two or more components using different communication channels or within an SCD.
•if clear text
•as
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. 24 → 30
Clear-text key components may be conveyed in SCDs or using tamper- evident, authenticable packaging.
Clear-text key components/shares must be conveyed in SCDs or using tamper- evident, authenticable packaging.
Modified
p. 24 → 30
− Components/shares must be conveyed using at least two separate communication channels, such as different courier services. Components/shares sufficient to form the key must not be conveyed using the same communication channel.
Modified
p. 24 → 30
(continued on next page) 8-1.a Determine whether keys are transmitted encrypted, as clear-text components, or within an SCD.
(continued on next page) 8-1.a Determine whether keys are transmitted encrypted, as clear-text components/shares, or within an SCD.
Modified
p. 24 → 30
− Documented procedures exist and are followed to require that the serial numbers be verified prior to the usage of the keying material.
Modified
p. 24 → 31
8-1.b If key components are ever transmitted in clear-text using pre- numbered tamper-evident mailers, 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. 24 → 31
− The details of the serial number of the package were transmitted separately from the package itself.
Modified
p. 24 → 32
• Examine documented procedures to verify that the mechanism to obtain the keying material (e.g., PIN) is conveyed using separate communication channel from the associated SCD.
Modified
p. 24 → 32
• Examine records of key transfers and interview responsible personnel to verify the mechanisms that make the SCD operational are conveyed using separate communication channels.
Removed
p. 25
Examine records of key transfers and interview responsible personnel to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
8-2.a Examine documented procedures to verify they include controls to ensure that no single person can ever have 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:
8-2.a Examine documented procedures to verify they include controls to ensure that no single person can ever have 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:
Modified
p. 25 → 31
• Where SCDs are used for conveying components/shares, the mechanisms or data (e.g., PIN) to obtain the key component/share from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
Modified
p. 25 → 31
• 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. 25 → 31
Note: Components/shares of encryption keys must be conveyed using different communication channels, such as different courier services. It is not sufficient to send key components/shares for a specific key on different days using the same communication channel.
Modified
p. 25 → 32
8-1.d Where an SCD is conveyed with pre-loaded secret and/or private keys, perform the following:
Modified
p. 25 → 32
• Examine documented procedures to verify that the SCD requires dual- control mechanisms to become operational.
Modified
p. 25 → 32
• Examine documented procedures to verify that each SCD is inspected to ensure that there are not any signs of tampering.
Modified
p. 25 → 33
8-2 A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
PIN Security Requirements Testing Procedures 8-2 A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Modified
p. 25 → 33
• Reminder that any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component or shares sufficient to form the necessary threshold to derive the key.
Modified
p. 25 → 33
• Steps to ensure any person with access to the media conveying a component/share of a key could not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key, without detection.
Modified
p. 25 → 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.
Removed
p. 26
8-2.d Observe the method used to transport key components to verify that the method does not allow for any personnel to have access to all components.
Modified
p. 26 → 34
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. 26 → 34
• There is a clear understanding that an individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Modified
p. 26 → 34
• There is sufficient evidence to show that a person with access to the media conveying a key component or key share could not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key without detection.
Modified
p. 26 → 34
8-2.c Examine documented procedures and interview responsible personnel to verify that the method used does not allow for any personnel to have access to all components.
8-2.c Examine records of past key transfers to verify that the method used did not allow for any personnel to have access to components or shares sufficient to form the key.
Modified
p. 26 → 34
8-3 E-mail shall not be used for the conveyance of secret or private keys or their components, even if encrypted, unless the key (or component) has already been encrypted in accordance with these requirements•i.e., in an SCD. This is due to the existence of these key values in unprotected memory just prior to 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 …
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 …
Modified
p. 26 → 34
8-3 Validate through interviews, observation, and logs that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components.
8-3 Validate through interviews, observation, and log inspection that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components/shares.
Removed
p. 27
Use of public-key certificates created by a trusted CA that meets the requirements of Annex A A hash of the public key sent by a separate channel (for example, mail) Using a MAC (message authentication code) created using the algorithm defined in ISO 16609 Be within an SCD 8-4.a Validate that self-signed certificates must not be used as the sole method of authentication.
Modified
p. 27 → 35
• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A.
Modified
p. 27 → 35
• Using a MAC (message authentication code) created using the algorithm defined in ISO 16609
Modified
p. 27 → 35
8-4.c Observe the process for conveying public keys, associated logs, and interview responsible personnel to verify that the implemented method ensures public keys are conveyed in a manner that protects their integrity and authenticity.
Removed
p. 28
Under the continuous supervision of a person with authorized access to this component, Locked in a security container (including pre-numbered tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or Contained within a physically secure SCD.
Under the continuous supervision of a person with authorized access to this component, Locked in a security container (including pre-numbered tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or Contained within a physically secure SCD.
Under the continuous supervision of a person with authorized access to this component, or Locked in a security container (including pre-numbered tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with …
Under the continuous supervision of a person with authorized access to this component, Locked in a security container (including pre-numbered tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or Contained within a physically secure SCD.
Under the continuous supervision of a person with authorized access to this component, or Locked in a security container (including pre-numbered tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with …
Modified
p. 28 → 36
Requirement 9: During its transmission, conveyance, or movement between any two organizational entities, any single unencrypted secret or private key component must at all times be protected.
Requirement 9: During its transmission, conveyance, or movement between any two locations or organizational entities, any single unencrypted secret or private key component or share must at all times be protected.
Modified
p. 28 → 36
Sending and receiving entities are equally responsible for the physical protection of the materials involved.
Sending and receiving locations/entities are equally responsible for the physical protection of the materials involved.
Modified
p. 28 → 36
9-1 Any single clear-text secret or private key component/share must at all times be either:
9-1 During the process to convey it, any single clear-text secret or private key component/share must at all times be either:
Modified
p. 28 → 36
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. 28 → 36
9-1.b Observe key-management processes and interview responsible personnel to verify processes are implemented to 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. 28 → 37
9-2 Packaging or mailers (i.e., pre-numbered tamper-evident packaging) containing clear-text key components are examined for evidence of tampering before being opened. Any sign of package tampering must result in the destruction and replacement of:
PIN Security Requirements Testing Procedures 9-2 Packaging or mailers (i.e., pre-numbered, tamper-evident packaging) containing clear-text key components are examined for evidence of tampering before being opened. Any sign of package tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and replacement of:
Modified
p. 28 → 37
• Any keys encrypted under this (combined) key 9-2.a Verify documented procedures include requirements for all packaging or mailers containing clear-text key components to be examined for evidence of tampering before being opened.
Removed
p. 29
The set of components Any keys encrypted under this (combined) key 9-3 No one but the authorized key custodian (and designated backup(s)) shall have physical access to a key component prior to transmittal or upon receipt of a component.
9-3.a Verify that a list(s) of key custodians (and designated backup(s)) authorized to have physical access to key components prior to transmittal or upon receipt of a component is defined and documented.
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 transmittal or upon receipt.
9-3.a Verify that a list(s) of key custodians (and designated backup(s)) authorized to have physical access to key components prior to transmittal or upon receipt of a component is defined and documented.
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 transmittal or upon receipt.
Modified
p. 29 → 37
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:
Modified
p. 29 → 37
• 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:
Modified
p. 29 → 38
• Place key components into pre-numbered, tamper-evident, authenticable packaging for transmittal.
Modified
p. 29 → 38
• Check tamper-evident packaging upon receipt for signs of tamper prior to opening tamper-evident, authenticable packaging containing key components.
Modified
p. 30 → 38
9-4.b Observe implemented mechanisms and processes and examine logs to verify that only the authorized key custodians can perform the following:
Modified
p. 30 → 39
9-5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers.
PIN Security Requirements Testing Procedures 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. 30 → 39
Note: Numbered courier bags are not sufficient for this purpose 9-5.c Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:
Note: Numbered courier bags are not sufficient for this purpose 9-5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:
Modified
p. 30 → 39
• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package itself.
Modified
p. 30 → 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.
Modified
p. 30 → 40
10-1 All key-encryption keys used to encrypt for transmittal or conveyance of other cryptographic keys must be (at least) as strong as the key being sent, as delineated in Annex C, except as noted below for RSA keys used for key transport and for TDEA keys.
10-1 All key-encryption keys used to encrypt for transmittal or conveyance of other cryptographic keys must be at least as strong as the key being sent, as delineated in Annex C, except as noted below for RSA keys used for key transport.
Modified
p. 30 → 40
10-1.a Examine documented procedures to verify there is a requirement that all keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed, except as noted for RSA keys.
Removed
p. 31
Verify that: o DEA keys used for encrypting keys must be at least double- length keys (have bit strength of 80 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key- encipherment. o A double- or triple-length DEA key must not be encrypted with a DES key of lesser strength. o TDEA keys are not used to protect AES keys. o TDEA keys shall not be used to encrypt keys greater in strength than 112 bits. o RSA keys used to transmit or convey other keys have bit strength of at least 80 bits. o RSA keys encrypting keys greater in strength than 80 bits have bit strength at least 112 bits. o No key-exchange key is weaker than the cryptographic keys it protects and that it is at least double-length for a DEA key; and if RSA, that it uses a key modulus …
Modified
p. 31 → 40
• 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. 31 → 40
• A double- or triple-length TDEA key must not be encrypted with a TDEA key of lesser strength.
Modified
p. 31 → 40
• TDEA keys shall not be used to protect AES keys.
Modified
p. 31 → 40
• TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
Modified
p. 31 → 40
• RSA keys used to transmit or convey other keys must have bit strength of at least 80 bits.
Modified
p. 31 → 40
• RSA keys encrypting keys greater in strength than 80 bits shall have bit strength at least 112 bits.
Modified
p. 31 → 40
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-2within 24 months of the publication of these requirements when …
•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
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 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 …
Modified
p. 31 → 41
PIN Security Requirements Testing Procedures 10-1.c Observe key-generation processes for the key types identified above. Verify that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed except as noted for RSA keys. To verify this:
Modified
p. 31 → 41
• Interview appropriate personnel and examine documented procedures for the creation of these keys.
Modified
p. 31 → 41
• Using the table in Annex C, validate the minimum respective key sizes for TDEA, RSA, Elliptic Curve, DSA, and Diffie Hellman algorithms where used for key encryption.
Modified
p. 32 → 41
10-1.d Examine system documentation and configuration files to validate the above, including HSM settings.
Modified
p. 33 → 43
Requirement 12: Secret and private keys must be input into hardware (host) security modules (HSMs) and PIN entry devices (PEDs) 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. 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.
Modified
p. 33 → 43
12-1.a Review documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required.
12-1.a Using the summary of cryptographic keys, identify keys that are loaded from components and examine documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required.
Modified
p. 33 → 43
12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key, the length of the key components, and the methodology used to form the key.
12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key.
Modified
p. 33 → 43
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 to 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. 33 → 44
12-2 Procedures must be established that will prohibit any one person from having access to components sufficient to form an encryption key when components are removed from and returned to storage for key loading.
PIN Security Requirements Testing Procedures 12-2 Procedures must be established that will prohibit any one person from having access to components sufficient to form an encryption key when components are removed from and returned to storage for key loading.
Modified
p. 33 → 44
12-2. Examine logs of access to security containers for key components to verify that only the authorized custodian(s) have accessed. Compare the number on the current TEA bag for each component to the last log entry for that component.
12-2. Examine logs of access to security containers for key components/shares to verify that only the authorized custodian(s) have accessed. Compare the number on the current tamper-evident and authenticable package for each component to the last log entry for that component.
Removed
p. 34
Two or more passwords of five characters or more (vendor default values must be changed) Multiple cryptographic tokens (such as smartcards), or physical keys Physical access controls Note that for devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian.
12-3.b For all types of production SCDs, observe processes for loading clear-text cryptographic keys, to verify that dual control is required to authorize any key-loading session. Verify that any passwords used are a minimum of five characters.
12-4.b Examine key-component lengths or device configuration settings to verify that key components used to create a key are the same length as the resultant key.
12-3.b For all types of production SCDs, observe processes for loading clear-text cryptographic keys, to verify that dual control is required to authorize any key-loading session. Verify that any passwords used are a minimum of five characters.
12-4.b Examine key-component lengths or device configuration settings to verify that key components used to create a key are the same length as the resultant key.
Modified
p. 34 → 45
PIN Security Requirements Testing Procedures 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.
PIN Security Requirements Testing Procedures 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. 34 → 45
• Procedures require dual control to authorize any key-loading session.
Modified
p. 34 → 45
12-3.c Examine documented records of key-loading processes to verify the presence of two authorized persons during each type of key-loading activity.
12-3.c Examine documented records of key-loading to verify the presence of two authorized persons during each type of key-loading activity.
Modified
p. 34 → 45
12-3.d Ensure that any default dual-control mechanisms (e.g., default passwords
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
12-3.d Ensure that any default dual-control mechanisms (e.g., default passwords/authentication codes
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
Modified
p. 34 → 46
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.) The resulting key must only exist within the SCD.
PIN Security Requirements Testing Procedures 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. 34 → 46
12-4.a Examine documented procedures for combining symmetric-key components and observe processes to verify that key components are combined using a process such that no active bit of the key can be determined without knowledge of the remaining components.
12-4.a Examine documented procedures for combining symmetric-key components and observe processes to verify that key components are combined using a process such that no active bit of the key can be determined without knowledge of the remaining components⎯e.g., only within an SCD.
Modified
p. 34 → 46
12-5 Examine vendor documentation describing options for how the HSM MFK is created. 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.
Removed
p. 35
Asymmetric techniques Manual techniques The existing TMK to encrypt the replacement TMK for download Keys shall not be reloaded by any methodology in the event of a compromised device, and must be withdrawn from use.
Modified
p. 35 → 46
12-7 The initial terminal master key (TMK) or initial DUKPT key must be loaded to the device using either asymmetric key-loading techniques or manual techniques•e.g., the device keypad, IC cards, key-loading device, etc. Subsequent loading of the terminal master key or an initial DUKPT key may use techniques described in this document such as:
Modified
p. 35 → 46
12-7.a Examine documented procedures for the loading of TMKs to verify that they require asymmetric key-loading techniques or manual techniques for initial loading.
12-7.a Examine documented procedures for the loading of TMKs and initial DUKPT keys to verify that they require asymmetric key-loading techniques or manual techniques for initial loading and allowed methods for replacement TMK or initial DUKPT key loading.
Modified
p. 35 → 46
12-7.b Examine documented procedures to verify that keys are prohibited from reloading or reuse wherever suspected of being compromised and are withdrawn from use.
12-7.b Examine documented procedures to verify that keys are withdrawn from use if they were loaded to a device that has been compromised or gone missing.
Modified
p. 35 → 47
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:
PIN Security Requirements Testing Procedures 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. 35 → 47
• Use public and private key lengths that are in accordance with Annex C for the algorithm in question (e.g., 1024-bits minimum for RSA).
Modified
p. 35 → 47
• Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Modified
p. 35 → 47
• Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device has (or can compute) the session key, and that no entity other than the POI device specifically identified can possibly compute the session key.
Modified
p. 35 → 47
12-8.a For techniques involving public-key cryptography, examine documentation and develop a schematic to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication for both the host and the POI.
12-8.a For techniques involving public-key cryptography, examine documentation to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication for both the host and the POI.
Modified
p. 35 → 47
• Use of public and private key lengths that are in accordance with Annex C for the algorithm in question (e.g., 1024-bits minimum for RSA).
Modified
p. 35 → 47
• Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Modified
p. 35 → 47
• Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable.
Removed
p. 36
The SCD must be inspected prior to use to ensure that it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying material.
Ensure that any cameras present are positioned to ensure they cannot monitor the entering of clear-text key components Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: o SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading. o An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device. o There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that …
Ensure that any cameras present are positioned to ensure they cannot monitor the entering of clear-text key components Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: o SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading. o An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device. o There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that …
Modified
p. 36 → 48
• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of clear-text key components.
Modified
p. 36 → 48
• There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys.
Modified
p. 36 → 48
• SCDs must be inspected to detect evidence of monitoring and to ensure dual control procedures are not circumvented during key loading.
Modified
p. 36 → 48
• An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are uniquely identified by the device.
Modified
p. 36 → 49
13-2 Only SCDs shall be 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 controller (computer) keyboards shall never be used for the loading of clear-text secret or private keys or their components.
PIN Security Requirements Testing Procedures 13-2 Only SCDs shall be used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility, as delineated in the requirements contained in Annex B. For example, ATM controller (computer) keyboards or those attached to an HSM shall never be used for the loading of clear-text secret or private keys or their components.
Modified
p. 36 → 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.
Modified
p. 37 → 49
•e.g., smart card, thumb drive,
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 device 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 device 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. 37 → 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
Modified
p. 37 → 49
13-3.a Examine documented procedures for the loading of secret or private key components from an electronic medium to a cryptographic device. Verify that procedures define specific instructions to be followed as a result of key loading, including:
Modified
p. 37 → 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
Modified
p. 37 → 50
PIN Security Requirements Testing Procedures 13-3.b Observe key-loading processes to verify that the loading process results in one of the following:
Modified
p. 37 → 50
• 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. 37 → 50
13-4 Review 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. 37 → 50
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.
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. 37 → 50
13-4.2 Verify the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it.
13-4.2 Verify the key-loading device is under the supervision of a person authorized by management or stored in a secure container such that no unauthorized person can have access to it.
Modified
p. 38 → 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.
Modified
p. 38 → 50
13-4.3.b Verify that authorized personnel inspect the key-loading device prior to use to ensure that a key-recording device has not been inserted between the SCDs.
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. 38 → 51
13-4.4 The key-loading device must not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred.
PIN Security Requirements Testing Procedures 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. 38 → 51
13-5 Any media (electronic or otherwise) containing secret or private key components used for loading cryptographic keys must be maintained in a secure storage location and accessible only to authorized custodian(s). When removed from the secure storage location, media or devices containing key components or used for the injection of clear-text cryptographic keys must be in the physical possession of only the designated component holder(s), and only for the minimum practical time necessary to complete the key-loading process.
13-5 Any media (electronic or otherwise) containing secret or private key components or shares used for loading cryptographic keys must be maintained in a secure storage location and accessible only to authorized custodian(s). When removed from the secure storage location, media or devices containing key components or used for the injection of clear-text cryptographic keys must be in the physical possession of only the designated component holder(s), and only for the minimum practical time necessary to complete the key-loading process.
Modified
p. 38 → 51
Key components that can be read (for example, those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in clear text to a non-custodian for that component.
Key components that can be read (for example, those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in clear text to anyone who is not a designated custodian for that component.
Modified
p. 38 → 51
• Requirement that media/devices be in the physical possession of only the designated component holder(s).
Modified
p. 38 → 51
• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process.
Modified
p. 39 → 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.
Modified
p. 39 → 51
13-6 Validate through interview and observation that printed key components are not opened until just prior to entry into the SCD/KLD. Plaintext secret and/or private keys and/or their components are visible only to key custodians for the duration of loading into an SCD/KLD.
13-6 Validate through interview and observation that printed key components are not opened until just prior to entry into the SCD. Plaintext secret and/or private keys and/or their components are visible only to key custodians for the duration of loading into an SCD.
Modified
p. 39 → 52
13-7 Written or printed key-component documents must not be opened until immediately prior to use.
PIN Security Requirements Testing Procedures 13-7 Written or printed key-component documents must not be opened until immediately prior to use.
Modified
p. 39 → 52
13-7.a Review 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. 39 → 52
13-8.b Examine key-component access controls and access logs to verify that any single authorized custodian can only access their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key.
13-8.b Examine key-component access controls and access logs to verify that any single authorized custodian can and has only had access to their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key.
Modified
p. 39 → 52
Requirement 14: All hardware and access/authentication mechanisms (e.g., passwords) used for key loading must be managed under the principle of dual control.
Requirement 14: All hardware and access/authentication mechanisms (e.g., passwords/authentication codes) used for key loading must be managed under the principle of dual control.
Modified
p. 39 → 52
14-1 Any hardware and passwords used in the key-loading function must be controlled and maintained in a secure environment under dual control. Resources (e.g., passwords and associated hardware) must be managed such that no single individual has the capability to enable key loading of clear-text keys or their components. 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 of clear-text keys or their components. This is not to imply that individual access authentication mechanisms must be managed under dual control.
Modified
p. 39 → 52
• Any hardware used in the key-loading function must be controlled and maintained in a secure environment under dual control.
Modified
p. 39 → 52
• Any resources (e.g., passwords/authentication codes and associated hardware) used in the key-loading function must be controlled and managed such that no single individual has the capability to enable key loading of clear-text keys or their components.
Modified
p. 40 → 53
• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control.
Modified
p. 40 → 53
• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading.
Modified
p. 40 → 53
14-2 All cable attachments where clear-text keying material traverses must be examined before each key-loading operation to ensure they have not been tampered with or compromised.
14-2 All cable attachments over which clear-text keying material traverses must be examined at the beginning of an entity's key-activity operations (system power on/authorization) to ensure they have not been tampered with or compromised.
Modified
p. 40 → 53
14-2.a Review documented procedures to ensure they require that cable attachments be examined prior to key-loading function.
14-2.a Examine documented procedures to ensure they require that cable attachments are examined at the beginning of an entity's key-activity operations (system power on/authorization).
Modified
p. 40 → 53
14-2.b Observe key-loading processes to verify that all cable attachments are properly examined prior to a key-loading function.
14-2.b Observe key-loading processes to verify that all cable attachments are properly examined at the beginning of an entity's key-activity operations (system power on/authorization).
Modified
p. 40 → 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 the use of access-control logs for when removed or placed into secure storage.
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. 40 → 53
14-4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key. Verify procedures require that physical tokens must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control.
14-4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key loading. Verify procedures require that physical tokens must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control.
Modified
p. 40 → 53
14-4.c Review storage locations for physical tokens to determine adequacy to ensure that only the authorized custodian(s) can access their specific tokens.
14-4.c Examine storage locations for physical tokens to determine adequacy to ensure that only the authorized custodian(s) can access their specific tokens.
Modified
p. 40 → 54
14-4.d Verify that access-control logs exist and are in use.
PIN Security Requirements Testing Procedures 14-4.d Verify that access-control logs exist and are in use including notation of tamper-evident, authenticable bag numbers.
Modified
p. 41 → 54
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. 41 → 54
14-5.a Verify that documented procedures require default passwords or PINs used to enforce dual control are changed.
14-5.a Verify that documented procedures require default passwords/authentication codes used to enforce dual control are changed.
Modified
p. 41 → 54
14-5.b Verify that documented procedures exist to require that these passwords/PINs be changed when assigned personnel change.
14-5.b Verify that documented procedures exist to require that these passwords/authentication codes be changed when assigned personnel change.
Modified
p. 41 → 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 not exceed six hexadecimal characters in length.
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 …
Modified
p. 41 → 54
15-1.c Verify that the methods used for key validation are consistent with ISO 11568•for example, if check values are used, they should return a value of no more than six hexadecimal characters.
15-1.c Verify that the methods used for key validation are consistent with ISO 11568•for example, if check values are used, they are in accordance with this requirement.
Modified
p. 41 → 55
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:
PIN Security Requirements Testing Procedures 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. 41 → 55
• Have a MAC (message authentication code) created using the algorithm defined in ISO 16609.
Modified
p. 42 → 55
16-1 Documented key-loading procedures must exist for all devices (e.g., HSMs and POIs), and all parties involved in cryptographic key-loading must be aware of those procedures.
16-1 Documented key-loading procedures must exist for all devices (e.g., HSMs and POIs), and all parties involved in cryptographic key loading must be aware of those procedures.
Modified
p. 43 → 56
17-1 Where two organizations or logically separate systems share a key to encrypt PINs (including key-encipherment keys used to encrypt the PIN-encryption key) communicated between them, that key must be unique to those two organizations or logically separate systems and must not be given to any other organization or logically separate systems.
17-1 Where two organizations or logically separate systems share a key to encrypt PINs (including key-encipherment keys used to encrypt the PIN- encryption key) communicated between them, that key must be unique to those two organizations or logically separate systems and must not be given to any other organization or logically separate systems.
Modified
p. 43 → 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 …
Modified
p. 43 → 56
• If a remote key-establishment and distribution scheme is implemented between networks, examine public keys and/or hash values and/or fingerprints of the keys to verify key uniqueness of the asymmetric-key pairs.
Modified
p. 43 → 56
• Compare key check values against those for known or default keys to verify that known or default key values are not used.
Modified
p. 44 → 57
• Specific actions that determine whether the legitimate value of the cryptographic key has changed. (For example, encryption of a known value to determine whether the resulting cryptogram matches the expected result.)
Modified
p. 44 → 57
18-2 To prevent or detect usage of a compromised key, key-component packaging, or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
18-2 To prevent or detect usage of a compromised key, key-component packaging, or containers that show signs of tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
Modified
p. 44 → 57
18-2.a Verify documented procedures are documented require that key- component packaging/containers showing signs of tampering 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. 44 → 57
18-2.b Interview personnel and observe processes to verify procedures are implemented to require that key-component packaging/containers showing signs of tampering results in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
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, and the result is that one person could have knowledge of the key, it results in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
Removed
p. 45
19-2 Private keys must only be used as follows:
Modified
p. 45 → 58
PIN Security Requirements Testing Procedures 18-3 Effective 1 January 2018, encrypted symmetric keys must be managed in structures called key blocks. The key usage must be cryptographically bound to the key using accepted methods.
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.
Modified
p. 45 → 58
• An integrity check that is an implicit part of the key-encryption process such as that which is used in the AES key-wrap process specified in ANSI X9.102.
Modified
p. 45 → 58
18-3 Examine documented procedures and observe key operations to verify that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of acceptable methods or an equivalent.
18-3 Using the cryptographic-key summary to identify secret keys conveyed or stored, examine documented procedures and observe key operations to verify that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of acceptable methods or an equivalent.
Modified
p. 45 → 59
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.). This is necessary to limit the magnitude of exposure should any key(s) be compromised. Using keys only as they are intended also significantly strengthens the security of the underlying system.
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 its own purpose, key derivation. …
Modified
p. 45 → 59
19-1.b Using a sample of device types, validate via review of check values, terminal definition files, etc. that keys used for key encipherment or PIN encipherment are not used for any other purpose.
19-1.b Using a sample of device types, validate via examination of check values, terminal definition files, etc. that keys used for key encipherment or PIN encipherment are not used for any other purpose.
Modified
p. 45 → 59
• Must be used only for a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices).
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices).
Modified
p. 45 → 59
• Must never be used to encrypt other keys.
Modified
p. 45 → 59
19-2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only used:
19-2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are:
Modified
p. 45 → 59
• Used only to create digital signatures or to perform decryption operations.
Modified
p. 45 → 59
• Used only for a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for POI devices).
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for POI devices).
Modified
p. 45 → 59
• Never used to encrypt other keys.
Modified
p. 46 → 59
19-3 Public keys must only be used for a single purpose•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for transaction-originating POI devices).
Modified
p. 46 → 59
• To perform encryption operations or to verify digital signatures.
Modified
p. 46 → 59
• For a single purpose
•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI devices).
•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI devices).
Modified
p. 46 → 60
19-4 Keys must never be shared or substituted between production and test/development systems:
PIN Security Requirements Testing Procedures 19-4 Keys must never be shared or substituted between production and test/development systems:
Modified
p. 46 → 60
• Key used for production must never be present or used in a test system, and
Modified
p. 46 → 60
Note: For logically partitioned HSMs and computing platforms, if one or more logical partitions of a physical device are used for production and one or more other logical partitions are used for testing, including QA or similar, the entire configuration must be managed and controlled as production.
Note: For logically partitioned HSMs and computing platforms, if one or more logical partitions of a physical device are used for production and one or more other logical partitions are used for testing, including QA or similar, the entire configuration that is impacted⎯computing platform(s) and networking equipment⎯must be managed and controlled as production.
Modified
p. 47 → 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.
Modified
p. 47 → 60
Note: This does not apply to HSMs that are never intended to be used for production.
Modified
p. 47 → 60
• All keying material is deleted from the HSM(s) and the server /computer platforms prior to testing.
Modified
p. 47 → 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.
Modified
p. 47 → 60
• The relevant production keying material is restored using the principles of dual control and split knowledge as stated in these requirements.
Modified
p. 47 → 61
• Known only to HSMs at the minimum number of facilities consistent with effective system operations.
Modified
p. 48 → 61
20-1.c Examine check values, hashes, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI vendor used) to determine that the associated private keys stored in the POI devices are unique per device•i.e., the public keys are unique.
Modified
p. 48 → 61
20-2a Determine whether any transaction-originating terminals interface with multiple acquiring organizations. If so:
Modified
p. 48 → 61
• Examine documented procedures for generating all types of keys and verify the procedures ensure that unique keys or sets of keys are used for each acquiring organization and are totally independent and not variants of one another.
Modified
p. 48 → 61
• Interview personnel and observe key-generation processes to verify that unique keys or sets of keys are generated for each acquiring organization.
Modified
p. 48 → 62
This requirement refers to the use of a single “base” key to derive master keys for many different POIs, using a key-derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for derivation of other keys once loaded, for example, as done with DUKPT.
This requirement refers to the use of a single “base” key to derive initial keys for many different POIs, using a key-derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for derivation of other keys once loaded, for example, as done with DUKPT.
Modified
p. 48 → 62
20-3.a Examine documented procedures and observe processes for generating master keys. Verify the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:
20-3.a Examine documented procedures and observe processes for generating initial keys. Verify the following is implemented where initial keys are generated by a derivation process and derived from the same Base Derivation Key:
Modified
p. 48 → 62
• Unique data is used for the derivation process such that all transaction-originating POIs receive unique secret keys.
Modified
p. 48 → 62
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.
Removed
p. 49
Different BDKs for each financial institution Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model Different BDKs by geographic region, market segment, platform, or sales unit Injection vendors must use at least one unique Base Derivation Key (BDK) per acquiring organization, and must be able to support segmentation of multiple BDKS of acquiring organizations.
20-4 Determine whether the entity processing or injecting DUKPT or other key-derivation methodologies does so on behalf of multiple acquiring organizations. If so:
Interview personnel and review documented procedures to determine that unique Base Derivation Keys are used for each acquiring organization.
Observe key-injection processes for devices associated with different acquiring organizations to verify that Base Derivation Key(s) unique to each organization are used.
20-4 Determine whether the entity processing or injecting DUKPT or other key-derivation methodologies does so on behalf of multiple acquiring organizations. If so:
Interview personnel and review documented procedures to determine that unique Base Derivation Keys are used for each acquiring organization.
Observe key-injection processes for devices associated with different acquiring organizations to verify that Base Derivation Key(s) unique to each organization are used.
Modified
p. 49 → 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:
Modified
p. 50 → 63
21-1 Secret or private keys must only exist in one or more of the following forms At least two separate key shares or full-length components Encrypted with a key of equal or greater strength as delineated in Annex C Contained within a secure cryptographic device 21-1.a Examine documented procedures for key storage and usage and observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when …
21-1 Secret or private keys must only exist in one or more of the following forms:
• At least two separate key shares (secret or private) or full-length components (secret)
• Encrypted with a key of equal or greater strength as delineated in • Contained within a secure cryptographic device Note: Key-injection facilities may have clear-text keying material outside of a SCD when used within a secure room in accordance with Requirement 32 in Annex B. 21-1.a Examine documented procedures for key …
• At least two separate key shares (secret or private) or full-length components (secret)
• Encrypted with a key of equal or greater strength as delineated in • Contained within a secure cryptographic device Note: Key-injection facilities may have clear-text keying material outside of a SCD when used within a secure room in accordance with Requirement 32 in Annex B. 21-1.a Examine documented procedures for key …
Modified
p. 50 → 63
21-2 Wherever key components are used, they have the following properties:
21-2 Wherever key components/shares are used, they have the following properties:
Modified
p. 50 → 63
21-2 Examine documented procedures and interview responsible personnel to determine all instances where key components are used.
21-2 Examine documented procedures and interview responsible personnel to determine all instances where key components/shares are used.
Modified
p. 50 → 63
21-2.1 Review processes for creating key components to verify that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key.
21-2.1 Examine processes for creating key components/shares to verify that knowledge of any one key component/share does not convey any knowledge of any part of the actual cryptographic key.
Modified
p. 50 → 63
21-2.2 Observe processes for constructing cryptographic keys to verify that at least two key components are required for each key construction.
21-2.2 Observe processes for constructing cryptographic keys to verify that at least two key components/shares are required for each key construction.
Modified
p. 50 → 63
21-2.3.a Examine documented procedures for the use of key components and interview key custodians and key-management supervisory personnel to verify that each key component is assigned to a specific individual, or set of individuals, who are designated as key custodians for that component.
21-2.3.a Examine documented procedures for the use of key components/shares and interview key custodians and key-management supervisory personnel to verify that each key component/share is assigned to a specific individual, or set of individuals, who are designated as key custodians for that component/share.
Modified
p. 50 → 64
21-2.3.b Observe key-component access controls and key-custodian authorizations/assignments to verify that all individuals with access to key components are designated as key custodians for those particular components.
PIN Security Requirements Testing Procedures 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.
Removed
p. 51
21-2.4.a Examine documented procedures for the use of key components to verify that procedures ensure that any custodian never has access to sufficient key components to reconstruct a cryptographic key.
Modified
p. 51 → 64
21-2.4 Procedures exist to ensure that no custodian ever has access to sufficient key components or shares of a secret or private key to reconstruct a cryptographic key.
Modified
p. 51 → 64
For example, in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian must not then be assigned component B or C, as this would give them knowledge of two components, which gives them ability …
For example, in an m-of-n scheme (which must use a recognized secret- sharing scheme such as Shamir), where only two of any three shares are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one share. If a custodian was previously assigned share A, which was then reassigned, the custodian must not then be assigned share B or C, as this would give them knowledge of two shares, which gives them …
Modified
p. 51 → 64
In an m-of-n scheme where n=5 and where three components are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key components (for example, component A and component B), as a second custodian (with, in this example, component C) would be required to reconstruct the final key, ensuring that dual control is maintained.
In an m-of-n scheme where n=5 and where three shares are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key shares (for example, share A and share B); and a second custodian (with, in this example, share C) would be required to reconstruct the final key, ensuring that dual control is maintained 21-2.4.a Examine documented procedures for the use of key components/shares to verify that procedures ensure that any …
Modified
p. 51 → 64
21-2.4.b Examine key-component access controls and access logs to verify that authorized custodians cannot access sufficient key components to reconstruct a cryptographic key.
21-2.4.b Examine key-component/share access controls and access logs to verify that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key.
Modified
p. 51 → 64
21-3 Key components must be stored as follows: 21-3 Examine documented procedures, interview responsible personnel, and inspect key-component storage locations to verify that key components 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. 52 → 65
PIN Security Requirements Testing Procedures 21-3.1 Key components that exist in clear text outside of an SCD must be sealed in opaque, pre-numbered tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.
PIN Security Requirements Testing Procedures 21-3.1 Key components that exist in clear text outside of an SCD must be sealed in individual opaque, pre-numbered, tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.
Modified
p. 52 → 65
Note: Tamper-evident, authenticable packaging
•opacity may be envelopes within tamper-evident packaging
•used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card,contactless card, or other media that can be read without direct physical contact, the packaging should be …
•opacity may be envelopes within tamper-evident packaging
•used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card,
Note: Tamper-evident, authenticable packaging
•opacity may be envelopes within tamper-evident packaging
•used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card, or other media that can be read without direct physical contact, the packaging should be designed to …
•opacity may be envelopes within tamper-evident packaging
•used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card, or other media that can be read without direct physical contact, the packaging should be designed to …
Modified
p. 52 → 65
21-3.1.a Examine key components and storage locations to verify that components are stored in 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 opaque, pre-numbered, tamper-evident packaging that prevents the determination of the key component without noticeable damage to the packaging.
Modified
p. 52 → 65
21-3.1.b Inspect any tamper-evident packaging used to secure key components and ensure that it prevents the determination of the key component without visible damage to the packaging.
21-3.1.b Inspect any tamper-evident packaging used to secure key components •e.g., is the package sufficiently opaque to prevent reading of a component
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
Modified
p. 52 → 65
21-3.1.c Ensure clear-text key components do not exist in any other locations, including in non-secure containers, in databases, on floppy disks, or in software programs.
21-3.1.c Ensure clear-text key components do not exist in non-secure containers such as databases or in software programs.
Modified
p. 52 → 65
21-3.2 Key components for each specific custodian must be stored in a separate, secure container that is accessible only by the custodian and/or designated backup(s).
21-3.2 Key components/shares for each specific custodian must be stored in a separate, secure container that is accessible only by the custodian and/or designated backup(s).
Modified
p. 52 → 65
Components/shares for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers.
Modified
p. 52 → 65
21-3.2 Inspect each key component storage container and verify the following:
21-3.2 Inspect each key component/share storage container and verify the following:
Modified
p. 52 → 65
• Key components/shares for different custodians are stored in separate secure containers.
Modified
p. 52 → 65
• Each secure container is accessible only by the custodian and/or designated backup(s).
Modified
p. 52 → 65
21-3.3 If a key component is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner (or designated backup(s)) must have possession of both the token and its access code.
21-3.3 If a key component/share is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner⎯or designated backup(s)⎯must have possession of both the token and its access code.
Modified
p. 53 → 66
Requirement 22: Procedures must exist and must be demonstrably in use to replace any known or suspected compromised key, its subsidiary keys (those keys encrypted with the compromised key), and keys derived from the compromised key, to a value not feasibly related to the original key.
Requirement 22: Procedures must exist and must be demonstrably in use to replace any key determined to be compromised, its subsidiary keys (those keys encrypted with the compromised key), and keys derived from the compromised key, to values not feasibly related to the original keys.
Modified
p. 53 → 66
22-1.1 Key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.
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. 53 → 66
22-1.1 Interview responsible personnel and observe implemented processes to verify key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.
22-1.1 Interview responsible personnel and observe implemented processes to verify 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. 53 → 66
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 …
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. 53 → 66
Known or suspected substitution of a secret key must result in the replacement of that key and any associated key-encipherment keys.
Known or suspected substitution of a secret key must result in the replacement of that key and based on an analysis of how the key was substituted, any associated key-encipherment keys that may have been compromised.
Modified
p. 53 → 66
• Use of that key is halted, and the key is replaced with a new unique key.
Modified
p. 53 → 66
• 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. 53 → 66
• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key.
Removed
p. 54
Missing secure cryptographic devices Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 22-1.5 Interview responsible personnel and review documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
Modified
p. 54 → 67
• Specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Modified
p. 54 → 67
22-1.4.a Interview responsible personnel and review documented procedures to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
22-1.4.a Interview responsible personnel and examine documented procedures to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
Modified
p. 54 → 67
• A damage assessment including, where necessary, the engagement of outside consultants.
Modified
p. 54 → 67
• Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Modified
p. 54 → 67
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 22-2 If attempts to load a secret key or key component into an KLD or POI fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original …
Modified
p. 55 → 68
23-1 Any key generated with a reversible process (such as a variant of a key) of another key must be protected in the same manner as the original key•that is, under the principles of dual control and split knowledge. Variants of the same key may be used for different purposes, but must not be used at different levels of the key hierarchy. For example, reversible transformations must not generate key-encipherment keys from PIN keys.
23-1 Any key generated with a reversible process (such as a variant of a key) of another key must be protected in the same manner as the original key•that is, under the principles of dual control and split knowledge. Variants of the same key may be used for different purposes but must not be used at different levels of the key hierarchy. For example, reversible transformations must not generate key-encipherment keys from PIN keys.
Modified
p. 55 → 68
23-2.b Review vendor documentation to determine support for key variants.
23-2.b Examine vendor documentation to determine support for key variants.
Modified
p. 55 → 68
23-2.c Via review of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys used, determine that variants of the MFK are not used external to the logical configuration that houses the MFK.
23-2.c Via examination of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys used, determine that variants of the MFK are not used external to the logical configuration that houses the MFK.
Modified
p. 56 → 69
Such transformations are only used to generate different types of key- encrypting keys from an initial key-encrypting key, or working keys with different purposes from another working key.
Such transformations are only used to generate different types of key- encrypting keys from an initial key-encrypting key or working keys with different purposes from another working key.
Modified
p. 56 → 69
Note: Using transforms of keys across different levels of a key hierarchy
•for example, generating a PEK from a key-encrypting key
•for example, generating a PEK from a key-encrypting key
Note: Using transformations of keys across different levels of a key hierarchy
•for example, generating a PEK from a key-encrypting key
•for example, generating a PEK from a key-encrypting key
Modified
p. 56 → 69
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as a PIN key, MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key- encrypting keys.
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as a PIN key, MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key-encrypting keys.
Modified
p. 56 → 69
• Variants used as KEKs must only be calculated from other key- encrypting keys.
Modified
p. 56 → 69
• Variants of working keys must only be calculated from other working keys.
Modified
p. 56 → 69
24-1.c Review storage locations for the sample of destroyed keys to verify they are no longer kept.
24-1.c Examine storage locations for the sample of destroyed keys to verify they are no longer kept.
Removed
p. 57
PIN Security Requirements Testing Procedures 24-2 The procedures for destroying keys or key components that are no longer used or that 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. This must be accomplished by use of a cross-cut shredder, pulping or burning. Strip-shredding is not sufficient.
Modified
p. 57 → 70
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. 57 → 70
24-2.3 Key components for keys other than the HSM MFK that have been successfully loaded and confirmed as operational must also be destroyed, unless the HSM does not store the encrypted values on a DB 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.
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 DB 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.
Removed
p. 58
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date for the custodian’s access Signature of management authorizing the access 25-1.3 Examine all key-custodian forms to verify that they include the following:
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date for the custodian’s access Signature of management authorizing the access
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date for the custodian’s access Signature of management authorizing the access
Modified
p. 58 → 71
25-1.1 Review key-custodian assignments for each component to verify that:
25-1.1 Examine key-custodian assignments for each component to verify that:
Modified
p. 58 → 71
• Key custodian(s) are designated for each component.
Modified
p. 58 → 71
• The fewest number of key custodians is assigned as necessary to enable effective key management.
Modified
p. 58 → 71
• Assigned key custodians are employees or contracted personnel.
Modified
p. 59 → 72
Organizations that are of such insufficient size that they cannot support the reporting-structure requirement must ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian), receive explicit training to instruct them from sharing key components with their direct manager, and must sign key-custodian agreements that includes an attestation to the requirement.
Organizations that are of insufficient size that they cannot support the reporting-structure requirement must:
• Ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian);
• Receive explicit training to instruct them from sharing key components with their direct manager;
• Sign key-custodian agreements that include an attestation to the requirement; and
• Receive training that includes procedures to report any violations.
• Ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian);
• Receive explicit training to instruct them from sharing key components with their direct manager;
• Sign key-custodian agreements that include an attestation to the requirement; and
• Receive training that includes procedures to report any violations.
Modified
p. 59 → 72
• Key custodians that form the necessary threshold to create a key do not directly report to the same individual.
Modified
p. 59 → 72
• Neither direct reports nor the direct reports in combination with their immediate supervisors possess the necessary threshold of key components sufficient to form any given key.
Modified
p. 59 → 72
• Ensure training includes whistleblower procedures to report any violations.
• Ensure training includes procedures to report any violations.
Removed
p. 60
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable) 26-1.a Review log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable)
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable)
Modified
p. 60 → 73
• Loaded to an SCD 26-1.b Examine log files and audit log settings to verify that logs include the following:
Modified
p. 60 → 74
27-1 If backup copies of secret and/or private keys exist, confirm that they are maintained in accordance with the same requirements as are followed for the primary keys.
27-1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as are followed for the primary keys.
Modified
p. 60 → 74
• Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys.
Modified
p. 60 → 74
• Inspect backup storage locations and access controls or otherwise verify through examination of documented procedures and interviews of personnel that backups are maintained as follows:
Removed
p. 61
PIN Security Requirements Testing Procedures 27-2 If backup copies are created, the following must be in place:
Modified
p. 61 → 74
• Creation (including cloning) of top-level keys, e.g., MFKs, must require a minimum of two authorized individuals to enable the process.
Modified
p. 61 → 74
• The creation of any backup copies for top-level keys requires at least two authorized individuals to enable the process.
Modified
p. 61 → 75
• Management of personnel changes, including revocation of access control and other privileges when personnel move 28-1.a Examine documented procedures for key-administration operations to verify they include:
Modified
p. 61 → 75
• Management of personnel changes, including revocation of access control and other privileges when personnel move 28-1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
Removed
p. 62
29-1.1 Controls must be implemented to protect POIs and other SCDs from unauthorized access up to point of deployment.
Modified
p. 62 → 76
29-1.a Review documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys:
29-1.a Examine documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys:
Modified
p. 62 → 76
29-1.1 Review documented procedures to verify controls are defined to protect POIs and other SCDs from unauthorized access up to point of deployment.
29-1.1 Examine documented procedures to verify controls are defined to protect POIs and other SCDs from unauthorized access up to point of deployment.
Removed
p. 63
PIN Security Requirements Testing Procedures 29-1.1.2 POIs and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords.
29-1.1.2 Examine vendor documentation or other information sources to identify default keys (such as keys that are pre-installed for testing purposes), passwords, or data. Observe implemented processes and interview personnel to verify that default keys or passwords are not used.
All personnel with access to POIs and other SCDs are authorized by management.
29-1.1.2 Examine vendor documentation or other information sources to identify default keys (such as keys that are pre-installed for testing purposes), passwords, or data. Observe implemented processes and interview personnel to verify that default keys or passwords are not used.
All personnel with access to POIs and other SCDs are authorized by management.
Modified
p. 63 → 77
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 specifies 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.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.
Modified
p. 63 → 77
• All personnel with access to POIs and other SCDs are authorized by management in an auditable manner.
Modified
p. 63 → 77
• The authorizations are reviewed annually.
Modified
p. 63 → 77
29-1.1.3.b For a sample of POIs and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in the formal list have access to devices.
29-1.1.3.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. 63 → 77
29-2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt through to placement into service.
29-2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt to placement into service.
Modified
p. 63 → 77
29-2.b For a sample of devices, review documented records and interview responsible personnel to verify the chain of custody is maintained from receipt to placement into service.
29-2.b For a sample of devices, examine documented records and interview responsible personnel to verify the chain of custody is maintained from receipt to placement into service.
Modified
p. 64 → 78
• 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. 64 → 78
• 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. 64 → 78
• A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. The SCD used for key-insertion verifies the presence of the correct “transport-protection token” before overwriting this value with the initial key, and the device is further protected until deployment.
Modified
p. 64 → 78
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. 64 → 79
• Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been subject to any unauthorized access or modifications.
Modified
p. 64 → 79
− Controls exist and are in use to ensure that all physical and logical controls and anti-tamper mechanisms used are not modified or removed.
Removed
p. 65
29-4.c Determine the adequacy of those controls in enforcing dual control.
Modified
p. 65 → 79
•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
•both deployed and spare or back-up devices
Modified
p. 65 → 80
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.
PIN Security Requirements Testing Procedures 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. 65 → 80
29-4.1.b For a sample of received devices, review sender documentation sent via a different communication channel than the device’s shipment (for example, the manufacturer’s invoice or similar documentation) used to verify device serial numbers. Examine the record of serial-number validations to confirm the serial number for the received device was verified to match that documented by the sender.
29-4.1.b For a sample of received devices, examine sender documentation sent via a different communication channel than the device’s shipment (for example, the manufacturer’s invoice or similar documentation) used to verify device serial numbers. Examine the record of serial-number validations to confirm the serial number for the received device was verified to match that documented by the sender.
Modified
p. 65 → 80
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 in PIN-processing equipment to support specified functionality must be disabled before the equipment is commissioned.
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. 65 → 80
Requirement 3, or non-ISO PIN-block formats must not be supported without a defined documented and approved business need.
Modified
p. 65 → 80
HSMs used for acquiring functions shall not be configured to output clear-text PINs.
• HSMs used for acquiring functions shall not be configured to output clear-text PINs or support PIN-change functionality.
Modified
p. 65 → 80
29-4.2.a Obtain and review the defined security policy to be enforced by the HSM.
29-4.2.a Obtain and examine the defined security policy to be enforced by the HSM.
Modified
p. 65 → 80
29-4.2.b Examine documentation of the HSM configuration settings to determine that the functions and command authorized to be enabled are in accordance with the security policy.
29-4.2.b Examine documentation of the HSM configuration settings from past commissioning events to determine that the functions and commands enabled are in accordance with the security policy.
Modified
p. 65 → 80
29-4.2.c For a sample of HSMs, review the configuration settings to determine that only authorized functions are enabled.
29-4.2.c For a sample of HSMs, examine the configuration settings to determine that only authorized functions are enabled.
Modified
p. 65 → 80
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. 66 → 81
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. 67 → 82
Requirement 30: Physical and logical protections must exist for deployed POI devices 30.1 POI devices must be secured throughout the device lifecycle. The responsible entity must:
Requirement 30: Physical and logical protections must exist for deployed POI devices 30-1 POI devices must be secured throughout the device lifecycle. The responsible entity must:
Modified
p. 67 → 82
• Maintain inventory-control and monitoring procedures to accurately track POI devices in their possession.
Modified
p. 67 → 82
• Physically secure POI devices awaiting deployment or otherwise not in use.
Modified
p. 67 → 82
• Implement procedures to prevent and detect the unauthorized alteration or replacement of POI devices in possession during deployment.
Modified
p. 67 → 82
• 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. 67 → 82
• Prevent unauthorized physical access to devices undergoing repair or maintenance while in their possession.
Modified
p. 67 → 82
30-1.a Obtain and examine documentation of inventory control and monitoring procedures. Determine that the procedures cover:
Modified
p. 67 → 82
• Physically securing POI devices when awaiting deployment or otherwise not in use.
Modified
p. 67 → 82
• The prevention and detection of the unauthorized alteration or replacement of POI devices during deployment.
Modified
p. 67 → 82
• Ensuring that POI devices are physically secured or otherwise controlled to prevent unauthorized access, modification, or substitution while devices are deployed for use, including both attended and unattended devices (for example, kiosks, “pay-at-the-pump,” etc.).
Modified
p. 67 → 82
• Preventing unauthorized physical access to devices undergoing repair or maintenance while in their possession.
Modified
p. 67 → 82
30-1.b Interview applicable personnel to determine that procedures are known and followed.
Modified
p. 67 → 82
• Securely maintain POI devices being returned, replaced, or disposed of, and provide related instructions to third-party providers performing this service.
Modified
p. 67 → 82
• Protect POI devices from known vulnerabilities and implement procedures for secure updates to devices.
Modified
p. 67 → 82
• Provide auditable logs of any changes to critical functions of the POI device(s).
Modified
p. 67 → 82
• Define and implement procedures for merchants on detecting and reporting tampered POI devices, including missing devices.
Modified
p. 67 → 82
• Implement mechanisms to monitor and respond to suspicious activity on POI devices deployed at merchant locations.
Modified
p. 67 → 82
• Securely maintaining devices being returned, replaced, or disposed of, along with related instructions to third-party providers performing this service.
Modified
p. 67 → 82
• Protecting POI devices from known vulnerabilities and implementing procedures for secure updates to devices.
Modified
p. 67 → 82
• Providing for auditable logs of any changes to critical functions of the POI device(s).
Modified
p. 67 → 82
• Defined, implemented procedures for merchants on detecting and reporting tampered POI devices, including missing devices.
Modified
p. 67 → 82
• Implementing mechanisms to monitor and respond to suspicious activity on POI devices deployed at merchant locations.
Modified
p. 68 → 83
31-1 Procedures are in place to ensure that any SCDs to be removed from service
•e.g., retired or returned for repair
•are not intercepted or used in an unauthorized manner, includingthat all keys and key material stored within the device must be rendered irrecoverable.
•e.g., retired or returned for repair
•are not intercepted or used in an unauthorized manner, including
31-1 Procedures are in place to ensure that any SCDs to be removed from service
•e.g., retired or returned for repair
•are not intercepted or used in an unauthorized manner, including rendering all secret and private keys and key material stored within the device irrecoverable.
•e.g., retired or returned for repair
•are not intercepted or used in an unauthorized manner, including rendering all secret and private keys and key material stored within the device irrecoverable.
Modified
p. 68 → 83
• Procedures require that all secret and private keys and key material stored within the device be securely destroyed.
Modified
p. 68 → 83
• Procedures cover all devices removed from service or for repair.
Modified
p. 68 → 83
31-1.1.a Review documented procedures for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes.
31-1.1.a Examine documented procedures for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes.
Modified
p. 68 → 83
31-1.2 Key are rendered irrecoverable (for example, zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual-control to prevent the disclosure of any sensitive data or keys.
31-1.2 Key are rendered irrecoverable (for example, zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.
Modified
p. 69 → 85
32-1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
PIN Security Requirements Testing Procedures 32-1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
Modified
p. 69 → 85
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, 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, or for physical access via a physical lock that requires two individuals, each with a different high-security key.
Modified
p. 69 → 85
For devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian.
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.
Modified
p. 69 → 85
Physical keys, authorization codes, passwords, or other enablers must be managed so that no one person can use both the enabler(s) and the device, which can create cryptograms of known keys or key components under a key-encipherment key used in production.
Physical keys, authorization codes, passwords/authentication codes, or other enablers must be managed so that no one person can use both the enabler(s) and the device, which can create cryptograms of known keys or key components under a key-encipherment key used in production.
Modified
p. 70 → 85
32-1.2 Passwords/authentication codes used for dual control must each be of at least five numeric and/or alphabetic characters.
Modified
p. 70 → 85
32-1.2 Observe password policies and configuration settings to confirm that passwords 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 32-1.3 Dual control must be implemented for the following:
Modified
p. 70 → 85
• To enable any manual key-encryption functions and any key- encryption functions that occur outside of normal transaction processing;
Modified
p. 70 → 85
• To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing;
Modified
p. 70 → 86
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.
Modified
p. 70 → 86
32-1.4.b Observe device configurations and interview device administrators to verify that HSMs, KLDs, and other SCDs used to generate or load cryptographic keys do not use default passwords.
32-1.4.b Observe device configurations and interview device administrators to verify that HSMs, KLDs, and other SCDs used to generate or load cryptographic keys do not use default passwords/authentication codes.
Modified
p. 70 → 86
• Under the continuous supervision of at least two authorized people who ensure that any unauthorized use of the device would be detected.
Removed
p. 72
A1
• Remote Key-Distribution Using Asymmetric Techniques Operations: Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key distribution using asymmetric techniques A2
• Certification and Registration Authority Operations: Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
• Remote Key-Distribution Using Asymmetric Techniques Operations: Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key distribution using asymmetric techniques A2
• Certification and Registration Authority Operations: Operations of Certification and Registration Authority platforms used in connection with remote key-distribution implementations. These requirements apply only to the entities operating Certification and/or Registration Authorities.
Modified
p. 72 → 87
• Certification Authority requirements apply to all entities (acquirers, manufacturers, and other third parties) signing public keys to be used for remote distribution of cryptographic keys, whether in X.509 certificate-based schemes or other designs, to allow for the required authentication of these signed public keys. For purposes of these requirements, a certificate is any digitally signed value containing a public key, where the term “digitally signed” refers to a cryptographic method used that enforces the integrity and authenticity of a …
Modified
p. 72 → 87
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates.
• The Certification Authority requirements are not intended to be applied to devices that sign their own keys, nor to key-loading systems where the key loading is not performed remotely, and authentication is provided by another method
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates.
•such as properly implemented dual control and key-loading device(s)
•even if these systems involve the use of certificates.
Modified
p. 72 → 87
The control objectives and security requirements are delineated as found in the preceding “PIN Security Requirement
• Technical Reference” section of thisdocument, and are in addition to requirements for those entities performing transaction processing.
• Technical Reference” section of this
The control objectives and security requirements are delineated as found in the preceding “PIN Security Requirement
• Technical Reference” section of this document and are in addition to requirements for those entities performing transaction processing.
• Technical Reference” section of this document and are in addition to requirements for those entities performing transaction processing.
Modified
p. 73 → 88
10-2 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed.
10-2 All key-encryption keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed except as noted in Requirement 10-1.
Modified
p. 73 → 88
10-2 Examine documented procedures to verify that all asymmetric keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed.
10-2 Examine documented procedures to verify that all keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed except as noted in Requirement 10-1.
Modified
p. 73 → 88
10-3 Key sizes and algorithms must be in accordance with Annex C. 10-3 Observe key-generation processes to verify that all asymmetric keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed.
10-3 Key sizes and algorithms must be in accordance with Annex C except as noted in Requirement 10-1.
Modified
p. 74 → 89
Note: Examples of this kind of validation include checking current certificate revocation lists or embedding valid authorized KDH certificates in devices and disallowing communication with unauthorized KDHs, as delineated by techniques defined in the Technical FAQs for PCI PTS POI Security Requirements.
Note: Examples of this kind of validation include ensuring the SCD serial number is listed in a table of "permitted" devices, checking current certificate revocation lists or embedding valid authorized KDH certificates in devices, and disallowing communication with unauthorized KDHs, as delineated by techniques defined in the Technical FAQs for PCI PTS POI Security Requirements.
Modified
p. 74 → 89
• POI devices must validate authentication credentials of KDHs prior to any key transport, exchange, or establishment with that device.
Modified
p. 74 → 89
• KDHs must validate authentication credentials of POIs prior to any key transport, exchange, or establishment with that device.
Modified
p. 74 → 89
• POI devices validate authentication credentials of KDHs immediately prior to any key transport, exchange, or establishment with that device.
Modified
p. 74 → 89
• KDHs validate authentication credentials of POIs immediately prior to any key transport, exchange, or establishment with that device.
Modified
p. 74 → 89
15-4 Key-establishment and distribution procedures must be designed such that:
Modified
p. 74 → 89
• Within an implementation design, there shall be no means available for “man-in-the-middle” attacks•e.g., through binding of the KDH certificate upon the initial communication.
Modified
p. 74 → 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.
Modified
p. 74 → 89
15-4 Examine system and process documentation to verify that key- establishment and distribution procedures are designed such that:
Modified
p. 74 → 89
• There are no means available in the implementation design for “man- in-the-middle” attacks.
Modified
p. 74 → 89
• System implementations are designed to prevent replay attacks.
Modified
p. 74 → 90
PIN Security Requirements Testing Procedures 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 …
Modified
p. 74 → 90
15-5 If key pairs are generated external to the device that uses the key pair, perform the following:
Modified
p. 74 → 90
• Examine documented procedures to verify that controls are defined to ensure the secrecy of private keys and the integrity of public keys during key transfer and loading.
Modified
p. 74 → 90
• Observe key transfer and loading operations to verify that the secrecy of private keys and the integrity of the public keys are ensured.
Modified
p. 74 → 90
• Verify the process ensures that key pairs are unique per POI device.
Modified
p. 75 → 90
• POIs only communicate with CAs for the purpose of certificate signing, or for key injection where the certificate-issuing authority generates the key pair on behalf of the device;
Modified
p. 75 → 91
18-4.b Interview responsible personnel and observe POI configurations to verify that:
PIN Security Requirements Testing Procedures 18-4.b Interview responsible personnel and observe POI configurations to verify that:
Modified
p. 75 → 91
• POIs only communicate with CAs for the purpose of certificate signing, or for key-injection where the certificate issuing authority generates the key pair on behalf of the device;
Modified
p. 75 → 91
• KDHs only to communicate with CAs for the purpose of certificate signing and certificate (entity) status checking.
Modified
p. 75 → 91
• KDHs only communicate with CAs for the purpose of certificate signing and certificate (entity) status checking.
Modified
p. 76 → 92
PIN Security Requirements Testing Procedures 19-6.b Interview responsible personnel and observe certificate issuing and replacement processes to verify that:
Modified
p. 76 → 92
• Only one certificate is requested for each key pair generated.
Modified
p. 76 → 92
• Certificates are replaced by generating a new key pair and requesting a new certificate.
Modified
p. 76 → 92
• Each key pair generated results in only one certificate.
Modified
p. 77 → 93
• Within a secure cryptographic device that meets applicable PCI PTS requirements for such a device,
Modified
p. 78 → 94
15-5 If key pairs are generated external to the device that uses the key pair, perform the following:
Modified
p. 78 → 94
• Examine documented procedures to verify that controls are defined to ensure the secrecy of private keys and the integrity of public keys during key transfer and loading.
Modified
p. 78 → 94
• Observe key transfer and loading operations to verify that the secrecy of private keys and the integrity of the public keys are ensured.
Modified
p. 78 → 94
• Verify the process ensures that key pairs are unique per POI device.
Modified
p. 78 → 94
10-4 All key-encryption keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed.
Modified
p. 78 → 94
10-4 Examine documented procedures to verify that all keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed.
Modified
p. 78 → 94
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. 78 → 94
Control Objective 4: Key-loading to hosts and PIN entry devices is handled in a secure manner.
Control Objective 4: Key-loading to HSMs and POI PIN-acceptance devices is handled in a secure manner.
Modified
p. 78 → 94
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. 79 → 95
• Only one certificate is requested for each key pair generated.
Modified
p. 79 → 95
• Certificates are replaced by generating a new key pair and requesting a new certificate.
Modified
p. 79 → 95
• Each key pair generated results in only one certificate.
Modified
p. 79 → 95
• All keying material must be deleted from the HSM(s) and the server/computer platforms prior to testing.
Modified
p. 79 → 95
• 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. 79 → 95
• Prior to reuse for production purposes, the HSM is returned to factory state.
Modified
p. 79 → 95
• The relevant production keying material is restored using the principles of dual control and split knowledge as stated in these requirements.
Modified
p. 79 → 95
• Each key pair generated results in only one certificate 19-6.b Interview responsible personnel, examine records of past KDH-signing requests, and observe certificate issuing and replacement processes to verify that:
Removed
p. 80
Subordinate entity certificate requests, Certificate status checking, and/or Self-signed root certificates.
Modified
p. 80 → 96
• Signature keys for updating valid/authorized host lists in POIs Are not used for any purpose other than:
Modified
p. 80 → 96
• Certificate signature keys,
• Certificate status checking (for example, Certificate Revocation Lists) signature keys, or
• Subordinate entity certificate requests, • Certificate status checking, and/or • Self-signed root certificates.
• Certificate status checking (for example, Certificate Revocation Lists) signature keys, or
• Subordinate entity certificate requests, • Certificate status checking, and/or • Self-signed root certificates.
Modified
p. 80 → 96
• Signature keys for updating valid/authorized host lists in POIs Are not used for any purpose other than:
Modified
p. 80 → 96
19-9.2 CAs that issue certificates to other CAs must not be used to issue certificates to POIs.
19-9.2 CAs that issue certificates to other CAs must not be used to issue certificates to POIs⎯i.e., a CA cannot sign certificates to both subordinate CAs and end-entity (POI) devices.
Modified
p. 81 → 99
• Within a secure cryptographic device that meets applicable PCI requirements for such a device,
Modified
p. 81 → 99
Requirement 22: Procedures must exist and be demonstrably in use to replace any known or suspected compromised key and its subsidiary keys (those keys enciphered with the compromised key) to a value not feasibly related to the original key.
Requirement 22: Procedures must exist and be demonstrably in use to replace any key determined to be compromised and its subsidiary keys (those keys enciphered with the compromised key) to values not feasibly related to the original keys.
Modified
p. 81 → 99
22-3 Root CAs must provide for segmentation of risk to address key compromise. An example of this would be the implementation of subordinate CAs.
Modified
p. 81 → 99
22-3 Through the examination of documented procedures, interviews and observation confirm that Root CAs provide for segmentation of risk to address key compromise.
Modified
p. 82 → 99
22-4 Mechanisms must be in place to respond to address compromise of a CA due to, for example, key compromise or mismanagement. This must include procedures to revoke or otherwise invalidate the usage of subordinate certificates, and notification of affected entities.
Modified
p. 82 → 99
22-4.a Examine documented procedures to verify that mechanisms are defined to respond to compromise of a CA. Verify the mechanisms include procedures to:
Modified
p. 82 → 99
• Revoke subordinate certificates, and
Modified
p. 82 → 99
22-4.b Interview responsible personnel to verify that the defined mechanisms to respond to compromise of a CA are in place and include:
Modified
p. 82 → 99
• Revoking subordinate certificates, and
Modified
p. 82 → 100
PIN Security Requirements Testing Procedures 22-4.1 The CA must cease issuance of certificates if a compromise is known or suspected and perform a damage assessment, including a documented analysis of how and why the event occurred.
Modified
p. 82 → 100
22-4.1.a Examine documented procedures to verify that the following are required in the event a compromise is known or suspected:
Modified
p. 82 → 100
• The CA will cease issuance of certificates.
Modified
p. 82 → 100
• The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.
Modified
p. 82 → 100
22-4.1.b Interview responsible personnel and observe process to verify that in the event a compromise is known or suspected:
Modified
p. 82 → 100
• The CA ceases issuance of certificates.
Modified
p. 82 → 100
• The CA performs a damage assessment, including a documented analysis of how and why the event occurred.
Modified
p. 82 → 100
22-4.2 In the event of a confirmed compromise, the CA must determine whether to revoke and reissue all signed certificates with a newly generated signing key.
Modified
p. 82 → 100
22-4.2.a Examine documented procedures to verify that in the event of a confirmed compromise, procedures are defined for the CA to determine whether to revoke and reissue all signed certificates with a newly generated signing key.
Modified
p. 82 → 100
22-4.2.b Interview responsible personnel to verify procedures are followed for the CA to determine whether to revoke and reissue all signed certificates with a newly generated signing key.
Modified
p. 83 → 101
PIN Security Requirements Testing Procedures 22-7.3 Mechanisms (for example, time stamping) must exist to prevent the usage of fraudulent certificates, once identified.
PIN Security Requirements Testing Procedures 22-4.3 Mechanisms (for example, time stamping) must exist to prevent the usage of fraudulent certificates, once identified.
Modified
p. 83 → 101
22-4.3.a Examine documented procedures to verify that mechanisms are defined to prevent the usage of fraudulent certificates.
Modified
p. 83 → 101
22-4.3.b Interview responsible personnel and observe implemented mechanisms to verify the prevention of the use of fraudulent certificates 22-4.4 The compromised CA must notify any superior or subordinate CAs of the compromise. The compromise damage analysis must include a determination of whether subordinate CAs and KDHs must have their certificates reissued and distributed to them or be notified to apply for new certificates.
Modified
p. 83 → 101
22-4.4.a Examine documented procedures to verify that the following procedures are required in the event of a compromise:
Modified
p. 83 → 101
• The CA will notify any superior CAs.
Modified
p. 83 → 101
• The CA will notify any subordinate CAs.
Modified
p. 83 → 101
• The CA will perform a damage assessment to determine the need to − Reissue and distribute certificates to affected parties, or − Notify the affected parties to apply for new certificates.
Modified
p. 83 → 101
22-4.4.b Interview responsible personnel to verify that the following procedures are performed in the event a compromise:
Modified
p. 83 → 101
• The CA notifies any superior CAs.
Modified
p. 83 → 101
• The CA notifies any subordinate CAs.
Modified
p. 83 → 101
− Reissues and distributes certificates to affected parties, or − Notifies the affected parties to apply for new certificates.
Modified
p. 84 → 102
PIN Security Requirements Testing Procedures 22-8 Minimum cryptographic strength for the CA system shall be:
PIN Security Requirements Testing Procedures 22-5 Minimum cryptographic strength for the CA system shall be:
Modified
p. 84 → 102
• Root and subordinate CAs have a minimum RSA 2048 bits or equivalent;
Modified
p. 84 → 102
• KDH devices have a minimum RSA 2048 bits or equivalent.
Modified
p. 84 → 102
22-5.a Interview appropriate personnel and examine documented procedures for the creation of these keys.
Modified
p. 84 → 102
22-5.b Verify that the following minimum key sizes exist for RSA keys or the equivalent for the algorithm used as defined in Annex C:
Modified
p. 84 → 102
• 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.
Modified
p. 84 → 102
25-2 All user access to material that can be used to construct secret and private keys (such as key components) must be directly attributable to an individual user (for example, through the use of unique IDs).
25-2 All user access to material that can be used to construct secret and private keys (such as key components or key shares used to reconstitute a key) must be directly attributable to an individual user⎯for example, through the use of unique IDs.
Modified
p. 85 → 103
• The network must only be used for certificate issuance and/or revocation.
Modified
p. 85 → 103
• Outside network access (e.g., using a separate platform in the DMZ) shall exist only for the purposes of “pushing” certificate- status information to relying parties (e.g., example, KDHs).
Modified
p. 85 → 103
• CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment).
Modified
p. 85 → 103
• The network is only used for certificate issuance, revocation, or both certificate issuance and revocation.
Modified
p. 85 → 103
• Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (for example, KDHs).
Modified
p. 85 → 103
25-3.2 CA or Registration Authority (RA) software updates must not be done over the network (local console access must be used for CA or RA software updates).
25-3.2 For CAs operated online•e.g., POI-signing CAs: CA or Registration Authority (RA) software updates must not be done over the network (local console access must be used for CA or RA software updates).
Modified
p. 85 → 103
25-3.3 Non-console access must use two-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. 85 → 103
25-3.3 Examine remote-access mechanisms and system configurations to verify that all non-console access, including remote access, requires two- 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. 85 → 103
25-3.4 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 host 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. 86 → 104
• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) 25-4.b Observe CA operations and interview responsible personnel to verify:
Modified
p. 86 → 104
• Multi-person control for operational procedures such that no one person can gain control over the CA signing key(s) 25-5 All CA systems that are not operated exclusively offline must be hardened to prevent insecure network access, to include:
Modified
p. 86 → 104
• Services that are not necessary or that allow non-secure access (for example, rlogin, rshell, telnet, ftp, etc.) must be removed or disabled.
Modified
p. 86 → 104
• Unnecessary ports must also be disabled.
Modified
p. 86 → 104
• Unnecessary ports must also be disabled.
Modified
p. 86 → 104
• Documentation must exist to support the enablement of all active services and ports.
Modified
p. 86 → 104
• Documentation must exist to support the enablement of all active services and ports.
Modified
p. 86 → 104
• Services that are not necessary or that allow non-secure access (for example, rlogin, rshell, etc., commands in UNIX) must be removed or disabled.
Modified
p. 86 → 104
• Services that are not necessary or that allow non-secure access (for example, rlogin, rshell, etc., commands in UNIX) are removed or disabled.
Modified
p. 86 → 104
• Unnecessary ports are disabled.
Modified
p. 86 → 104
• There is documentation to support all active services and ports.
Modified
p. 87 → 105
Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades must only be enabled when required and otherwise must be disabled from login.
Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades must only be enabled when necessary and otherwise must be disabled from login.
Modified
p. 87 → 105
• Vendor-default IDs are changed, removed, or disabled unless necessary for a documented and specific business reason.
Modified
p. 87 → 105
• Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades are only be enabled when required and otherwise must be disabled from login.
Modified
p. 87 → 105
• Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades are only be enabled when required and otherwise must be disabled from login.
Modified
p. 87 → 105
• Vendor-default IDs are changed, removed or disabled unless necessary for a documented and specific business reason.
Modified
p. 87 → 105
• All key-management operations
•such as key generation, loading, transmission, backup, recovery, compromise, destruction, and certificate generation or revocation • The identity of the person authorizing the operation • The identities of all persons handling any key material (such as key components or keys stored in portable devices or media) • Protection of the logs from alteration and destruction 25-6.a Examine system configurations and audit trails to verify that all key- management operations are logged.
•such as key generation, loading, transmission, backup, recovery, compromise, destruction, and certificate generation or revocation • The identity of the person authorizing the operation • The identities of all persons handling any key material (such as key components or keys stored in portable devices or media) • Protection of the logs from alteration and destruction 25-6.a Examine system configurations and audit trails to verify that all key- management operations are logged.
Modified
p. 87 → 105
• The identity of the person authorizing the operation • The identities of all persons handling any key material • Mechanisms exist to protect logs from alteration and destruction
Modified
p. 89 → 107
25-7.b Review 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 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.
Modified
p. 89 → 107
• Deny all services not explicitly permitted.
Modified
p. 89 → 107
• Deny all services not explicitly permitted.
Modified
p. 89 → 107
• Disable or remove all unnecessary services, protocols, and ports.
Modified
p. 89 → 107
• Disable or remove all unnecessary services, protocols, and ports.
Modified
p. 89 → 107
• Fail to a configuration that denies all services and require a firewall administrator to re-enable services after a failure.
Modified
p. 89 → 107
• Fail to a configuration that denies all services and require a firewall administrator to re-enable services after a failure.
Modified
p. 89 → 107
• Disable source routing on the firewall.
Modified
p. 89 → 107
• Disable source routing on the firewall.
Modified
p. 89 → 107
• Not accept traffic on its external interfaces that appears to be coming from internal network addresses.
Modified
p. 89 → 107
• Not accept traffic on its external interfaces that appears to be coming from internal network addresses.
Modified
p. 89 → 107
• Notify the firewall administrator in near real time of any item that may need immediate attention such as a break-in, little disk space available, or other related messages so that an immediate action can be taken.
Modified
p. 89 → 107
• Notify the firewall administrator in near real time of any item that may need immediate attention such as a break-in, little disk space available, or other related messages so that an immediate action can be taken.
Modified
p. 89 → 107
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled.
Modified
p. 89 → 107
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled.
Modified
p. 89 → 107
25-7.1.a Examine network and system configurations to verify that certificate-processing system components operated online are protected from unauthorized access by firewall(s).
25-7.1.a Examine network and system configurations to verify that certificate- processing system components operated online are protected from unauthorized access by firewall(s).
Modified
p. 90 → 108
• Generic user IDs and accounts are disabled or removed.
Modified
p. 90 → 108
• Shared user IDs for system administration activities and other critical functions do not exist.
Modified
p. 90 → 108
• Shared and generic user IDs are not used.
Modified
p. 90 → 108
25-8.3 If passwords are used, system-enforced expiration life must not exceed 30 days and a minimum life at least one day.
25-8.3 If passwords are used, system-enforced expiration life must not exceed 90 days and a minimum life at least one day.
Modified
p. 90 → 108
25-8.3 For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 30 days and have a minimum life of at least one day.
25-8.3 For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days and have a minimum life of at least one day.
Modified
p. 90 → 109
25-8.4 Passwords must have a minimum length of eight characters using a mix of alphabetic, numeric, and special characters.
PIN Security Requirements Testing Procedures 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. 90 → 109
25-8.4 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to be at least eight characters long and contain numeric, alphabetic, and special characters.
25-8.4 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to be at least eight characters long and contain numeric, alphabetic, and special characters or equivalent strength as defined in NIST SP 800-63B.
Modified
p. 91 → 109
25-8.5 Limit repeated access attempts by locking out the user ID after not more than five attempts.
Modified
p. 91 → 109
25-8.8.a Review policies and procedures and interview personnel to determine that the embedding of passwords in shell scripts, command files, communication scripts, etc. is strictly prohibited.
25-8.8.a Examine policies and procedures and interview personnel to determine that the embedding of passwords in shell scripts, command files, communication scripts, etc. is strictly prohibited.
Modified
p. 91 → 109
25-8.9.b Examine token-configuration settings to verify parameters are set to require PINs/passwords be at least eight decimal digits in length, or equivalent.
25-8.9.b Examine token-configuration settings to verify parameters are set to require that PINs/passwords be at least eight decimal digits in length, or equivalent.
Modified
p. 92 → 110
25-9.b For a sample of critical systems, review the time-related system parameters to verify that system clocks and times are synchronized for all systems involved in key-management operations.
25-9.b For a sample of critical systems, examine the time-related system parameters to verify that system clocks and times are synchronized for all systems involved in key-management operations.
Modified
p. 92 → 110
• CA operations must be dedicated to certificate issuance and management.
Modified
p. 92 → 110
• All physical and logical CA system components must be separated from key-distribution systems.
Modified
p. 93 → 111
PIN Security Requirements Testing Procedures 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.) The CPS must be consistent with the requirements described within this document.
PIN Security Requirements Testing Procedures 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. 93 → 111
• The CA shall operate in accordance with its CPS.
Removed
p. 94
Verification of the certificate applicant’s possession of the associated private key through the use of a digitally signed certificate request pursuant to PKCS #10 or another cryptographically-equivalent demonstration; Determination that the organization exists by using at least one third-party identity-proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization; Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the certificate applicant to confirm that the organization has authorized the certificate application, confirmation of the employment of the representative submitting the certificate application on behalf of the certificate applicant, and confirmation of the authority of the representative to act on behalf of the certificate applicant; Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the certificate applicant’s representative to confirm that the person named as representative has submitted …
Modified
p. 94 → 112
PIN Security Requirements Testing Procedures 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 with the same secure area. These procedures must include at a minimum, two or more of the following for KDH certificate requests:
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. 95 → 113
• For all certificates whose status had changed
Modified
p. 96 → 114
• Consists of the entrance to the facility.
• Consists of the entrance to the facility.
Modified
p. 96 → 114
• Secures the entrance beyond the foyer/reception area to the CA facility.
• Secures the entrance beyond the foyer/reception area to the CA facility.
Modified
p. 96 → 114
• Provides access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices.
• Provides access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices.
Modified
p. 96 → 114
• The entrance to the facility Level Two Barrier
• The entrance beyond the foyer/reception area to the CA facility Level Three Barrier
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices 32-2.1.b Observe the physical facility to verify three tiers of physical security are implemented as follows:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices 32-2.1.b Observe the physical facility to verify three tiers of physical security are implemented as follows:
Modified
p. 96 → 114
• The entrance to the facility Level Two Barrier
• The entrance beyond the foyer/reception area to the CA facility Level Three Barrier
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Level 1 Barrier 32-2.2 The entrance to the CA facility/building must include the following controls:
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Level 1 Barrier 32-2.2 The entrance to the CA facility/building must include the following controls:
Modified
p. 98 → 116
32-2.3.2.b Observe personnel entering the Level 2 barrier and review corresponding access logs to verify that all entry through the Level 2 barrier is logged.
32-2.3.2.b Observe personnel entering the Level 2 barrier and examine corresponding access logs to verify that all entry through the Level 2 barrier is logged.
Modified
p. 98 → 116
32-2.4.b Review a sample of recorded footage to verify that the video- recording system captures all entry through the Level 2 entrance.
32-2.4.b Examine a sample of recorded footage to verify that the video- recording system captures all entry through the Level 2 entrance.
Modified
p. 98 → 116
32-2.5.1.a Observe Level 3 environment entrances to verify that all doors to the Level 3 environment have locking mechanisms.
Modified
p. 99 → 117
• Specific access authorizations, whether logical or physical 32-2.6.a Examine documented procedures to verify they include the following:
Modified
p. 99 → 117
• Specific access authorizations, whether logical or physical 32-2.6.b Interview responsible personnel to verify that the documented procedures are followed for:
Modified
p. 99 → 117
• Specific access authorizations, whether logical or physical 32-2.6.1 All authorized personnel with access through the Level 3 barrier must:
Modified
p. 99 → 117
• Have successfully completed a background security check.
Modified
p. 99 → 117
• Have successfully completed a background security check.
Modified
p. 99 → 117
• Be assigned resources (staff, dedicated personnel) of the CA operator with defined business needs and duties.
Modified
p. 99 → 117
• Be assigned resources of the CA operator with defined business needs and duties.
Modified
p. 102 → 120
32-2.9.2 Examine monitoring system configurations to verify; The system records to time-lapse VCRs or similar mechanisms.
32-2.9.2 Examine monitoring system configurations to verify;
Modified
p. 102 → 120
• A minimum of five frames are recorded every three seconds.
Modified
p. 103 → 121
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.
If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy (primary and backup) to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
Modified
p. 103 → 121
32-2.9.7 CCTV images must be backed up daily. The backup recording must be stored in a separate, secure location within the facility and must ensure segregation of duties between the users (personnel accessing the secure area) and administrators of the system. Alternatively, backups may be stored in other facilities via techniques such as disk mirroring, provided the storage is secure in accordance with these requirements.
32-2.9.7 CCTV images must be backed up daily. The backup recording must be stored in a separate, secure location within the facility and must ensure segregation of duties between the users (personnel accessing the secure room) and administrators of the system. Alternatively, backups may be stored in other facilities via techniques such as disk mirroring, provided the storage is secure in accordance with these requirements.
Modified
p. 103 → 121
• Backups are securely stored in a separate location from the primary.
Modified
p. 103 → 121
• Ensure that segregation is maintained between users and administrators of the system.
Modified
p. 103 → 121
32-3 The environment must have continuous (24/7) intrusion-detection systems in place, which protects the secure area by motion detectors when unoccupied.
32-3 The environment must have continuous (24/7) intrusion-detection systems in place, which protects the secure room by motion detectors when unoccupied.
Modified
p. 103 → 121
• Continuous (24/7) intrusion-detection monitoring of the Level 3 environment.
Modified
p. 103 → 121
• Motion detectors must be active when the environment is unoccupied.
Modified
p. 103 → 121
• Continuous (24/7) intrusion-detection monitoring of the Level 3 environment is in place.
Modified
p. 103 → 121
• Motion detectors are active when the environment is unoccupied.
Modified
p. 104 → 122
PIN Security Requirements Testing Procedures 32-3.1 Any windows in the secure area must be locked and protected by alarmed sensors.
PIN Security Requirements Testing Procedures 32-3.1 Any windows in the secure room must be locked and protected by alarmed sensors.
Modified
p. 104 → 122
32-3.1.a Observe all windows in the secure areas to verify they are locked and protected by alarmed sensors.
32-3.1.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors.
Modified
p. 104 → 122
32-3.2 Any windows or glass walls must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure area.
32-3.2 Any windows or glass walls must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
Modified
p. 104 → 122
32-3.2 Observe all windows and glass walls in the secure areas to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure area.
32-3.2 Observe all windows and glass walls in the secure room to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
Modified
p. 104 → 122
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 area. The system must be configured to activate within 30 seconds.
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. 104 → 122
• The intrusion-detection system(s) is connected to the alarm system.
Modified
p. 104 → 122
• The intrusion-detection system(s) is automatically activated every time all authorized personnel have exited the secure room.
Modified
p. 104 → 122
• Having all authorized personnel who badged or otherwise authenticated into the area exit and one person remain behind even though they have badged out.
Modified
p. 104 → 122
• Having all but one authorized person who badged or otherwise authenticated into the system badge out and exit.
Modified
p. 104 → 122
• Actions that disable the intrusion-detection system 32-4 All non-CA personnel must sign an access logbook when entering the Level 3 environment.
Modified
p. 104 → 122
32-4.a Examine security policies and procedures to verify they require all personnel (including CA personnel and visitors) 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. 104 → 122
32-4.b On the escorted entry into the secure area, observe that all personnel appropriately sign the access logbook and that all escorted visitors are required to sign the access logbook.
32-4.b On the escorted entry into the secure room, observe that all non-CA personnel appropriately sign the access logbook.
Modified
p. 105 → 123
• For visitor access, the initials of the person escorting the visitor 32-4.1 Examine the access logbook to verify it contains the following information:
Modified
p. 105 → 123
• For visitor access, the initials of the person escorting the visitor 32-4.2 The logbook must be maintained within the Level 3 secure environment.
Modified
p. 105 → 123
32-6.1.c For a sample of documented alarm events, review the record to verify that personnel authorized to sign off on alarm events were not also the cause of that event.
32-6.1.c For a sample of documented alarm events, examine the record to verify that personnel authorized to sign off on alarm events were not also the cause of that event.
Modified
p. 106 → 124
32-6.3.a Review documented procedures to verify they require that all alarms for physical intrusion must be responded to within 30 minutes by personnel assigned security duties.
32-6.3.a Examine documented procedures to verify they require that all alarms for physical intrusion must be responded to within 30 minutes by personnel assigned security duties.
Modified
p. 106 → 124
32-7.1 If a manual synchronization process is used, synchronization must occur at least quarterly; and documentation of the synchronization must be retained for at least a one-year period.
32-7.1 If a manual synchronization process is used, synchronization must occur at least quarterly; events must be recorded, and variances documented; and documentation of the synchronization must be retained for at least a one-year period.
Modified
p. 107 → 125
Key-injection systems that allow clear-text secret and/or private keys and/or their components to appear in unprotected memory (e.g., within a computer and outside of the secure boundary of a secure cryptographic device) are inherently less secure. Any such systems are subject to additional controls as delineated in the criteria in this annex. The payment brands may establish dates by which all key-injection facilities providing key-injection services to multiple entities shall have to use secure cryptographic hardware for key-injection.
Key-injection systems that allow clear-text secret and/or private keys and/or their components to appear in unprotected memory (e.g., within a computer and outside of the secure boundary of a secure cryptographic device) are inherently less secure. Any such systems are subject to additional controls as delineated in the criteria in this annex.
Modified
p. 107 → 125
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.
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, …
Removed
p. 108
1-2.b Examine key-injection platforms and systems used for managing cryptographic keys to verify they conform to the requirements for SCDs.
1-3.b Examine documented procedures and interview personnel to verify that all decryption 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 decryption operations are performed only by the FIPS-approved and/or PTS-approved HSMs identified above.
Modified
p. 108 → 126
• FIPS140-2 Level 3 or higher certified, or
Modified
p. 108 → 126
1-3.a For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and review the list of approved devices to verify that all HSMs are either:
1-3.a For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and examine the list of approved devices to verify that all HSMs are either:
Modified
p. 108 → 126
• Listed on the PCI SSC website, with a valid SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Refer to https://www.pcisecuritystandards.org.
Modified
p. 108 → 126
1-2. Examine documented procedures and system documentation to verify that key-injection platforms and systems used for managing cryptographic keys are required to conform to the requirements for SCDs.
Modified
p. 108 → 126
• 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.
Removed
p. 109
Vendor name Model name/number Hardware version number Firmware version number
Modified
p. 109 → 127
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 1-4.a For all PCI-approved HSMs used, examine HSM devices and examine the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
Modified
p. 109 → 127
• 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:
Modified
p. 110 → 128
PIN Security Requirements Testing Procedures 1-5 The KIF platform provider maintains documentation detailing the distributed KIF architecture and key-management flows. The platform provider must:
PIN Security Requirements Testing Procedures 1-5 The KIF platform provider maintains documentation detailing the KIF architecture and key-management flows. The platform provider must:
Modified
p. 110 → 128
• Maintain current documentation that describes or illustrates the architecture of the KIF, including all KIF functionality.
Modified
p. 110 → 128
• Maintain documentation detailing the flow of keys from the key generation, through the functionality to the destination device. The documentation should indicate how personnel interaction and inventory management of KIF components are integrated into the flow.
Modified
p. 110 → 128
1-5.a Interview relevant personnel and review documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
1-5.a Interview relevant personnel and examine documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
Modified
p. 110 → 128
1-5.b Interview relevant personnel and review 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.
Modified
p. 110 → 128
• Documentation shows all key-management flows across functions and networks from the point the key is generated through to the point the key is injected into the POI.
Modified
p. 110 → 128
• Documentation is kept current and updated as needed upon changes to the KIF architecture
Removed
p. 111
5-1.a Examine key-management policy document and to verify that it requires that all devices used to generate cryptographic keys meet one of the following An approved key-generation function of a PCI-approved HSM An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22.
Modified
p. 111 → 129
Requirement 5: All keys and key components must be generated using an approved random or pseudo-random process.
Requirement 5: All keys, key components, and key shares must be generated using an approved random or pseudo-random process.
Modified
p. 111 → 129
5-1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Cryptographic keys or key components must be generated by one of the following:
5-1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Generation of cryptographic keys or key components must occur within an SCD. They must be generated by one of the following:
Modified
p. 111 → 130
• An SCD that has an approved random number generator that has been certified by an independent laboratory to comply with NIST SP 800-22
Modified
p. 111 → 130
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 approved key-generation function of a PCI•approved HSM An approved key-generation function of a FIPS 140-2 Level 3 (or higher) HSM An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 5-1.c Verify devices used for key generation are those as noted above, …
5-1.b Examine certification letters or technical documentation to verify that all devices used to generate cryptographic keys or key components meet one of the following
Modified
p. 111 → 130
6-1 Implement security controls, including dual control and tamper protection to prevent the unauthorized disclosure of keys/key components.
6-1 Implement security controls, including dual control and tamper detection to prevent the unauthorized disclosure of keys or key components.
Removed
p. 112
There is no unauthorized mechanism that might disclose a clear- text key or key component between the key-generation device and the device or medium receiving the key or key component.
There is no mechanism including connectivity that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Note: Full-length key components or key shares derived using a recognized key-splitting algorithm are not considered key parts and do not provide any information regarding the actual cryptographic key.
PIN Security Requirements Testing Procedures 6-1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component.
There is no mechanism including connectivity that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Note: Full-length key components or key shares derived using a recognized key-splitting algorithm are not considered key parts and do not provide any information regarding the actual cryptographic key.
PIN Security Requirements Testing Procedures 6-1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component.
Modified
p. 112 → 130
• Any output of a clear-text component or share is overseen by only the assigned key custodian(s) for that component/share.
Modified
p. 112 → 131
6-1.2 There must be no point in the process where a single individual has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
6-1.2 There must be no point in the key-generation process where a single individual has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
Modified
p. 112 → 131
6-1.2.b Examine key-generation logs to verify that at least two individuals performed the key-generation processes.
6-1.2.b Examine key-generation logs to verify that:
Modified
p. 112 → 131
6-1.1.b Observe key-generation processes and interview responsible personnel to verify:
PIN Security Requirements Testing Procedures 6-1.1.b Observe key-generation process demonstration and interview responsible personnel to verify:
Modified
p. 112 → 131
• Any output of a clear-text component or share is overseen by only the assigned key custodian(s) for that the component/share.
Modified
p. 112 → 131
6-1.2.a Observe the process from end to end to verify there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
6-1.2.a Examine documented procedures for all key-generation methods and observe demonstrations of the key-generation process from end to end to verify there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
Modified
p. 112 → 131
6-1.3 Devices used for generation of clear-text key components that are output in the clear must be powered off when not in use. Logically partitioned devices used concurrently for other processes
•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.
•e.g., providing services simultaneously to host systems, such as for transaction processing
•must have key-generation capabilities disabled when not in
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. 112 → 131
• Key-generation devices that generate clear-text key components be powered off when not in use; or require re-authentication whenever key generation is invoked; or
Removed
p. 113
6-2.b Observe generation process and review vendor documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory.
Modified
p. 113 → 132
PIN Security Requirements Testing Procedures 6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (for example, unnecessary cables).
PIN Security Requirements Testing Procedures 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. 113 → 132
6-1.4.a Review documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering, prior to use.
6-1.4.a Examine documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering, prior to use⎯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. 113 → 132
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.
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. 113 → 132
6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the key-generation area. It must not be feasible to observe the key-component/key-generation process whereby clear-text keying material is observable either directly or via camera monitoring.
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 clear-text keying material either directly or via camera monitoring.
Modified
p. 113 → 132
6-1.5.a Examine documentation to verify that physical security controls are defined to ensure the key component/key-generation process cannot be observed or accessed by unauthorized personnel.
6-1.5.a Examine documentation to verify that physical security controls (e.g., partitions or barriers) are defined to ensure the key component cannot be observed or accessed by unauthorized personnel.
Modified
p. 113 → 132
6-1.5.b Observe the physical security controls to verify that key- component/key-generation process cannot be observed or accessed by unauthorized personnel.
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. 113 → 133
6-2 Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory.
PIN Security Requirements Testing Procedures 6-2 Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
Modified
p. 113 → 133
6-2.a Examine documented procedures to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory.
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. 113 → 133
Additionally, this requirement excludes from its scope computers used only for administration of SCDs, or key-generation devices where they have no ability to access clear-text cryptographic keys or components.
Additionally, this requirement excludes from its scope computers used only for administration of SCDs, or key-generation devices that do not have the ability to access clear-text cryptographic keys or components.
Modified
p. 113 → 133
Single-purpose computers with an installed SCD where clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) meet this requirement. Where the components pass through unprotected memory of the PC, it must meet Requirement 13 of Annex B.
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 or key pass through memory of the PC, Requirement 13 of Annex B must be met.
Modified
p. 113 → 133
Note: See Requirement 13.
Note: See Requirements 5 and 13.
Modified
p. 113 → 133
6-2.c Where single-purpose computers with an installed SCD are used, verify that either:
6-2.c Where single-purpose computers with an installed SCD or a modified PED are used, verify that either:
Modified
p. 113 → 133
• Where clear keying material passes through memory of the PC, the PC requirements of Requirement 13 of Annex B are met.
Removed
p. 114
PIN Security Requirements Testing Procedures 6-3 Printed key components must be printed within blind mailers or sealed immediately after printing to ensure that:
Printers used for this purpose must not be used for other purposes.
Printers used for this purpose are not used for other purposes.
Printers used for this purpose must not be used for other purposes.
Printers used for this purpose are not used for other purposes.
Modified
p. 114 → 134
• Tampering can be visually detected.
Modified
p. 114 → 134
• Tampering can be detected.
Modified
p. 114 → 134
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 immediately after printing such that:
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:
Modified
p. 114 → 134
6-3.b Observe processes for printing key components to verify that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output.
6-3.b Observe processes for printing key components to verify that 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 and that printers are used only under dual control, only within the secure room that meets the requirements of 32-9 in Annex B, and are not networked.
Modified
p. 114 → 134
6-3.c Observe blind mailers or other sealed containers used for key components to verify that tampering can be detected.
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. 115 → 135
• Any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation.
Modified
p. 115 → 135
• Any residue that may contain clear-text keys or components is destroyed immediately after generation.
Modified
p. 115 → 135
Examples of where such key residue may exist include (but are not limited to): Printing material, including ribbons and paper waste Memory storage of a key-loading device, after loading the key to a different device or system Other types of displaying or recording 6-4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures are implemented to ensure the following:
Examples of where such key residue may exist include (but are not limited to): • Printing material, including ribbons and paper waste
Modified
p. 115 → 135
• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device(s) immediately after the transfer to the device that will use the key.
Modified
p. 115 → 135
• If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device(s) immediately after the transfer to the device that will use the key.
Modified
p. 115 → 135
6-4.b Observe the destruction process of the identified key residue and verify the following:
6-4.b Observe the destruction process of each identified type of key residue and verify the following:
Removed
p. 116
Devices used for key generation or key injection are securely stored when not in use.
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text secret or private keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into startup instructions Taping key or component values to or inside devices Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that key components are prohibited from being transmitted across insecure channels, including but not limited to:
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text secret or private keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into startup instructions Taping key or component values to or inside devices Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that key components are prohibited from being transmitted across insecure channels, including but not limited to:
Modified
p. 116 → 136
• If generated externally, the private key of the key pair and all related critical security parameters (for example, secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair.
Modified
p. 116 → 136
• If generated externally, the key pair and all related critical security parameters are deleted (for example, zeroized) immediately after the transfer to the device that will use the key pair.
Modified
p. 116 → 136
• If generated externally, the key pair and all related critical security parameters must be deleted (zeroized) immediately after the transfer to the device that will use the key pair.
Modified
p. 116 → 136
6-6 Policy and procedures must exist to ensure that key components are prohibited from being transmitted across insecure channels. These include but are not limited to:
6-6 Policy and procedures must exist to ensure that clear-text private or secret keys or their components/shares are not transmitted across insecure channels. Preclusions include but are not limited to:
Modified
p. 117 → 137
7-1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations.
7-1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations and address all keys in scope.
Modified
p. 117 → 137
PIN Security Requirements Testing Procedures 6-6.b From observation of key-management processes verify that key 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. 117 → 137
7-1 Written key-creation procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. All key-creation events performed by a key- injection facility must be documented. Procedures for creating all keys must be documented.
7-1 Written key-generation policies and procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. All key-creation events performed by a key-injection facility must be documented. Procedures for creating all keys must be documented.
Modified
p. 117 → 137
7-1.c Observe key-generation ceremonies whether actual or for demonstration purposes, and verify that the documented procedures are demonstrably in use.
7-1.c Observe key-generation ceremonies whether actual or for demonstration purposes and verify that the documented procedures are demonstrably in use.
Modified
p. 117 → 138
7-2.c Examine logs of key generation to verify that exchanges of higher- level keys with other organizations have been recorded.
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. 117 → 138
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. 118 → 139
Keys conveyed to a key-injection facility must be conveyed in compliance with these requirements. Such keys can include, but are not limited to:
It is the responsibility of both the sending and receiving parties to ensure these keys are managed securely during transport Keys conveyed to a key-injection facility must be conveyed in compliance with these requirements. Such keys can include, but are not limited to:
Modified
p. 118 → 139
• Key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf);
Modified
p. 118 → 139
• Digitally signed HSM-authentication public key(s) signed by a device manufacturer’s private key and subsequently loaded into the HSM for supporting certain key-establishment and distribution applications protocols (if applicable);
Removed
p. 119
Note this does not apply to keys installed in POI devices meeting Requirement 1 when shipped from the key-injection facility.
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. 119 → 140
PIN Security Requirements Testing Procedures 8-1 Keys must be transferred either encrypted or
•if clear text
•as two or more components using different communication channels or within an SCD.
•if clear text
•as
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. 119 → 140
Clear-text key components may be transferred in SCDs or using tamper- evident, authenticable packaging.
Clear-text key components/shares must be transferred in SCDs or using tamper-evident, authenticable packaging.
Modified
p. 119 → 140
− Components/shares must be conveyed using at least two separate communication channels, such as different courier services. Components/shares sufficient to form the key must not be conveyed using the same communication channel.
Modified
p. 119 → 140
• Where SCDs are used for conveying components/shares, the mechanisms or data (e.g., PIN) to obtain the key component/share from the SCD must be conveyed using a separate communication channel from the SCD, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
Modified
p. 119 → 140
• 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. 119 → 140
8-1.a Determine whether keys are transmitted encrypted, as clear-text components or within an SCD.
8-1.a Determine whether keys are transmitted encrypted, as clear-text components/shares, or within an SCD.
Modified
p. 119 → 141
− The details of the serial number of the package were transmitted separately from the package itself.
Modified
p. 119 → 141
8-1.b If key components are ever transmitted in clear text using tamper- evident mailers, 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. 119 → 142
• Examine documented procedures to verify that the mechanism to obtain the keying material (e.g., PIN) is conveyed using separate communication channel from the associated SCD.
Modified
p. 119 → 142
• Examine records of key transfers and interview responsible personnel to verify the mechanisms that make the SCD operational are conveyed using separate communication channels.
Modified
p. 119 → 142
• Examine documented procedures to verify that the SCD is inspected to ensure there are no signs of tampering.
Removed
p. 120
Examine records of key transfers and interview responsible personnel to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
Examine documented procedures to verify that the SCD requires dual- control mechanisms to become operational.
Examine documented procedures to verify that the SCD is inspected to ensure that there are not any signs of tampering.
Examine records of key transfers and interview responsible personnel to verify that the mechanisms make the SCD operational are conveyed using separate communication channels.
Examine documented procedures to verify that the SCD requires dual- control mechanisms to become operational.
Examine documented procedures to verify that the SCD is inspected to ensure that there are not any signs of tampering.
Examine records of key transfers and interview responsible personnel to verify that the mechanisms make the SCD operational are conveyed using separate communication channels.
Modified
p. 120 → 142
• Examine documented procedures to verify that the SCD requires dual- control mechanisms to become operational.
Modified
p. 120 → 142
PIN Security Requirements Testing Procedures 8-1.c Where SCDs are used to convey components, perform the following:
PIN Security Requirements Testing Procedures 8-1.c Where SCDs are used to convey components/shares,
Modified
p. 120 → 142
• Examine documented procedures to verify that the SCD is inspected to ensure that there are not any signs of tampering.
Modified
p. 120 → 142
8-1.d Where SCDs are conveyed with pre-loaded secret and/or private keys, perform the following:
8-1.d Where an SCD is conveyed with pre-loaded secret and/or private keys, perform the following:
Modified
p. 120 → 143
8-2 A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares sufficient to form the necessary threshold to derive the key.
PIN Security Requirements Testing Procedures 8-2 A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares sufficient to form the necessary threshold to derive the key.
Modified
p. 120 → 143
8-2.a Examine documented procedures to verify they include controls to ensure that no single person can ever have 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:
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:
Modified
p. 120 → 143
• Reminder that any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other components or shares sufficient to form the necessary threshold to derive the key.
Modified
p. 120 → 143
• Steps to ensure any person with access to the media conveying a component/share of a key could not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key without detection.
Modified
p. 121 → 144
• There is sufficient evidence to show that a person with access to the media conveying a key component or key share could not have access to other components/shares of this key or to any other medium conveying any other components or shares of this key that are sufficient to form the necessary threshold to derive the key without detection.
Modified
p. 121 → 144
8-3 E-mail shall not be used for the conveyance of secret or private keys or their components, even if encrypted, unless the key (or component) has already been encrypted in accordance with these requirements•i.e., in an SCD. This is due to the existence of these key values in unprotected memory just prior to 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 …
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 …
Modified
p. 121 → 144
PIN Security Requirements Testing Procedures 8-2.b Observe key-transfer processes and interview personnel to verify that controls are implemented to ensure that no single person can ever have 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:
PIN Security Requirements Testing Procedures 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. 121 → 144
• There is a clear understanding that an individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Modified
p. 121 → 144
8-3 Validate through interviews, observation, and logs that email, SMS, fax, or telephone or similar communication is not used as means to convey secret or private keys or key components.
8-3 Validate through interviews, observation, and log inspection that e-mail, SMS, fax, or telephone or similar communication is not used as means to convey secret or private keys or key components/shares.
Removed
p. 122
Examine documented procedures for conveying public keys to verify that methods are defined to convey public keys in a manner that protects their integrity and authenticity such as: o Use of public-key certificates created by a trusted CA that meets the requirements of Annex A o A hash of the public key sent by a separate channel (for example, mail) o Using a MAC (message authentication code) created using the algorithm defined in ISO 16609 o Be within an SCD Validate that self-signed certificates must not be used as the sole method of authentication.
Modified
p. 122 → 145
• Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A.
Modified
p. 122 → 145
• Using a MAC (message authentication code) created using the algorithm defined in ISO 16609
Modified
p. 122 → 145
8-4.c Observe the process for conveying public keys, associated logs, and interview responsible personnel to verify that the implemented method ensures public keys are conveyed in a manner that protects their integrity and authenticity.
Removed
p. 123
Under the continuous supervision of a person with authorized access to this component, or Locked in a security container (including tamper-evident, authenticable packaging) in such a way that unauthorized access to it would be detected, or Contained within a physically secure SCD.
Under the continuous supervision of a person with authorized access to this component, or Locked in a security container (including tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or Contained within a physically secure SCD.
Under the continuous supervision of a person with authorized access to this component, or Locked in a security container (including tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or Contained within a physically secure SCD.
Under the continuous supervision of a person with authorized access to this component, or Locked in a security container (including tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or Contained within a physically secure SCD.
Under the continuous supervision of a person with authorized access to this component, or Locked in a security container (including tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or Contained within a physically secure SCD.
Modified
p. 123 → 146
Requirement 9: During its transmission, conveyance, or movement between any two organizational entities, any single unencrypted secret or private key component must at all times be protected.
Requirement 9: During its transmission, conveyance, or movement between any two locations or organizational entities, any single unencrypted secret or private key component or share must at all times be protected.
Modified
p. 123 → 146
9-1 Any single clear-text secret or private key component/share must at all times be either:
9-1 During the process to convey it, any single clear-text secret or private key component/share must at all times be either:
Modified
p. 123 → 146
Sending and receiving entities are equally responsible for the physical protection of the materials involved.
Sending and receiving location/entities are equally responsible for the physical protection of the materials involved.
Modified
p. 123 → 146
Key components conveyed to and from a key-injection facility must be conveyed in compliance with these requirements. Such key components include but are not limited to those for key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf), or key components for the BDKs themselves, …
Key components/shares conveyed to and from a key-injection facility must be conveyed in compliance with these requirements. Such key components/shares include but are not limited to those for key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf), or key components for the BDKs themselves, …
Modified
p. 123 → 147
9-1.b Observe key-management processes and interview responsible personnel to verify processes are implemented to ensure that any single clear-text key component is at all times either:
PIN Security Requirements Testing Procedures 9-1.b Observe key-management processes, examine associated logs, and interview responsible personnel to verify processes are implemented to ensure that any single clear-text key component is at all times either:
Removed
p. 124
The set of components Any keys encrypted under this (combined) key 9-3 No one but the authorized key custodian (and designated backup(s)) shall have physical access to a key component prior to transmittal or upon receipt of a component.
9-3.a Verify that a list(s) of key custodians (and designated backup(s)) authorized to have physical access to key components prior to transmittal or upon receipt of a component is defined and documented.
9-3.a Verify that a list(s) of key custodians (and designated backup(s)) authorized to have physical access to key components prior to transmittal or upon receipt of a component is defined and documented.
Modified
p. 124 → 147
• Any keys encrypted under this (combined) key 9-2.a Verify documented procedures include requirements for all packaging or mailers containing clear-text key components to be examined for evidence of tampering before being opened.
Modified
p. 124 → 147
• 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:
Modified
p. 124 → 147
9-2 Packaging or mailers (i.e., pre-numbered, tamper-evident packaging) containing clear-text key components are examined for evidence of tampering before being opened. Any sign of package tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and replacement of:
Modified
p. 124 → 147
9-2.c Verify documented procedures require that any sign of package tampering 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 ultimately results in the destruction and replacement of both:
Modified
p. 124 → 148
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 transmittal or upon receipt.
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. 125 → 148
• Place key components into pre-numbered, tamper-evident, authenticable packaging for transmittal.
Modified
p. 125 → 148
9-4 Mechanisms must exist to ensure that only authorized custodians:
Modified
p. 125 → 148
• Check tamper-evident packaging upon receipt for signs of tamper prior to opening the tamper-evident, authenticable packaging containing key components.
Modified
p. 125 → 149
• Examine documented procedures to verify they define how details of the serial number are transmitted separately from the package itself.
Modified
p. 125 → 149
• 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. 125 → 149
9-4.b Observe implemented mechanisms and processes to verify that only the authorized key custodians can perform the following:
PIN Security Requirements Testing Procedures 9-4.b Observe implemented mechanisms and processes and examine logs to verify that only the authorized key custodians can perform the following:
Modified
p. 125 → 149
• Place the key component into pre-numbered, tamper-evident packaging for transmittal.
Modified
p. 125 → 149
9-5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers.
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.
Removed
p. 126
• 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 within 24 months of the publication of these requirements when used for key distribution using asymmetric techniques in accordance with Annex A.
Modified
p. 126 → 151
• TDEA keys shall not be used to protect AES keys.
Modified
p. 126 → 151
• TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
Modified
p. 126 → 151
• RSA keys used to transmit or convey other keys must have bit strength of at least 80 bits.
Modified
p. 126 → 151
• RSA keys encrypting keys greater in strength than 80 bits shall have bit strength at least 112 bits.
Modified
p. 126 → 151
Key-encryption keys used to convey keys to a key-injection facility must be (at least) as strong as any key transmitted or conveyed. Such keys include but are not limited to, key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf).
Key-encryption keys used to convey keys to a key-injection facility or between locations or systems within the same key-injection facility must be at least as strong as any key transmitted or conveyed. Such keys include but are not limited to, key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities, locations, or systems (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third …
Modified
p. 126 → 151
10-1 All key-encryption keys used to encrypt for transmittal or conveyance of other cryptographic keys must be (at least) as strong as the key being sent, as delineated in Annex C except as noted below for RSA keys used for key transport and for TDEA keys.
10-1 All key-encryption keys used to encrypt for transmittal or conveyance of other cryptographic keys must be at least as strong as the key being sent, as delineated in Annex C except as noted below for RSA keys used for key transport.
Modified
p. 126 → 151
• 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. 126 → 151
• A double- or triple-length TDEA key must not be encrypted with a TDEA key of a lesser strength.
Modified
p. 126 → 151
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
•and thus have a mixed portfolio of devices
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 …
•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 …
Modified
p. 126 → 151
10-1.a Examine documented procedures to verify that all keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed.
10-1.a Examine documented procedures to verify there is a requirement that all keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed, except as noted for RSA keys.
Removed
p. 127
Verify that: o DEA keys used for encrypting keys must be at least double-length keys (have bit strength of 80 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment. o A double- or triple-length DEA key must not be encrypted with a DEA key of lesser strength. o TDEA keys are not used to protect AES keys. o TDEA keys shall not be used to encrypt keys greater in strength than 112 bits. o RSA keys used to transmit or convey other keys have bit strength of at least 80 bits. o RSA keys encrypting keys greater in strength than 80 bits have bit strength at least 112 bits.
Modified
p. 127 → 152
• Interview appropriate personnel and examine documented procedures for the creation of these keys.
Modified
p. 127 → 152
PIN Security Requirements Testing Procedures 10-1.b 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.
PIN Security Requirements Testing Procedures 10-1.c Observe key-generation processes for the key types identified above. Verify that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed except as noted for RSA keys.
Modified
p. 127 → 152
• Using the table in Annex C, validate the respective key sizes for TDEA, RSA, Elliptic Curve, DSA, and Diffie Hellman algorithms where used for key encryption.
Modified
p. 127 → 152
− Any POI device that is version 3 or higher is using RSA with a key size of at least 2048 and SHA-2, where applicable. Use as necessary the device information used in Requirement 1.
Modified
p. 127 → 152
10-1.d Examine system documentation and configuration files to validate the above, including HSM settings.
Removed
p. 129
Derived Unique Key Per Transaction (DUKPT) Base Derivation Keys (BDKs) used in the DUKPT key-management method; Key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is injecting keys on their behalf); Terminal master keys (TMKs) used in the master key/session key key-management method; PIN-encryption keys used in the fixed-transaction key method; Master keys for key-injection platforms and systems that include hardware devices (SCDs) for managing (e.g., generating and storing) the keys used to encrypt other keys for storage in the key-injection platform system; Public and private key pairs loaded into the POIs for supporting remote key-establishment and distribution applications; Digitally signed POI public key(s) signed by a device manufacture’s private key and subsequently …
Modified
p. 129 → 154
Requirement 12: Secret and private keys must be input into hardware (host) security modules (HSMs) and PIN entry devices (PEDs) 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. 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.
Modified
p. 129 → 155
12-1.a Review documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required.
12-1.a Using the summary of cryptographic keys, identify keys that are loaded from components and examine documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required.
Modified
p. 129 → 155
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.
PIN Security Requirements Testing Procedures 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. 129 → 155
12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key, and the methodology used to form the key.
12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key.
Modified
p. 129 → 155
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 to 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.
Removed
p. 130
12-4.b Examine key-component lengths or device configuration settings to verify that key components used to create a key are the same length as the resultant key.
Two or more passwords of five characters or more (vendor default values must be changed), Multiple cryptographic tokens (such as smartcards), or physical keys, Physical access controls Note that for devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian.
12-3.b For all types of production SCDs, observe processes for loading clear-text cryptographic keys, including public keys, to verify that dual control is required to authorize any key-loading session. Verify that any passwords used are a minimum of five characters.
Two or more passwords of five characters or more (vendor default values must be changed), Multiple cryptographic tokens (such as smartcards), or physical keys, Physical access controls Note that for devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian.
12-3.b For all types of production SCDs, observe processes for loading clear-text cryptographic keys, including public keys, to verify that dual control is required to authorize any key-loading session. Verify that any passwords used are a minimum of five characters.
Modified
p. 130 → 155
12-1.d Verify that the process includes the entry of individual key components by the designated key custodians.
Modified
p. 130 → 155
12-2 Examine logs of access to security containers for key components to verify that only the authorized custodian(s) have accessed. Compare the number on the current TEA bag for each component to the last log entry for that component.
12-2 Examine logs of access to security containers for key components/shares to verify that only the authorized custodian(s) have accessed. Compare the number on the current tamper-evident and authenticable package for each component to the last log entry for that component.
Modified
p. 130 → 156
12-3.c Examine documented records of key-loading processes to verify the presence of two authorized persons during each type of key-loading activity.
12-3.c Examine documented records of key-loading to verify the presence of two authorized persons during each type of key-loading activity.
Modified
p. 130 → 156
12-3.d Ensure that any default dual-control mechanisms (e.g., default passwords
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
12-3.d Ensure that any default dual-control mechanisms (e.g., default passwords/authentication codes
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
Modified
p. 130 → 156
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.
PIN Security Requirements Testing Procedures 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. 130 → 156
12-3.a Examine documented procedures for loading of clear-text cryptographic keys, including public keys, to verify they require dual control to authorize any key-loading session.
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. 130 → 157
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.) Note that 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.
PIN Security Requirements Testing Procedures 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.) Note that 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. 130 → 157
12-4.a Examine documented procedures for combining symmetric key components and observe processes to verify that key components are combined using a process such that no active bit of the key can be determined without knowledge of the remaining components.
12-4.a Examine documented procedures for combining symmetric key components and observe processes to verify that key components are combined using a process such that no active bit of the key can be determined without knowledge of the remaining components⎯e.g. only within an SCD.
Modified
p. 131 → 157
12-5 Examine vendor documentation describing options for how the HSM MFK is created. 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. 131 → 157
12-7.a Examine documented procedures for the loading of TMKs to verify that they require asymmetric key-loading techniques or manual techniques for initial loading.
12-7.a Examine documented procedures for the loading of TMKs and initial DUKPT keys to verify that they require asymmetric key-loading techniques or manual techniques for initial loading and allowed methods for replacement TMK or initial DUKPT key loading.
Modified
p. 131 → 157
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. 131 → 157
12-6 Through examination of documented procedures, interviews, and observation, confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key, 12-7 The initial terminal master key (TMK) 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 documents such as:
12-6 Through examination of documented procedures, interviews, and observation, confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key, 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. 131 → 157
• The existing TMK to encrypt the replacement TMK for download
Modified
p. 131 → 157
Keys shall not be reloaded by any methodology in the event of a compromised device, and must be withdrawn from use.
Keys shall not be reloaded by any methodology in the event of a compromised device and must be withdrawn from use.
Modified
p. 131 → 157
12-7.b Examine documented procedures to verify that keys are prohibited from reloading or reuse wherever suspected of being compromised and are withdrawn from use.
12-7.b Examine documented procedures to verify that keys are withdrawn from use if they were loaded to a device that has been compromised or went missing.
Modified
p. 131 → 158
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:
PIN Security Requirements Testing Procedures 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. 131 → 158
• Use public and private key lengths that are in accordance with Annex C for the algorithm in question (e.g., 1024-bits minimum for RSA).
Modified
p. 131 → 158
• Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Modified
p. 131 → 158
• Use of public and private key lengths that are in accordance with Annex C for the algorithm in question (e.g., 1024-bits minimum for RSA).
Modified
p. 131 → 158
• Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Modified
p. 131 → 158
• Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable.
Modified
p. 131 → 158
A public-key technique for the distribution of symmetric secret keys must:
• A public-key technique for the distribution of symmetric secret keys
Modified
p. 131 → 158
• Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device has (or can compute) the session key and that no entity other than the POI device specifically identified can possibly compute the session key.
Modified
p. 131 → 158
12-8.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication for both the host and the POI.
12-8.a For techniques involving public key cryptography, examine documentation to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication for both the host and the POI.
Modified
p. 131 → 158
12-8.b If key-establishment protocols using public-key cryptography are used to distribute secret keys, verify that the remote key distribution requirements detailed in Annex A of this document are met, including:
12-8.b If key-establishment protocols using public-key cryptography are used to distribute secret keys, verify that the remote key-distribution requirements detailed in Annex A of this document are met, including:
Modified
p. 132 → 159
Note: Such controls may include but are not limited to: 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.
Note: Such controls may include but are not limited to: • 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. 132 → 159
• 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. 132 → 159
• 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. 132 → 159
• Demonstrable procedures that prohibit key custodians from handing their components to any other individual for key entry.
Modified
p. 132 → 159
12-9.a Examine documented key-injection procedures to verify that the procedures define use of dual control and split knowledge controls for the loading of keys into devices.
• Separate key-loading devices for each component 12-9.a Examine documented key-injection procedures to verify that the procedures define use of dual control and split knowledge controls for the loading of keys into devices.
Modified
p. 133 → 160
Some key-injection platforms use personal-computer (PC)-based software applications, whereby clear-text secret and/or private keys and/or their components exist in unprotected memory outside the secure boundary of an SCD for loading keys. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. These weaknesses include:
Some key-injection platforms use personal-computer (PC)-based software applications, whereby clear-text secret and/or private keys and/or their components exist in memory outside the secure boundary of an SCD for loading keys. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. These weaknesses include:
Modified
p. 133 → 160
• XOR’ing of key components is performed in software.
Modified
p. 133 → 160
• Clear-text keys and components can reside in software during the key-loading process.
Modified
p. 133 → 160
• Some systems require only a single password.
Modified
p. 133 → 160
• Some systems store the keys (e.g., BDKs, TMKs) on removable media or smart cards. These keys are in the clear with some systems.
Modified
p. 133 → 160
• PCs, by default, are not managed under dual control. Extra steps (e.g., logical user IDs, physical access controls, etc.) must be implemented to prevent single control of a PC.
Modified
p. 133 → 160
• Data can be recorded in the PC’s non-volatile storage.
Modified
p. 133 → 160
• Software Trojan horses or keyboard sniffers can be installed on PCs.
Removed
p. 134
The SCD must be inspected prior to use to ensure that it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying materials.
Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: o SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading. o An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device. o There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys. o The SCD is inspected to ensure it has not been subject to any …
Review documented procedures to determine that they require that keys and components are transferred into an SCD only after an inspection of the devices and mechanism; and verify they are followed by observing a demonstration that: o SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading. o An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device. o There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys. o The SCD is inspected to ensure it has not been subject to any …
Modified
p. 134 → 161
• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of clear-text key components.
Modified
p. 134 → 161
• There is not any mechanism at the interface between the conveyance medium and the SCD that might disclose the transferred keys.
Modified
p. 134 → 161
• An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are uniquely identified by the device.
Modified
p. 134 → 161
• SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.
Modified
p. 134 → 161
• Ensure that any cameras that are present are positioned to ensure they cannot monitor the entering of clear-text key components.
Modified
p. 134 → 161
13-2 Only SCDs shall be 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 controller (computer) keyboards shall never be used for the loading of clear-text secret or private keys or their components.
13-2 Only SCDs shall be used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility, as delineated in the requirements in this Annex. For example, ATM controller (computer) keyboards or those attached to an HSM shall never be used for the loading of clear-text secret or private keys or their components.
Modified
p. 134 → 161
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.
Removed
p. 135
The medium used for key loading is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or All traces of the component are erased or otherwise destroyed from the electronic medium.
Modified
p. 135 → 162
13-3.a Examine documented procedures for the loading of secret or private key components from an electronic medium to a cryptographic device. Verify that procedures define specific instructions to be followed as a result of key loading, including:
Modified
p. 135 → 162
• 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. 135 → 162
13-4 Review 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. 135 → 162
PIN Security Requirements Testing Procedures 13-3 The loading of secret or private key components from an electronic medium to 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: 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 …
•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 …
Modified
p. 135 → 162
• 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. 135 → 162
13-3.b Observe key-loading processes to verify that the loading process results in one of the following:
Modified
p. 135 → 163
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.
13-4.2 Verify the key-loading device is under the supervision of a person authorized by management or stored in a secure container such that no unauthorized person can have access to it.
Modified
p. 135 → 163
13-4.2 Verify the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it.
PIN Security Requirements Testing Procedures 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. 136 → 163
13-4.3.b Verify that authorized personnel inspect the key-loading device prior to use to ensure that a key-recording device has not been inserted between the SCDs.
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. 136 → 163
• The media/devices are removed from secure storage only for the minimum practical time necessary to complete the key-loading process.
Modified
p. 136 → 163
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. 136 → 163
13-4.4 The key-loading device must not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred.
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. 136 → 163
13-5 Any media (electronic or otherwise) containing secret or private key components used for loading cryptographic keys must be maintained in a secure storage location and accessible only to authorized custodian(s).
13-5 Any media (electronic or otherwise) containing secret or private key components or shares used for loading cryptographic keys must be maintained in a secure storage location and accessible only to authorized custodian(s).
Modified
p. 136 → 163
Key components that can be read/displayed (for example, those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in clear text to a non-custodian for that component.
Key components that can be read/displayed (for example, those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in clear text to anyone who is not a designated custodian for that component.
Modified
p. 136 → 163
• Requirement that media/devices are in the physical possession of only the designated component holder(s).
Modified
p. 136 → 164
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.
PIN Security Requirements Testing Procedures 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.
Removed
p. 137
Standalone Dedicated to only key loading Located in a physically secure room that is dedicated to key loading activities
Modified
p. 137 → 164
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. 137 → 164
13-6 Validate through interview and observation that printed key components are not opened until just prior to entry into the SCD/KLD. Plaintext secret and/or private keys and/or their components are visible only to key custodians for the duration of loading into an SCD/KLD.
13-6 Validate through interview and observation that printed key components are not opened until just prior to entry into the SCD. Plaintext secret and/or private keys and/or their components are visible only to key custodians for the duration of loading into an SCD.
Modified
p. 137 → 164
13-7.a Review 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. 137 → 164
13-8.b Examine key-component access controls and access logs to verify that any single authorized custodians can only access their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key.
13-8.b Examine key-component access controls and access logs to verify that any single authorized custodians can and has only had access to their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key.
Modified
p. 137 → 165
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 unprotected memory outside the secure boundary of an SCD must minimally implement the following additional controls:
PIN Security Requirements Testing Procedures 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. 137 → 165
13-9 Interview appropriate personnel and review documentation to determine the procedures for key loading to POIs, key-loading devices, and HSMs that are part of the key-loading platform. Review any logs of key loading.
13-9 Interview appropriate personnel and examine documentation to determine the procedures for key loading to POIs, key-loading devices, and HSMs that are part of the key-loading platform. Examine any logs of key loading.
Modified
p. 137 → 165
• Standalone (i.e., without modems, not connected to a LAN or WAN, not capable of wireless connections, etc.);
Removed
p. 138
Logs include a minimum of: o Access to the room from a badge access system, o Access to the room from a manual sign-in sheet, o User sign-on logs on the PC at the operating system level, o User sign-on logs on the PC at the application level, o Logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key-injection, o Video surveillance logs with a minimum retention period of 45 days.
Modified
p. 138 → 165
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.
Modified
p. 138 → 165
• All hardware used in key loading (including the PC) is managed under dual control.
Modified
p. 138 → 165
• Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process.
Modified
p. 138 → 165
• Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals.
Modified
p. 138 → 166
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:
PIN Security Requirements Testing Procedures 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. 138 → 166
− 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. 138 → 166
13-9.3.a Verify through interviews and observation that logs of key- loading activities are maintained and meet the following:
13-9.3.a Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
Modified
p. 138 → 166
• Retained for a minimum of three years.
Modified
p. 138 → 166
• Retained for a minimum of three years.
Modified
p. 138 → 166
• Regularly reviewed by an authorized person who does not have access to the room or to the PC.
Modified
p. 138 → 166
• Regularly reviewed by an authorized person who does not have access to the room or to the PC.
Modified
p. 138 → 166
• The reviews are documented.
Modified
p. 138 → 166
• The reviews are documented.
Modified
p. 138 → 166
13-9.3.b Verify through interviews and observation that logs of key- loading activities are maintained and meet the following:
13-9.3.b Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
Modified
p. 139 → 166
13-9.4 Additionally: 13-9.2 Verify through interviews and observation that:
Modified
p. 139 → 167
13-9.4.3 The software application must load keys without recording any clear-text values on portable media or other unsecured devices.
PIN Security Requirements Testing Procedures 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. 139 → 167
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 orpasswords to operate the key-injection application.
•they must be escorted by authorized key-injection personnel
•and they must not have user IDs or
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. 139 → 167
13-9.4.5 Personnel responsible for the systems administration of the PC do not have authorized access into the room
•i.e., they are escorted by authorized key-injection personnel
•and do not have user IDs orpasswords to operate the key-injection application.
•i.e., they are escorted by authorized key-injection personnel
•and do not have user IDs or
13-9.4.5 Personnel responsible for the systems administration of the PC do not have authorized access into the room
•i.e., they are escorted by authorized key-injection personnel
•and do not have user IDs or passwords/authentication codes to operate the key-injection application.
•i.e., they are escorted by authorized key-injection personnel
•and do not have user IDs or passwords/authentication codes to operate the key-injection application.
Modified
p. 140 → 168
Requirement 14: All hardware and access/authentication mechanisms (e.g., passwords) used for key loading must be managed under the principle of dual control.
Requirement 14: All hardware and access/authentication mechanisms (e.g., passwords/authentication codes) used for key loading must be managed under the principle of dual control.
Modified
p. 140 → 168
• Any hardware used in the key-loading function must be controlled and maintained in a secure environment under dual control.
Modified
p. 140 → 168
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 to be used to initiate decryption of keys on portable electronic media (e.g., smart cards) must ensure the passwords are maintained under dual control and split knowledge.
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.
Modified
p. 140 → 168
13-9.4.10 Manufacturer’s default passwords for PC-based applications must be changed.
13-9.4.10 Manufacturer’s default passwords/authentication codes for PC-based applications must be changed.
Modified
p. 140 → 168
13-9.4.10 Manufacturer’s default passwords for PC-based applications are changed.
13-9.4.10 Manufacturer’s default passwords/authentication codes for PC- based applications are changed.
Modified
p. 140 → 168
Key-injection facilities must ensure that the key-injection application passwords and associated user IDs are managed in such a way as to enforce dual control. Also, the hardware used for key-injection must be managed under dual control. Vendor default passwords must be changed.
Key-injection facilities must ensure that the key-injection application passwords/authentication codes and associated user IDs are managed in such a way as to enforce dual control. Also, the hardware used for key-injection must be managed under dual control. Vendor default passwords/authentication codes must be changed.
Modified
p. 140 → 168
14-1 Any hardware and passwords used in the key-loading function must be controlled and maintained in a secure environment under dual control. Resources (e.g., passwords and associated hardware must be managed such that no single individual has the capability 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. 140 → 168
• Any resources (e.g., passwords/authentication codes and associated hardware) used in the key-loading function must be controlled and managed such that no single individual has the capability to enable key loading.
Modified
p. 141 → 169
• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control.
Modified
p. 141 → 169
• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading.
Modified
p. 141 → 169
14-2.a Review documented procedures to ensure they require that cable attachments be examined prior to key-loading function.
14-2.a Examine documented procedures to ensure they require that cable attachments are examined at the beginning of an entity's key-activity operations (system power on/authorization).
Modified
p. 141 → 169
14-2.b Observe key-loading processes to verify that all cable attachments are properly examined prior to a key-loading function.
14-2.b Observe key-loading processes to verify that all cable attachments are properly examined at the beginning of an entity's key-activity operations (system power on/authorization).
Modified
p. 141 → 169
14-2 All cable attachments must be examined before each key-loading operation to ensure they have not been tampered with or compromised.
14-2 All cable attachments over which clear-text keying material traverses must be examined at the beginning of an entity's key-activity operations (system power on/authorization) to ensure they have not been tampered with or compromised.
Modified
p. 141 → 169
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. 141 → 170
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 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. 142 → 170
14-4.c Review storage locations for physical tokens to determine adequacy to ensure that only the authorized custodian(s) can access their specific tokens.
14-4.c Examine storage locations for physical tokens to determine adequacy to ensure that only the authorized custodian(s) can access their specific tokens.
Modified
p. 142 → 170
14-5.a Verify that documented procedures require default passwords or PINs used to enforce dual control are changed.
14-5.a Verify that documented procedures require default passwords/authentication codes used to enforce dual control are changed.
Modified
p. 142 → 170
14-5.b Verify that documented procedures exist to require that these passwords/PINs be changed when assigned personnel change.
14-5.b Verify that documented procedures exist to require that these passwords/authentication codes be changed when assigned personnel change.
Modified
p. 142 → 170
14-4.b Inspect locations and controls for physical tokens to verify that tokens used to enable key loading are not in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control.
Modified
p. 142 → 170
14-4.d Verify that access-control logs exist and are in use.
14-4.d Verify that access-control logs exist and are in use, including notation of tamper-evident authenticable bag numbers.
Modified
p. 142 → 170
14-5 Default password or PINs 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. 142 → 171
15-1 A cryptographic-based validation mechanism must be is 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 not exceed six hexadecimal characters in length.
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. 143 → 171
15-1.c Verify that the methods used for key validation are consistent with ISO 11568•for example, if check values are used, they should return a value of no more than six hexadecimal characters.
15-1.c Verify that the methods used for key validation are consistent with ISO 11568•for example, if check values are used, they are in accordance with this requirement.
Modified
p. 143 → 171
• Have a MAC (message authentication code) created using the algorithm defined in ISO 16609.
Modified
p. 143 → 171
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. 143 → 171
15-2.a Interview personnel and review documented procedures to verify that all public keys exist only in an approved form.
15-2.a Interview personnel and examine documented procedures to verify that all public keys exist only in an approved form.
Modified
p. 143 → 172
16-1 Documented key-loading procedures must exist for all devices (e.g., HSMs and POIs), and all parties involved in cryptographic key-loading must be aware of those procedures.
16-1 Documented key-loading procedures must exist for all devices (e.g., HSMs and POIs), and all parties involved in cryptographic key loading must be aware of those procedures.
Removed
p. 144
18-3 Effective 1 January 2018, encrypted symmetric keys must be managed in structures called key blocks. The key usage must be cryptographically bound to the key using accepted methods Acceptable methods of implementing the integrity requirements include, but are not limited to:
Modified
p. 144 → 172
18-2 To prevent or detect usage of a compromised key, key-component packaging or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
18-2 To prevent or detect usage of a compromised key, key-component packaging, or containers that show signs of tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, it must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
Modified
p. 144 → 172
18-2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering 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 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 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. 144 → 173
18-2.b Interview personnel and observe processes to verify procedures are implemented to require that key-component packaging/containers showing signs of tampering result in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
PIN Security Requirements Testing Procedures 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. 144 → 173
• An integrity check that is an implicit part of the key-encryption process such as that which is used in the AES key-wrap process specified in ANSI X9.102.
Modified
p. 144 → 173
18-3 Examine documented procedures and observe key operations to verify that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or an equivalent.
18-3 Using the cryptographic-key summary to identify secret keys conveyed or stored, examine documented procedures and observe key operations to verify that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or an equivalent.
Modified
p. 145 → 174
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. 145 → 174
• All devices loaded with keys must be tracked at each key-loading session by serial number.
Modified
p. 145 → 174
• Key-injection facilities must use something unique about the POI (for example, logical identifiers) when deriving the key (for example, DUKPT, TMK) injected into it.
Modified
p. 145 → 174
• Controls to prevent the operation of devices without legitimate keys.
Modified
p. 145 → 174
• Controls are implemented that prevent the operation of devices without legitimate keys.
Modified
p. 145 → 174
• Where test keys are used, key-injection facilities must use a separate test system for the injection of test keys.
Modified
p. 145 → 174
• Test keys must not be injected using the production platform, and test keys must not be injected into production equipment.
Modified
p. 145 → 174
• Production keys must not be injected using a test platform, and production keys must not be injected into equipment that is to be used for testing purposes.
Modified
p. 145 → 174
• Keys used for signing of test certificates must be test keys.
Modified
p. 145 → 174
• Keys used for signing of production certificates must be production keys.
Removed
p. 146
19-2 Private keys must only be used as follows:
Modified
p. 146 → 175
19-1.b Using a sample of device types, validate via review of check values, terminal definition files, etc. that keys used for key encipherment or PIN encipherment are not used for any other purpose.
19-1.b Using a sample of device types, validate via examination of check values, terminal definition files, etc. that keys used for key encipherment or PIN encipherment are not used for any other purpose.
Modified
p. 146 → 175
• Must be used only for a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices).
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices).
Modified
p. 146 → 175
• Must never be used to encrypt other keys.
Modified
p. 146 → 175
19-2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only used:
19-2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are:
Modified
p. 146 → 175
• Used only to create digital signatures or to perform decryption operations.
Modified
p. 146 → 175
• Used only for a single purpose
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for POI devices).
•a private key must only be used for either decryption or for creating digital signatures, but not both (except for POI devices).
Modified
p. 146 → 175
• Never used to encrypt other keys.
Modified
p. 146 → 175
• To perform encryption operations or to verify digital signatures.
Modified
p. 146 → 175
• For a single purpose
•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI devices).
•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for POI devices).
Modified
p. 146 → 175
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.). This is necessary to limit the magnitude of exposure should any key(s) be compromised. Using keys only as they are intended also significantly strengthens the security of the underlying system.
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 …
Modified
p. 147 → 176
• All keying material is deleted from the HSM(s) and the server /computer platforms prior to testing.
Modified
p. 147 → 176
• Key used for production keys must never be present or used in a test system, and
Modified
p. 147 → 176
• 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. 148 → 177
• Known only to HSMs at the minimum number of facilities consistent with effective system operations.
Modified
p. 148 → 177
• Interview personnel and observe key-generation processes to verify that unique keys or sets of keys are generated for each acquiring organization.
Modified
p. 148 → 177
This means that 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 that 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. 148 → 177
20-2a Determine whether any transaction-originating terminals interface with multiple acquiring organizations. If so:
Modified
p. 148 → 177
• Examine documented procedures for generating all types of keys and verify the procedures ensure that unique keys or sets of keys are used for each acquiring organization and are totally independent and not variants of one another.
Removed
p. 149
Different BDKs for each financial institution Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model Different BDKs by geographic region, market segment, platform, or sales unit Injection vendors must use at least one unique Base Derivation Key (BDK) per acquiring organization, and must be able to support segmentation of multiple BDKs of acquiring organizations.
The POI must have a completely different and unique key, or set of keys, for each acquiring organization.
These different keys, or sets of keys, must be totally independent and not variants of one another.
The POI must have a completely different and unique key, or set of keys, for each acquiring organization.
These different keys, or sets of keys, must be totally independent and not variants of one another.
Modified
p. 149 → 178
This requirement refers to the use of a single “base” key to derive master keys for many different POIs, using a key-derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for derivation of other keys once loaded, for example, as done with DUKPT.
This requirement refers to the use of a single “base” key to derive initial keys for many different POIs, using a key-derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for derivation of other keys once loaded, for example, as done with DUKPT.
Modified
p. 149 → 178
20-3.a Examine documented procedures and observe processes for generating master keys. Verify the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:
20-3.a Examine documented procedures and observe processes for generating initial keys. Verify the following is implemented where initial keys are generated by a derivation process and derived from the same Base Derivation Key:
Modified
p. 149 → 178
• Unique data is used for the derivation process such that all transaction-originating POIs receive unique secret keys.
Modified
p. 149 → 178
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.
Modified
p. 149 → 178
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. 149 → 179
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. 149 → 179
20-4.a Examine documented key-generation and injection procedures to verify that the following is required when injecting keys into a single POI for more than one acquiring organization:
20-4.a Examine documented key-generation and injection procedures to verify that entities processing or injecting DUKPT or other key-derivation methodologies incorporate a segmentation strategy in their environments using one or more of the following techniques:
Removed
p. 150
PIN Security Requirements Testing Procedures 20-4.b Observe processes for generation and injection of keys into a single POI for more than one acquiring organization, to verify:
The POI has a completely different and unique key, or set of keys, for each acquiring organization.
These different keys, or sets of keys, are totally independent and not variants of one another.
The POI has a completely different and unique key, or set of keys, for each acquiring organization.
These different keys, or sets of keys, are totally independent and not variants of one another.
Modified
p. 150 → 179
• Keys must be uniquely identifiable in all hosts and POI Devices⎯e.g., EPPs/PEDs. Keys must be identifiable via cryptographically verifiable means⎯e.g., through the use of digital signatures or key check values.
Modified
p. 150 → 179
• Key pairs must be unique per POI device⎯e.g., EPPs and PEDs.
Modified
p. 150 → 179
• The mechanisms utilized for mutual device authentication for both the host and the POI PED.
Modified
p. 150 → 179
• Cryptographic mechanisms exist to uniquely identify the keys.
Modified
p. 150 → 179
• Key pairs used by POI devices are unique per device.
Modified
p. 151 → 180
21-2 Wherever key components are used, they have the following properties:
21-2 Wherever key components/shares are used, they have the following properties:
Modified
p. 151 → 180
21-2 Examine documented procedures and interview responsible personnel to determine all instances where key components are used.
21-2 Examine documented procedures and interview responsible personnel to determine all instances where key components/shares are used.
Modified
p. 151 → 180
21-2.2 Observe processes for constructing cryptographic keys to verify that at least two key components are required for each key construction.
21-2.2 Observe processes for constructing cryptographic keys to verify that at least two key components/shares are required for each key construction.
Modified
p. 151 → 180
Some key-injection platforms use personal-computer (PC)-based software applications or similar devices whereby clear-text secret and/or private keys and/or their components exist in unprotected memory outside the secure boundary of an SCD for loading keys. Such systems do not therefore meet this requirement. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. The exploitation of some of the weaknesses could be possible without collusion. Therefore, key-injection facilities that use PC-based key-loading software platforms …
Some key-injection platforms use personal-computer (PC)-based software applications or similar devices whereby clear-text secret and/or private keys and/or their components exist in memory outside the secure boundary of an SCD for loading keys. Such systems do not therefore meet this requirement. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. The exploitation of some of the weaknesses could be possible without collusion. Therefore, key-injection facilities that use PC-based key-loading software platforms whereby …
Modified
p. 151 → 180
21-1.a Examine documented procedures for key storage and usage to verify that secret or private keys only exist in one or more approved forms at all times when stored.
Modified
p. 151 → 180
21-2.1 Review processes for creating key components to verify that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key.
21-2.1 Examine processes for creating key components to verify that knowledge of any one key component or share does not convey any knowledge of any part of the actual cryptographic key.
Modified
p. 152 → 181
For example, in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian must not then be assigned component B or C, as this would give them knowledge of two components, which gives them ability …
For example, in an m-of-n scheme (which must use a recognized secret- sharing scheme such as Shamir), where only two of any three shares are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one share. If a custodian was previously assigned share A, which was then reassigned, the custodian must not then be assigned share B or C, as this would give them knowledge of two shares, which gives them …
Modified
p. 152 → 181
21-2.3.a Examine documented procedures for the use of key components and interview key custodians and key-management supervisory personnel to verify that each key component is assigned to a specific individual, or set of individuals, who are designated as key custodians for that component.
21-2.3.a Examine documented procedures for the use of key components and interview key custodians and key-management supervisory personnel to verify that each key component or share is assigned to a specific individual, or set of individuals, who are designated as key custodians for that component/share.
Modified
p. 152 → 181
21-2.3.b Observe key-component access controls and key-custodian authorizations/assignments to verify that all individuals with access to key components are designated as key custodians for those particular components.
21-2.3.b Observe key-component access controls and key-custodian authorizations/assignments to verify that all individuals with access to key components or shares are designated as key custodians for those particular components/shares.
Modified
p. 152 → 181
21-2.4 Procedures exist to ensure any custodian never has access to sufficient key components or shares of a secret or private key to reconstruct a cryptographic key.
21-2.4 Procedures exist to ensure that no custodian ever has access to sufficient key components or shares of a secret or private key to reconstruct a cryptographic key.
Modified
p. 152 → 181
In an m-of-n scheme where n =5 and where all three components are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key components (for example, component A and component B), as a second custodian (with, in this example, component C) would be required to reconstruct the final key, ensuring that dual control is maintained.
In an m-of-n scheme where n=5 and where all three shares are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key shares (for example, share A and share B); and a second custodian (with, in this example, share C) would be required to reconstruct the final key, ensuring that dual control is maintained.
Modified
p. 152 → 181
21-2.4.a Examine documented procedures for the use of key components to verify that procedures ensure that any custodian never has access to sufficient key components to reconstruct a cryptographic key.
21-2.4.a Examine documented procedures for the use of key components/shares to verify that procedures ensure that no custodian ever has access to sufficient key components or shares to reconstruct a secret or private cryptographic key.
Modified
p. 152 → 181
21-2.4.b Examine key-component access controls and access logs to verify that authorized custodians cannot access sufficient key components to reconstruct a cryptographic key.
21-2.4.b Examine key-component access controls and access logs to verify that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key.
Modified
p. 152 → 181
21-3 Key components must be stored as follows: 21-3 Examine documented procedures, interview responsible personnel and inspect key-component storage locations to verify that key components are stored as follows:
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. 153 → 182
PIN Security Requirements Testing Procedures 21-3.1 Key components that exist in clear text outside of an SCD must be sealed in opaque, pre-numbered tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.
PIN Security Requirements Testing Procedures 21-3.1 Key components that exist in clear text outside of an SCD must be sealed in individual opaque, pre-numbered, tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.
Modified
p. 153 → 182
21-3.1.b Inspect any tamper-evident packaging used to secure key components and ensure that it prevents the determination of the key component without visible damage to the packaging.
21-3.1.b Inspect any tamper-evident packaging used to secure key components •e.g., is the package sufficiently opaque to prevent reading of a component
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
Modified
p. 153 → 182
Components/shares for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers.
Modified
p. 153 → 182
21-3.2 Inspect each key component storage container and verify the following:
21-3.2 Inspect each key component/share storage container and verify the following:
Modified
p. 153 → 182
• Key components/shares for different custodians are stored in separate secure containers.
Modified
p. 153 → 182
• Each secure container is accessible only by the custodian and/or designated backup(s).
Modified
p. 153 → 182
21-3.3 If a key component is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner (or designated backup(s)) must have possession of both the token and its access code.
21-3.3 If a key component/share is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner⎯or designated backup(s)⎯must have possession of both the token and its access code.
Modified
p. 153 → 182
Note: Tamper-evident, authenticable packaging (opacity may be envelopes within tamper-evident packaging) used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card, contactless card, or other media that can be read without direct physical contact, the packaging …
Note: Tamper-evident, authenticable packaging (opacity may be envelopes within tamper-evident packaging) used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card, or other media that can be read without direct physical contact, the packaging should be …
Modified
p. 153 → 182
21-3.1.a Examine key components and storage locations to verify that components are stored in 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. 153 → 182
21-3.1.c Interview responsible personnel to determine that clear-text key components do not exist in any other locations, including in non-secure containers, in databases, on floppy disks, or in software programs.
21-3.1.c Interview responsible personnel to determine that clear-text key components do not exist in non-secure containers such as databases or in software programs.
Modified
p. 153 → 182
21-3.2 Key components for each specific custodian must be stored in a separate secure container that is accessible only by the custodian and/or designated backup(s).
21-3.2 Key components/shares for each specific custodian must be stored in a separate secure container that is accessible only by the custodian and/or designated backup(s).
Modified
p. 154 → 183
Requirement 22: Procedures must exist and must be demonstrably in use to replace any known or suspected compromised key, its subsidiary keys (those keys encrypted with the compromised key), and keys derived from the compromised key, to a value not feasibly related to the original key.
Requirement 22: Procedures must exist and must be demonstrably in use to replace any key determined to be compromised, its subsidiary keys (those keys encrypted with the compromised key), and keys derived from the compromised key, to values not feasibly related to the original keys.
Modified
p. 154 → 183
22-1.1 Key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.
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. 154 → 184
Known or suspected substitution of a secret key must result in the replacement of that key and any associated key-encipherment keys.
Known or suspected substitution of a secret key must result in the replacement of that key and based on an analysis of how the key was substituted, any associated key-encipherment keys that may have been compromised.
Modified
p. 154 → 184
• Use of that key is halted, and the key is replaced with a new unique key.
Modified
p. 154 → 184
• 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. 154 → 184
• The replacement key must not be a variant of the original key, or an irreversible transformation of the original key.
Modified
p. 154 → 184
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 …
PIN Security Requirements Testing Procedures 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 …
Removed
p. 155
Missing secure cryptographic devices Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 22-1.5 Interview responsible personnel and review documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
Modified
p. 155 → 184
• Specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Modified
p. 155 → 184
22-1.4.a Interview responsible personnel and review documented procedures to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
22-1.4.a Interview responsible personnel and examine documented procedures to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
Modified
p. 155 → 184
• A damage assessment including, where necessary, the engagement of outside consultants.
Modified
p. 155 → 184
• Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
Modified
p. 155 → 184
22-1.4 A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including:
Modified
p. 155 → 185
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. 155 → 185
• Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation 22-2 If attempts to load a secret key or key component into a KLD or POI fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original …
Modified
p. 156 → 186
23-1 Any key generated with a reversible process (such as a variant of a key) of another key must be protected in the same manner as the original key•that is, under the principles of dual control and split knowledge. Variants of the same key may be used for different purposes, but must not be used at different levels of the key hierarchy. For example, reversible transformations must not generate key-encipherment keys from PIN keys.
23-1 Any key generated with a reversible process (such as a variant of a key) of another key must be protected in the same manner as the original key•that is, under the principles of dual control and split knowledge. Variants of the same key may be used for different purposes but must not be used at different levels of the key hierarchy. For example, reversible transformations must not generate key-encipherment keys from PIN keys.
Modified
p. 156 → 187
23-2.b Review vendor documentation to determine support for key variants.
23-2.b Examine vendor documentation to determine support for key variants.
Modified
p. 156 → 187
23-2.c Via review of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys used, determine that variants of the MFK are not used external to the logical configuration that houses the MFK.
23-2.c Via examination of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys used, determine that variants of the MFK are not used external to the logical configuration that houses the MFK.
Modified
p. 156 → 187
23-2 An MFK used by host processing systems for encipherment of keys for local storage
•and variants of the MFK
•must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local storage shall not be used for other purposes, such as key conveyance between platforms that are not part of the same logical configuration.
•and variants of the MFK
•must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local storage shall not be used for other purposes, such as key conveyance between platforms that are not part of the same logical configuration.
PIN Security Requirements Testing Procedures 23-2 An MFK used by host processing systems for encipherment of keys for local storage
•and variants of the MFK
•must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local storage shall not be used for other purposes, such as key conveyance between platforms that are not part of the same logical configuration.
•and variants of the MFK
•must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local storage shall not be used for other purposes, such as key conveyance between platforms that are not part of the same logical configuration.
Modified
p. 157 → 187
Such transformations are only used to generate different types of key- encrypting keys from an initial key-encrypting key, or working keys with different purposes from another working key.
Such transformations are only used to generate different types of key- encrypting keys from an initial key-encrypting key or working keys with different purposes from another working key.
Modified
p. 157 → 187
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as a PIN key, MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key- encrypting keys.
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as a PIN key, MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key-encrypting keys.
Modified
p. 157 → 187
• Variants used as KEKs must only be calculated from other key- encrypting keys.
Modified
p. 157 → 187
• Variants of working keys must only be calculated from other working keys.
Modified
p. 157 → 187
23-3 Reversible key transformations are not used across different levels of the key hierarchy. For example, reversible transformations must not generate working keys (e.g., PEKs) from key-encrypting keys.
Modified
p. 157 → 187
Note: Using transforms of keys across different levels of a key hierarchy
•for example, generating a PEK key from a key-encrypting key•increases the risk of exposure of each of those keys.
•for example, generating a PEK key from a key-encrypting key
Note: Using transformations of keys across different levels of a key hierarchy
•for example, generating a PEK key from a key-encrypting key
•for example, generating a PEK key from a key-encrypting key
Modified
p. 157 → 188
24-1.c Review storage locations for the sample of destroyed keys to verify they are no longer kept.
24-1.c Examine storage locations for the sample of destroyed keys to verify they are no longer kept.
Removed
p. 158
PIN Security Requirements Testing Procedures 24-2 The procedures for destroying keys or key components that are no longer used or that 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. This must be accomplished by use of a cross-cut shredder, pulping or burning. Strip-shredding is not sufficient.
Modified
p. 158 → 188
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.
24-2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media types in all permissible forms
Modified
p. 158 → 189
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.
PIN Security Requirements Testing Procedures 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. 158 → 189
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. 158 → 189
24-2.3 Key components for keys other than the HSM MFK that have been successfully loaded and confirmed as operational must also be destroyed, unless the HSM does not store the encrypted values on a database but only stores the subordinate keys internal to the HSM. BDKs used in KLDs may also be stored as components where necessary to reload the KLD.
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.
Removed
p. 159
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date for the custodian’s access Signature of management authorizing the access 25-1.3 Examine all key-custodian forms to verify that they include the following:
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date for the custodian’s access Signature of management authorizing the access
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date for the custodian’s access Signature of management authorizing the access
Modified
p. 159 → 189
• Key custodian(s) are designated for each component.
Modified
p. 159 → 189
• The fewest number of key custodians is assigned as necessary to enable effective key management.
Modified
p. 159 → 189
25-1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. Key custodians must be employees or contracted personnel 25-1.1 Review key-custodian assignments for each component to verify that:
25-1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. Key custodians must be employees or contracted personnel 25-1.1 Examine key-custodian assignments for each component to verify that:
Modified
p. 159 → 190
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. 160 → 191
• Key custodians that form the necessary threshold to create a key do not directly report to the same individual.
Modified
p. 160 → 191
• Neither direct reports nor the direct reports in combination with their immediate supervisors possess the necessary threshold of key components sufficient to form any given key.
Modified
p. 160 → 191
Organizations that are of such insufficient size that they cannot support the reporting-structure requirement must ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian), receive explicit training to instruct them from sharing key components with their direct manager and must sign key-custodian agreements that includes an attestation to the requirement.
Organizations that are of insufficient size that they cannot support the reporting-structure requirement must:
• Ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian);
• Receive explicit training to instruct them from sharing key components with their direct manager;
• Sign key-custodian agreements that include an attestation to the requirement; and
• Receive training that includes procedures to report any violations.
• Ensure key custodians do not report to each other (i.e., the manager cannot also be a key custodian);
• Receive explicit training to instruct them from sharing key components with their direct manager;
• Sign key-custodian agreements that include an attestation to the requirement; and
• Receive training that includes procedures to report any violations.
Modified
p. 160 → 191
• Ensure key custodians do not report to each other.
Modified
p. 160 → 191
• Receive explicit training to instruct them from sharing key components with their direct manager.
Modified
p. 160 → 191
• Sign key-custodian agreement that includes an attestation to the requirement.
Modified
p. 160 → 191
• Ensure training includes procedures to report any violations.
Modified
p. 160 → 192
• Loaded to an SCD 26-1.b Examine log files and audit log settings to verify that logs include the following:
Modified
p. 160 → 192
• Removed from secure storage
Removed
p. 161
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable)
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable) 26-1.b Review log files and audit log settings to verify that logs include the following:
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable) 26-1.b Review log files and audit log settings to verify that logs include the following:
Modified
p. 161 → 193
27-1 If backup copies of secret and/or private keys exist, confirm that they are maintained in accordance with the same requirements as are followed for the primary keys.
27-1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as are followed for the primary keys.
Modified
p. 161 → 193
• Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys.
Modified
p. 161 → 193
PIN Security Requirements Testing Procedures 26-1 (continued) At a minimum, logs must include the following:
PIN Security Requirements Testing Procedures
Modified
p. 161 → 193
• Inspect backup storage locations and access controls or otherwise verify through examination of documented procedures and interviews of personnel that backups are maintained as follows:
Modified
p. 161 → 193
• Creation (including cloning) must require a minimum of two authorized individuals to enable the process.
Modified
p. 161 → 193
• The creation of any backup copies requires at least two authorized individuals to enable the process.
Modified
p. 162 → 194
• Management of personnel changes, including revocation of access control and other privileges when personnel move 28-1.a Examine documented procedures for key-administration operations to verify they include:
Modified
p. 162 → 194
• Management of personnel changes, including revocation of access control and other privileges when personnel move 28-1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
Modified
p. 162 → 194
28-1 Written procedures must exist, and all affected parties must be aware of those procedures. All activities related to key administration performed by a key-injection facilities must be documented. This includes all aspects of key administration, as well as:
28-1 Written procedures must exist, and all affected parties must be aware of those procedures. All activities related to key administration must be documented. This includes all aspects of key administration, as well as:
Modified
p. 162 → 195
29-1.a Review documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys:
29-1.a Examine documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys:
Modified
p. 162 → 195
Secure areas must be established for the inventory of PEDs that have not had keys injected. The area must have extended walls from the real floor to the real ceiling using sheetrock, wire mesh, or equivalent. Equivalence can be steel cages extending floor to real ceiling. The cages can have a steel cage top in lieu of the sides extending to the real ceiling. The cages must have locks (with logs) or badge control with logging for entry.
Secure rooms must be established for inventory that includes securing PEDs that have not had keys injected. The area must have extended walls from the real floor to the real ceiling using sheetrock, wire mesh, or equivalent. Equivalence can be steel cages extending floor to real ceiling. The cages can have a steel cage top in lieu of the sides extending to the real ceiling. The cages must have locks (with logs) or badge control with logging for entry.
Removed
p. 163
29-1.1 Controls must be implemented to protect POIs and other SCDs from unauthorized access up to point of deployment.
29-1.1.2 Examine vendor documentation or other information sources to identify default keys (such as keys that are pre-installed for testing purposes), passwords, or data. Observe implemented processes and interview personnel to verify that default keys or passwords are not used.
29-1.1.2 POIs and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords.
29-1.1.2 Examine vendor documentation or other information sources to identify default keys (such as keys that are pre-installed for testing purposes), passwords, or data. Observe implemented processes and interview personnel to verify that default keys or passwords are not used.
29-1.1.2 POIs and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords.
Modified
p. 163 → 195
29-1.1 Review documented procedures to verify controls are defined to protect POIs and other SCDs from unauthorized access up to point of deployment.
29-1.1 Examine documented procedures to verify controls are defined to protect POIs and other SCDs from unauthorized access up to point of deployment.
Modified
p. 163 → 195
29-1.b Observe processes and interview personnel to verify that processes are followed to provide the following assurances prior to the loading of cryptographic keys:
Removed
p. 164
All personnel with access to POIs and other SCDs are authorized by management.
Modified
p. 164 → 196
• All personnel with access to POIs and other SCDs are authorized by management in an auditable manner.
Modified
p. 164 → 196
• The authorizations are reviewed annually.
Modified
p. 164 → 196
29-1.1.3.b For a sample of POIs and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in the formal list have access to devices.
29-1.1.3.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. 164 → 196
29-2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt through to placement into service.
29-2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt to placement into service.
Modified
p. 164 → 196
29-2.b For a sample of devices, review documented records and interview responsible personnel to verify the chain of custody is maintained from receipt to placement into service.
29-2.b For a sample of devices, examine documented records and interview responsible personnel to verify the chain of custody is maintained from receipt to placement into service.
Modified
p. 164 → 196
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.
Modified
p. 164 → 196
29-2.c Verify that the chain-of-custody records identify responsible personnel for each interaction with the device
29-2.c Verify that the chain-of-custody records identify responsible personnel for each interaction with the device.
Modified
p. 165 → 197
PIN Security Requirements Testing Procedures 29-3 Implement physical protection of devices from the manufacturer’s facility up to the point of key-insertion and deployment, through one or more of the following.
PIN Security Requirements Testing Procedures 29-3 Implement physical protection of devices from the manufacturer’s facility up to the point of key-insertion and deployment, through one or more of the following:
Modified
p. 165 → 197
• 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. 165 → 197
• 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. 165 → 197
• A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. The SCD used for key-insertion verifies the presence of the correct “transport-protection token” before overwriting this value with the initial key, and the device is further protected until deployment.
Modified
p. 165 → 197
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. 165 → 198
• Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been subject to any unauthorized access or modifications.
Modified
p. 165 → 198
Devices must not be re-installed unless there is assurance they have not been tampered with or compromised. (Note: This control must be used in conjunction with one of the other methods.) o Controls exist and are in use to ensure that all physical and logical controls and anti-tamper mechanisms used are not modified or removed.
Devices must not be re-installed unless there is assurance they have not been tampered with or compromised.
Removed
p. 166
29-4.c Determine the adequacy of those controls in enforcing dual control.
• both in-service and spare or back-up devices
•throughout their life cycle.
HSMs used for acquiring functions shall not be configured to output clear-text PINs.
• both in-service and spare or back-up devices
•throughout their life cycle.
HSMs used for acquiring functions shall not be configured to output clear-text PINs.
Modified
p. 166 → 198
•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
•both deployed and spare or back-up devices
Modified
p. 166 → 198
29-4.b Interview responsible personnel and physically verify the dual- control mechanism used to prevent substitution or tampering of HSMs
29-4.b Interview responsible personnel and physically verify the dual-control mechanism used to prevent substitution or tampering of HSMs •both in service and spare or back-up devices
•throughout their life cycle.
•throughout their life cycle.
Modified
p. 166 → 198
Note: Documents used for this process must be received via a different communication channel•i.e., the control document used must not have arrived with the equipment. An example of how serial numbers may be documented by the sender includes but is not limited to the manufacturer’s invoice or similar document 29-4.1.a Interview responsible personnel to verify that device serial numbers are compared to the serial number documented by the sender.
Note: Documents used for this process must be received via a different communication channel•i.e., the control document used must not have arrived with the equipment. An example of how serial numbers may be documented by the sender includes but is not limited to the manufacturer’s invoice or similar document.
Modified
p. 166 → 198
29-4.1.b For a sample of received devices, review sender documentation sent via a different communication channel than the devices shipment (for example, the manufacturer’s invoice or similar documentation) used to verify device serial numbers. Examine the record of serial-number validations to confirm the serial number for the received device was verified to match that documented by the sender.
29-4.1.b For a sample of received devices, examine sender documentation sent via a different communication channel than the device’s shipment (for example, the manufacturer’s invoice or similar documentation) used to verify device serial numbers. Examine the record of serial-number validations to confirm the serial number for the received device was verified to match that documented by the sender.
Modified
p. 166 → 199
Requirement 3, or non-ISO PIN-block formats must not be supported without a defined documented and approved business need.
Modified
p. 166 → 199
29-4.2.c For a sample of HSMs, review the configuration settings to determine that only authorized functions are enabled.
29-4.2.c For a sample of HSMs, examine the configuration settings to determine that only authorized functions are enabled.
Modified
p. 166 → 199
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 in PIN-processing equipment 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. 166 → 199
29-4.2.b Examine documentation of the HSM configuration settings from past commissioning events to determine that the functions and commands enabled are in accordance with the security policy.
Modified
p. 166 → 199
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. 167 → 199
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. 167 → 200
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. 167 → 200
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. 168 → 201
30-3 Processes must exist to ensure that key injection operations are performed and reconciled on an inventory of pre-authorized devices.
30-3 Processes must exist to ensure that key-injection operations are performed and reconciled on an inventory of pre-authorized devices.
Modified
p. 168 → 201
• Each production run must be associated with a predefined inventory of identified POI devices to be injected or initialized with keys.
Modified
p. 168 → 201
• Unauthorized personnel must not be able to modify this inventory without detection.
Modified
p. 168 → 201
• All POI devices to be initialized with keys on a production run must be identified and accounted for against the inventory.
Modified
p. 168 → 201
• Unauthorized POI devices submitted for injection or initialized must be rejected by the injection platform and investigated.
Modified
p. 168 → 201
• Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices must be identified and accounted for against the inventory.
Modified
p. 168 → 201
30.3.a Obtain and review documentation of inventory control and monitoring procedures. Determine that the procedures cover:
30.3.a Obtain and examine documentation of inventory control and monitoring procedures. Determine that the procedures cover:
Modified
p. 168 → 201
• Each production run is associated with a predefined inventory of identified POI devices to be injected or initialized with keys.
Modified
p. 168 → 201
• Unauthorized personnel are not able to modify this inventory without detection.
Modified
p. 168 → 201
• All POI devices to be initialized with keys on a production run are identified and accounted for against the inventory.
Modified
p. 168 → 201
• Unauthorized POI devices submitted for injection or initialized are rejected by the injection platform and investigated.
Modified
p. 168 → 201
• Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices are identified and accounted for against the inventory.
Modified
p. 169 → 202
• Procedures require that all secret and private keys and key material stored within the device be securely destroyed.
Modified
p. 169 → 202
• Procedures cover all devices removed from service or for repair.
Modified
p. 169 → 202
31-1.1.a Review documented procedures for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes.
31-1.1.a Examine documented procedures for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes.
Modified
p. 169 → 202
If a key-injection facility receives a used device to reload with keys, procedures shall ensure that old keys that may be in the device are destroyed prior to loading of new keys. (The used device should have had its keys destroyed when it was removed from service, but this is a prudent secondary check that the keys were destroyed.) 31-1 Procedures are in place to ensure that any SCDs to be removed from service
•e.g., retired, or returned for repair
•are not …
•e.g., retired, or returned for repair
•are not …
If a key-injection facility receives a used device to reload with keys, procedures shall ensure that old keys that may be in the device are destroyed prior to loading of new keys. (The used device should have had its keys destroyed when it was removed from service, but this is a prudent secondary check that the keys were destroyed.) 31-1 Procedures are in place to ensure that any SCDs to be removed from service
•e.g., retired, or returned for repair
•are not …
•e.g., retired, or returned for repair
•are not …
Modified
p. 169 → 202
31-1.1.b Interview personnel and observe demonstration (if HSM is available) of processes for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes 31-1.2 Keys are rendered irrecoverable (for example, zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed prior to leaving the dual-control area to prevent the disclosure of any sensitive data or keys.
31-1.1.b Interview personnel and observe demonstration (if HSM is available) of processes for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes 31-1.2 Keys are rendered irrecoverable (for example, zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.
Modified
p. 170 → 203
PIN Security Requirements Testing Procedure 31-1.3 SCDs being decommissioned are tested and inspected to ensure keys have been rendered irrecoverable.
PIN Security Requirements Testing Procedures 31-1.3 SCDs being decommissioned are tested and inspected to ensure keys have been rendered irrecoverable.
Removed
p. 171
To enable any manual key-encryption functions and any key- encryption functions that occur outside of normal transaction processing; To place the device into a state that allows for the input or output of clear-text key components; For all access to key-loading devices (KLDs 32-1.3 Examine dual-control mechanisms and observe authorized personnel performing the defined activities to confirm that dual control is implemented for the following:
Modified
p. 171 → 204
Physical keys, authorization codes, passwords, or other enablers must be managed so that no one person can use both the enabler(s) and the device, which can create cryptograms of known keys or key components under a key-encipherment key used in production.
Physical keys, authorization codes, passwords/authentication codes, or other enablers must be managed so that no one person can use both the enabler(s) and the device, which can create cryptograms of known keys or key components under a key-encipherment key used in production.
Modified
p. 171 → 204
PIN Security Requirements Testing Procedure 32-1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
PIN Security Requirements Testing Procedures 32-1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
Modified
p. 171 → 204
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 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.
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. 171 → 204
For devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian.
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. 171 → 204
32-1.2 Passwords used for dual control must each be of at least five numeric and/or alphabetic characters.
32-1.2 Passwords/authentication codes used for dual control must each be of at least five numeric and/or alphabetic characters.
Modified
p. 171 → 204
32-1.2 Observe password policies and configuration settings to confirm that passwords used for dual control must be at least five numeric and/or alphabetic characters.
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. 171 → 204
• To enable any manual key-encryption functions, and any key- encryption functions that occur outside of normal transaction processing;
Modified
p. 171 → 205
32-1.4.b Observe device configurations and interview device administrators to verify that HSMs, KLDs, and other SCDs used to generate or load cryptographic keys do not use default passwords.
32-1.4.b Observe device configurations and interview device administrators to verify that HSMs, KLDs, and other SCDs used to generate or load cryptographic keys do not use default passwords/authentication codes.
Modified
p. 171 → 205
32-1.4.a Examine password policies and documented procedures to confirm default passwords must not be used for HSMs, KLDs, and other SCDs used to generate or load cryptographic keys.
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.
Modified
p. 172 → 205
• Under the continuous supervision of at least two authorized people who ensure that any unauthorized use of the device would be detected.
Modified
p. 172 → 205
32-1.5 To detect any unauthorized use, devices are at all times within a secure room and either:
Modified
p. 172 → 205
Functionality of a key-injection facility may be located at a single physical location or distributed over a number of physical locations. Distributed KIF functionality may include key generation, CA functionality, key distribution and key injection. In order to mitigate the expanded attack surface of a distributed KIF, specific controls apply to a distributed architecture. If any secret or private keys or their components/shares appear in the clear outside of a SCD, Requirement 32-10 for a secure room must be met.
Functionality of a key-injection facility may be located at a single physical location or distributed over a number of physical locations. Distributed KIF functionality may include key generation, CA functionality, key distribution, and key injection. In order to mitigate the expanded attack surface of a distributed KIF, specific controls apply to a distributed architecture. This may occur within a single organization or across organizations. If any secret or private keys or their components/shares appear in the clear outside of a …
Modified
p. 172 → 205
32-8 Distributed functionality of the KIF that is used for generation and transfer of keys must communicate via mutually authenticated channels. All key transfers between distributed KIF functions must meet the requirements of Control Objective 3.
Modified
p. 172 → 206
PIN Security Requirements Testing Procedures 32-8.1 The KIF must ensure that keys are transmitted between KIF components in accordance with Control Objective 3.
Modified
p. 172 → 206
32-8.1.a Examine documented procedures for key conveyance or transmittal to verify that keys used between KIF components are addressed in accordance with applicable criteria in Control Objective 3.
Modified
p. 172 → 206
32-8.1.b Interview responsible personnel and observe conveyance processes to verify that the documented procedures are followed for key conveyance or transmittal for keys used between KIF components.
Modified
p. 172 → 206
32-8.2 The KIF must implement mutually authenticated channels for communication between distributed KIF functions•for example, between a host used to generate keys and a host used to distribute keys.
Modified
p. 172 → 206
32-8.2 Examine documented procedures to confirm they specify the establishment of a channel for mutual authentication of the sending and receiving devices.
Modified
p. 173 → 206
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. 173 → 206
32-8.4 The channel for mutual authentication is established using the requirements of Control Objective 4.
Modified
p. 173 → 206
32-8.4.a Examine documented procedures for key loading to hosts and POI devices to verify that they are in accordance with applicable criteria in Control Objective 4.
Modified
p. 173 → 206
32-8.4.a 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. 173 → 206
32-8.5 The KIF must implement a mutually authenticated channel for establishment of enciphered secret or private keys between POI devices and an HSM at the KIF.
Modified
p. 173 → 206
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. 173 → 207
• POI devices must validate authentication credentials of KDHs prior to any key transport, exchange, or establishment with that device.
Modified
p. 173 → 207
PIN Security Requirements Testing Procedures 32-8.6 Mutual authentication of the sending and receiving devices must be performed.
Modified
p. 173 → 207
• KIFs must validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
Modified
p. 173 → 207
• When a KLD is used as an intermediate device to establish keys between POIs and a KIF HSM it must not be possible to insert an unauthorized SCD into the flow without detection.
Modified
p. 173 → 207
32-8.6 Interview responsible personnel and observe processes for establishment of enciphered secret or private keys between sending and receiving devices to verify:
Modified
p. 173 → 207
• KIFs validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
Modified
p. 173 → 207
• POI devices validate authentication credentials of KLDs prior to any key transport, exchange, or establishment with that device.
Modified
p. 173 → 207
• When a KLD is used as an intermediate device to establish keys between POIs and a KIF HSM, it is not possible to insert an unauthorized SCD into the flow without detection 32-8.7 Mechanisms must exist to prevent a non-authorized host from injecting keys into POIs or an unauthorized POI from establishing a key with a legitimate KIF component.
Modified
p. 173 → 207
32-8.7 Examine documented procedures to confirm they define mechanisms to prevent an unauthorized host from performing key transport, key exchange, or key establishment with POIs.
Modified
p. 174 → 208
PIN Security Requirements Testing Procedure 32-10 The KIF must implement a physically secure area (secure room) for key injection where any secret or private keys or their components/shares appear in the clear outside of an SCD.
PIN Security Requirements Testing Procedures 32-9 The KIF must implement a physically secure room for key injection where any secret or private keys or their components/shares appear in memory outside the secure boundary of an SCD during the process of loading/injecting keys into an SCD.
Modified
p. 174 → 208
32-9.1 The secure room must have walls made of solid materials. In addition, if the solid walls do not extend from the real floor to the real ceiling, the secure room must also have extended walls from the real floor to the real ceiling using sheetrock or wire mesh.
Modified
p. 174 → 208
32-9.1 Inspect the secure room designated for key injection to verify that it is constructed with extended walls from the real floor to the real ceiling using sheetrock or wire mesh.
Modified
p. 174 → 208
32-9.2 Any windows into the secure room must be locked and protected by alarmed sensors.
Modified
p. 174 → 208
32-9.2.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors.
Modified
p. 174 → 209
PIN Security Requirements Testing Procedures 32-9.2.b Examine configuration of window sensors to verify that the alarm mechanism is active.
Modified
p. 174 → 209
32-9.3 Any windows must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
Modified
p. 174 → 209
32-9.3 Observe all windows in the secure room to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
Modified
p. 174 → 209
32-9.4 A solid-core door or a steel door must be installed to ensure that door hinges cannot be removed from outside the room.
Modified
p. 174 → 209
32-9.4 Inspect the secure room to verify that it is only accessed through a solid-core or a steel door, with door hinges that cannot be removed from outside the room.
Modified
p. 174 → 209
32-9.5 An electronic access control system (for example, badge and/or biometrics) must be in place that enforces:
Modified
p. 174 → 209
• Dual-access requirements for entry into the secure room, and
Modified
p. 174 → 209
32-9.5 Observe authorized personnel entering the secure room to verify that a badge-control system is in place that enforces the following requirements:
Modified
p. 174 → 209
• Anti-pass-back 32-9.6 The badge-control system must support generation of an alarm when one person remains alone in the secure room for more than 30 seconds.
Modified
p. 174 → 209
32-9.6 Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds.
Removed
p. 175
The entrance door, SCDs, both pre and post key injection, Any safes that are present, and The equipment used for key injection.
The entrance door, SCDs, both pre and post key injection, Any safes that are present, and The equipment used for key injection.
The entrance door, SCDs, both pre and post key injection, Any safes that are present, and The equipment used for key injection.
Modified
p. 175 → 209
32-9.7 CCTV cameras must record all activity, including recording events during dark periods through the use of infrared CCTV cameras or automatic activation of floodlights in case of any detected activity. This recording may be motion-activated. The recording must continue for at least a minute after the last pixel of activity subsides.
Modified
p. 175 → 209
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.
Modified
p. 175 → 209
32-9.8 Monitoring must be supported on a continuous (24/7) basis such that alarms can be resolved by authorized personnel.
Modified
p. 175 → 209
32-9.8 Inspect configuration of monitoring systems and interview monitoring personnel to verify that monitoring is supported on a continuous (24/7) basis and alarms can be resolved by authorized personnel.
Modified
p. 175 → 210
PIN Security Requirements Testing Procedures 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. 175 → 210
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. 175 → 210
32-9.9.b Inspect access-control configurations for the CCTV server/storage secure location and the key-injection secure room to identify all personnel who have access to each area. Compare access lists to verify that personnel with access to the key-injection secure room do not have access to the CCTV server/storage secure location.
Modified
p. 175 → 210
32-9.10 The CCTV cameras must be positioned to monitor:
Modified
p. 175 → 210
32-9.10 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor:
Modified
p. 175 → 210
32-9.11 CCTV cameras must be positioned so they do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.
Modified
p. 175 → 210
32-9.11 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.
Modified
p. 177 → 212
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 (§): The bit-strength of a double-length TDEA key depends on the availability to a potential attacker of pairs of plaintext and corresponding ciphertext enciphered with the key. A double-length TDEA key may only be assessed to have 112 bits of …
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 longer key lengths (see NIST SP800-131A) without any requirement for legacy support.
Removed
p. 178
Data Encryption Algorithm (DEA) refers to Triple DEA (TDEA) keys with non-parity bits. The RSA key size 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.
Modified
p. 178 → 213
1. DH implementations
• Entities must securely generate and distribute the system-wide parameters: generator g, prime numberp 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 shall generate a private key x and a public key y using the domain parameters (p, q, g).
• Entities must securely generate and distribute the system-wide parameters: generator g, prime number
1. DH 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 shall generate a private key x and a public key y using the domain parameters (p, q, g).
• 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 shall generate a private key x and a public key y using the domain parameters (p, q, g).
Removed
p. 180
Check value A computed value which is the result of passing a data value through a non-reversible algorithm. Check values are generally calculated using a cryptographic transformation, which takes as input a secret key and an arbitrary string and gives a cryptographic check value as output. The computation of a correct check value without knowledge of the secret key must not be feasible.
Modified
p. 180 → 215
Certification authority (CA) For purposes of these requirements, a certification authority is any entity signing public keys, whether in X.509 certificate based schemes or other designs for use in connection with the remote distribution of symmetric keys using asymmetric techniques.
Certification authority (CA) For purposes of these requirements, a certification authority is any entity signing public keys, whether in X.509 certificate-based schemes or other designs for use in connection with the remote distribution of symmetric keys using asymmetric techniques.
Removed
p. 181
The transformation of plaintext data into ciphertext data, The transformation of ciphertext data into plaintext data, A digital signature computed from data, The verification of a digital signature computed from data, An authentication code computed from data, or An exchange agreement of a shared secret.
Modified
p. 181 → 217
• Offer financial services to merchants or authorized third parties who accept such payment cards for merchandise, services, or cash disbursement, and directly or indirectly enter the resulting transaction receipt into interchange (acquirers).
Modified
p. 181 → 217
Data Encryption Algorithm (DEA) A published encryption algorithm used to protect critical information by enciphering data based upon a variable secret key. The Data Encryption Algorithm is defined in ANSI X3.92: Data Encryption Algorithm for encrypting and decrypting data. The algorithm is a 64-bit block cipher that uses a 64-bit key, of which 56 bits are used to control the cryptographic process and 8 bits are used for parity-checking to ensure that the key is transmitted properly.
Data Encryption Algorithm (DEA) A published encryption algorithm used to protect critical information by enciphering data based upon a variable secret key. The Data Encryption Algorithm is defined in ANSI X3.92: Data Encryption Algorithm for encrypting and decrypting data. The algorithm is a 64-bit block cipher that uses a 64-bit key, of which 56 bits are used to control the cryptographic process and 8 bits are used for parity checking to ensure that the key is transmitted properly.
Removed
p. 183
Hardware (host) security module An SCD that provides a set of secure cryptographic services, including but not limited to key generation, cryptogram creation, PIN translation and certificate signing
Modified
p. 183 → 219
Encrypting PIN pad (EPP) A device for secure PIN entry and encryption in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader, or rely upon external displays or card readers installed in the unattended device. An EPP is typically used in an ATM or other unattended device (e.g., an unattended kiosk or automated fuel dispenser) for PIN entry and is controlled by a device controller. An EPP has a clearly defined physical and logical boundary, …
Encrypting PIN pad (EPP) A device for secure PIN entry and encryption in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader or rely upon external displays or card readers installed in the unattended device. An EPP is typically used in an ATM or other unattended device (e.g., an unattended kiosk or automated fuel dispenser) for PIN entry and is controlled by a device controller. An EPP has a clearly defined physical and logical boundary, …
Modified
p. 183 → 219
• 1 + 1 = 0 FIPS Federal Information Processing Standard.
Removed
p. 184
Interchange The exchange of clearing records between financial institution customers.
Modified
p. 185 → 221
Key-distribution host (KDH) A KDH is a processing platform used in conjunction with HSM(s) that generates keys and securely distributes those keys to the EPP or PED and the financial processing platform communicating with those EPPs/PEDs. A KDH may be an application that operates on the same platform that is used for PIN translation and financial transaction processing. The KDH may be used in conjunction with other processing activities. A KDH shall not be used for certificate issuance, and must …
Key-distribution host (KDH) A KDH is a processing platform used in conjunction with HSM(s) that generates keys and securely distributes those keys to the EPP or PED and the financial processing platform communicating with those EPPs/PEDs. A KDH may be an application that operates on the same platform that is used for PIN translation and financial transaction processing. The KDH may be used in conjunction with other processing activities. A KDH shall not be used for certificate issuance and must …
Modified
p. 186 → 223
Master File Key (MFK) This is a symmetric key used to encrypt other cryptographic keys which are to be stored outside of the Hardware Security Module (HSM).
Master File Key (MFK) This is a symmetric key used to encrypt other cryptographic keys that are to be stored outside of the hardware security module (HSM).
Modified
p. 190 → 227
Split knowledge A condition under which two or more entities separately have key components that individually convey no knowledge of the resultant cryptographic key. The information needed to perform a process such as key formation is split among two or more people. No individual has enough information to gain knowledge of any part of the actual key that is formed.
Split knowledge A condition under which two or more entities separately have information (e.g., key components) that individually conveys no knowledge of the resulting combined information (e.g., a cryptographic key). The information needed to perform a process such as key formation is split among two or more people. No individual has enough information to gain knowledge of any part of the actual key that is formed.
Removed
p. 191
Two-factor authentication Two-factor authentication (“TFA” or “2FA”) is a system wherein two different factors are used in conjunction for authentication. Two-factor authentication typically is a signing-on process where a person proves his or her identity with two of the three methods: "something you know" (e.g., password or PIN), "something you have" (e.g., smartcard or token), or "something you are" (e.g., fingerprint or iris scan).
Modified
p. 191 → 229
• Provide a reasonable level of availability, reliability, and correct operation; and
Modified
p. 192 → 229
• Vending Machine Unattended payment terminal (UPT) A POS POI device where the transaction is initiated by the cardholder, and there is no immediate merchant support available. These include terminals such as:
Modified
p. 192 → 229
• Self-service devices
•ticketing/vending or car parking terminals.
•ticketing/vending or car parking terminals.