Document Comparison
PTS_PIN_Technical_FAQs_v2_August_2019.pdf
→
PCI_PIN_Technical_FAQs_v3_August_2025.pdf
61% similar
24 → 40
Pages
10189 → 17009
Words
89
Content Changes
Content Changes
89 content changes. 15 administrative changes (dates, page numbers) hidden.
Added
p. 4
Q 5 January 2020: Can an acquirer use third-party hosted HSM service⎯i.e., HSM in the cloud? A Yes, however the acquirer is responsible for ensuring that all applicable requirements regarding the management of the HSMs are met by the HSM cloud Provider.
Q 6 January 2020: Can an HSM as a Service (cloud) provider use third-party hosted data center facilities to house the HSMs? A Yes, subject to the following:
• The cloud provider must control all logical access. Data center operations staff must not have any logical access rights (administrator or operator) to the HSMs.
• The cloud provider must have appropriately placed CCTV cameras that are implemented consistent with PIN Requirement Annex B 32-9.7 and send images to a server controlled by the cloud provider at a site other than that of the data center hosting the HSMs⎯e.g., the cloud provider’s own site.
• Access to the cabinets housing the cloud provider’s …
Q 6 January 2020: Can an HSM as a Service (cloud) provider use third-party hosted data center facilities to house the HSMs? A Yes, subject to the following:
• The cloud provider must control all logical access. Data center operations staff must not have any logical access rights (administrator or operator) to the HSMs.
• The cloud provider must have appropriately placed CCTV cameras that are implemented consistent with PIN Requirement Annex B 32-9.7 and send images to a server controlled by the cloud provider at a site other than that of the data center hosting the HSMs⎯e.g., the cloud provider’s own site.
• Access to the cabinets housing the cloud provider’s …
Added
p. 14
Q 5 October 2023: RSA keys with a modulus of 2048 bits can be used for the conveyance of 128-bit AES keys. This is an exception to the requirement that any keys used in key conveyance must be of equal or greater strength then the key conveyed. Are there any other exceptions? A No. This exception is only permitted in scenarios where asymmetric remote-key distribution is being used to convey an AES-128 key to a POI or HSM. In all other cases both the key used for wrapping and the key used for signing must be of equal or greater strength then the key conveyed. Please note, the referenced exception is a recognition of limitations that exist in current cryptographic technologies. It should be expected that this exception will be sunset at some future point after the publication of appropriate industry standards.
Q 1 December (update) 2022: Does the loading of …
Q 1 December (update) 2022: Does the loading of …
Added
p. 31
Q 2 January (update) 2020: What are the minimum criteria for construct of Certification Authority room walls for offline⎯e.g., root⎯CAs? A Offline CAs (those used to issue certificates to other CAs and/or KDHs) are typically stored in a large safe when not in use. Thus, construction of CA walls using two layers of 5/8 inch sheet rock attached to metal studs is the minimum requirement for CA room walls. This does not preclude the need for CCTV and alarmed access with motion sensors.
Initial DUKPT keys are generated by a key derivation process and are therefore considered key generation.
Initial DUKPT keys are generated by a key derivation process and are therefore considered key generation.
Added
p. 33
Q 4 December 2024: Keys loaded to POI devices for the protection of cardholder data must meet the minimum key sizes defined in Normative Annex C. If an acquirer processor or merchant (Acquiring Entity) requires its independent KIF service provider to inject the POI devices of the processor or merchant with weaker keys than prescribed, is the KIF non- compliant to the PIN Security Requirements? A No, provided the KIF demonstrates the ability to the assessor for the injection of appropriately strong keys per Annex C. If weak keys are being injected at the explicit request of an Acquiring Entity, the liability for those keys is on the Acquirer. The KIF must maintain documentation regarding this request by the Acquirer. Furthermore, the assessor must note in the PIN ROC any Entity for which the KIF service provider has injected cryptographic keys that are not of appropriate strength.
PIN Security Requirement 12
Q …
PIN Security Requirement 12
Q …
Modified
p. 1
Payment Card Industry (PCI) PTS PIN Security Requirements Technical FAQs for use with Version 2
Payment Card Industry (PCI) PTS PIN Security Requirements Technical FAQs for use with Version 3
Modified
p. 3
Q 1 June 2015: Requirement 10 allows 2048 RSA keys to encrypt AES keys for transport. This is an exception to the general rule that key encryption keys must be of equal or greater strength to the keys they protect. Are there any other exceptions? A No. Entities implementing AES for the protection of PINs must protect any such keys at their host with keys of equal or greater strength when those keys are stored external to the HSM. For …
Q 1 June 2015: Requirement 10 allows 2048 RSA keys to encrypt AES keys for transport. This is an exception to the general rule that key-encryption keys must be of equal or greater strength to the keys they protect. Are there any other exceptions? A No. Entities implementing AES for the protection of PINs must protect any such keys at their host with keys of equal or greater strength when those keys are stored external to the HSM. For most …
Modified
p. 3
Q 2 July (update) 2017: Logs are required in a number of requirements for activities in connection with key management. What are the minimum contents of any such log? A 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), if applicable 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)
Q 2 July (update) 2017: Logs are required in a number of requirements for activities in connection with key management. What are the minimum contents of any such log? A 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), if applicable 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.
Modified
p. 3
Q 4 March 2017: Can TDES keys be used to encrypt AES keys for conveyance into a POI device. A Yes, but only for local key injection, i.e. directly cabled, and not over a network connection. Furthermore, because TDES keys are significantly weaker than AES keys, this must be treated as equivalent to clear text key injection and requires the use of a secure room as defined in requirement 32-10. Note that this specific restriction does not currently apply for …
Q 4 March 2017: Can TDES keys be used to encrypt AES keys for conveyance into a POI device? Yes, but only for local key injection⎯i.e., directly cable⎯and not over a network connection. Furthermore, because TDES keys are significantly weaker than AES keys, this must be treated as equivalent to clear-text key injection and requires the use of a secure room as defined in requirement 32-9.
Removed
p. 4
• Their HSM pre-dates PCI HSM.
• They may be using unapproved software (such as bespoke versions).
• The shipping requirements of PCI HSM were not met at the time they ordered the unit.
• They may not be able to deploy any “PCI mode” on their HSM.
• Their HSM vendor has not provided a PCI-approved version. This means that many entities will have to fall back on FIPS 140-2 certification. However, the following issues exist:
• A strict definition of “firmware” would include all the HSM vendor’s embedded software (rather than just the bootstrap, low level drivers, etc.). This would mean that no FIPS 140-2 certificates for PIN processing HSMs meet the requirement.
• A number of the FIPS certificates cover only the crypto module rather than the whole HSM.
• Algorithms may be covered by other NIST/FIPS certifications rather than having been included in the FIPS 140-2 certificate. For HSMs that were deployed prior …
• They may be using unapproved software (such as bespoke versions).
• The shipping requirements of PCI HSM were not met at the time they ordered the unit.
• They may not be able to deploy any “PCI mode” on their HSM.
• Their HSM vendor has not provided a PCI-approved version. This means that many entities will have to fall back on FIPS 140-2 certification. However, the following issues exist:
• A strict definition of “firmware” would include all the HSM vendor’s embedded software (rather than just the bootstrap, low level drivers, etc.). This would mean that no FIPS 140-2 certificates for PIN processing HSMs meet the requirement.
• A number of the FIPS certificates cover only the crypto module rather than the whole HSM.
• Algorithms may be covered by other NIST/FIPS certifications rather than having been included in the FIPS 140-2 certificate. For HSMs that were deployed prior …
Modified
p. 4 → 8
• The HSM’s FIPS 140-2 certificate must include at least the firmware required to load vendor- provided software components in a secure manner.
• The HSM’s FIPS 140-2 certificate must include at least the firmware required to load vendor-provided software components in a secure manner.
Modified
p. 4 → 8
Q 6 April 2016: Requirement 1 specifies that all hardware security modules (HSMs) are either FIPS140-2 Level 3 or higher certified, or PCI approved. If the using entity applies an update or patch to the HSM’s firmware, there may temporarily be a discrepancy between the listed approved versions, and the actual version in place. How can this be addressed during an assessment? A If the using entity has applied a vendor security patch resulting in an updated HSM firmware version, …
Q 2 April 2016: Requirement 1 specifies that all hardware security modules (HSMs) are either FIPS140-2 Level 3 or higher certified, or PCI approved. If the using entity applies an update or patch to the HSM’s firmware, there may temporarily be a discrepancy between the listed approved versions, and the actual version in place. How can this be addressed during an assessment? A If the using entity has applied a vendor security patch resulting in an updated HSM firmware version, …
Modified
p. 5 → 8
Q 7 April 2016: Requirement 1 specifies the use of FIPS or PCI approved devices. How are PCI approved devices identified on the PCI website? A These devices are identified by among other identifiers, with vendor name, model name/number, hardware version and firmware version
• all of which are required to match the listing. As described in the PCI PTS Device Testing and Approval Program Guide, vendors may use a combination of fixed and variable alphanumeric characters in the version numbers. …
• all of which are required to match the listing. As described in the PCI PTS Device Testing and Approval Program Guide, vendors may use a combination of fixed and variable alphanumeric characters in the version numbers. …
Q 3 April 2016: Requirement 1 specifies the use of FIPS or PCI approved devices. How are PCI approved devices identified on the PCI website? A These devices are identified by among other identifiers, with vendor name, model name/number, hardware version, and firmware version
• all of which are required to match the listing. As described in the PCI PTS Device Testing and Approval Program Guide, vendors may use a combination of fixed and variable alphanumeric characters in the version numbers. …
• all of which are required to match the listing. As described in the PCI PTS Device Testing and Approval Program Guide, vendors may use a combination of fixed and variable alphanumeric characters in the version numbers. …
Modified
p. 5 → 9
Q 8 December 2016: Entities acquiring (e.g., the processor) PIN-based transactions are responsible for maintaining an inventory of POI Devices. How does this apply where the acquiring entity does not purchase the POS or ATM devices? For example, a merchant or other third-party purchases and owns the devices. A Ultimately, the entity (typically a financial institution) sponsoring the usage of the devices into a payment network bears the responsibility for any non-compliance. However, the entity driving the devices must maintain …
Q 4 December 2016: Entities acquiring⎯e.g., the processor⎯PIN-based transactions are responsible for maintaining an inventory of POI Devices. How does this apply where the acquiring entity does not purchase the POS or ATM devices? For example, a merchant or other third-party purchases and owns the devices. A Ultimately, the entity (typically a financial institution) sponsoring the usage of the devices into a payment network bears the responsibility for any non-compliance. However, the entity driving the devices must maintain an inventory …
Modified
p. 5 → 9
Q 9 November 2018: In 2016, the NIST Cryptographic Module Validation Program adopted a five-year validation sunset program. This has resulted in a significant number of devices migrating from the Active Validation List to the Historical Validation List. Migration to this list reflects that the certificates and the documentation posted with them are more than 5 years old and have not been updated to reflect the latest NIST guidance and/or transitions, and may not accurately reflect how the module can …
Q 5 November 2018: In 2016, the NIST Cryptographic Module Validation Program adopted a five-year validation sunset program. This has resulted in a significant number of devices migrating from the Active Validation List to the Historical Validation List. Migration to this list reflects that the certificates and the documentation posted with them are more than 5 years old and have not been updated to reflect the latest NIST guidance and/or transitions and may not accurately reflect how the module can …
Modified
p. 6 → 9
Q 10 May 2019: PCI approved v1 HSMs expire in 2019. Can PCI approved HSMs with expired approvals continue to be used? A For clarification on the usage of PCI approved HSMs for which the approval has expired, contact the payment brand(s) of interest at: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-do-I-contact-the- payment-card-brands PIN Security Requirement 6
Q 6 July (update) 2022: For PCI approved HSMs that have had their approvals expire, can they continue to be used? A For clarification on the usage of PCI approved HSMs for which the approval has expired, contact the payment brand(s) of interest at: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-do-I-contact- the-payment-card-brands
Modified
p. 6 → 11
Q 11 May 2019: Printers used for printing key components must not be used for other purposes and must not be networked i.e., locally connected in a system that is dedicated to the printing of key components and is not connected to any other system. Are there any circumstances where the printing system can have connectivity for the conveyance of encrypted keys to another system related to PIN processing? A Yes, if the printing system is protected by a firewall(s) …
Q 1 May 2019: Printers used for printing key components must not be used for other purposes and must not be networked⎯i.e., locally connected in a system that is dedicated to the printing of key components and is not connected to any other system. Are there any circumstances where the printing system can have connectivity for the conveyance of encrypted keys to another system related to PIN processing? A Yes, if the printing system is protected by a firewall(s) from …
Modified
p. 6 → 11
• Fail to a configuration that denies all services and require a firewall administrator to re-enable services after a failure.
• Fail to a configuration that denies all services and require a firewall administrator to re- enable services after a failure.
Removed
p. 7
Q 12 May 2019: Printers used for printing key components must be managed under dual control, including the use of a secure room that meets the requirements of 32-9 in Annex B. Can a secure room used for printing key components meet a subset of the requirements in 32-9 and be compliant? A This requirement is under revision. The room must meet the baseline requirements for a secure room i.e., the room used must meet the minimal configuration for a secure room of requiring the use of an electronic access-control system (for example, badge and/or biometrics) to enter.
Effective 1 January 2020. the room must additionally:
• The room must have walls made of solid materials. The walls do not have to extend from true floor to true ceiling, but do need to extend form floor to ceiling
• Any windows into the secure room must be:
• Locked and protected by alarmed sensors.
• …
Effective 1 January 2020. the room must additionally:
• The room must have walls made of solid materials. The walls do not have to extend from true floor to true ceiling, but do need to extend form floor to ceiling
• Any windows into the secure room must be:
• Locked and protected by alarmed sensors.
• …
Modified
p. 7 → 12
• 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.
• CCTV cameras must be positioned so they do not monitor any clear-text keying materials, combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials; otherwise, custodians must position their bodies to obscure monitoring (per 6-3.8).
Removed
p. 8
Q 13 November 2015: Requirement 6-5 states that asymmetric-key pairs must either be:
• Generated by the device that will use the key pair; or
• If generated externally, 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.
• Devices used for key generation or key injection are securely stored when not in use.
Is this meant to be two separate requirements? A The first two bullets are options to each other. The third bullet is intended to be part of the second option. Further to this, additional information regarding management of key injection devices is contained in requirement 13-4.
• Generated by the device that will use the key pair; or
• If generated externally, 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.
• Devices used for key generation or key injection are securely stored when not in use.
Is this meant to be two separate requirements? A The first two bullets are options to each other. The third bullet is intended to be part of the second option. Further to this, additional information regarding management of key injection devices is contained in requirement 13-4.
Modified
p. 8 → 13
Q 14 April 2016: Are PCI PTS POI v1 or v2 devices able to use RSA 1024-bit length keys to encrypt for transmittal or conveyance of other cryptographic keys as part of key distribution using asymmetric techniques? A If the PCI PTS POI v1 or v2 device is capable of supporting 2048 RSA keys, then they must be used. Where support for 2048-bit RSA keys is not possible, 1024-bit RSA keys are permissible.
Q 1 April 2016: Are PCI PTS POI v1 or v2 devices able to use RSA 1024-bit length keys to encrypt for transmittal or conveyance of other cryptographic keys as part of key distribution using asymmetric techniques? A If the PCI PTS POI v1 or v2 device is capable of supporting 2048 RSA keys, then they must be used. Where support for 2048-bit RSA keys is not possible, 1024-bit RSA keys are permissible.
Modified
p. 9 → 13
Q 16 November 2018: PIN Security Requirement 10 states that RSA keys encrypting keys greater in strength than 80 bits (e.g. triple-length TDEA, AES) shall have a bit strength at least 112 bits (2048 RSA). Does this allow AES keys of any size to be encrypted with 2048 RSA keys? A No. The intent of the allowance of using RSA keys that are weaker in strength than the keys they transport is to leverage the cryptographic algorithms and key strengths …
Q 3 November 2018: PIN Security Requirement 10 states that RSA keys encrypting keys greater in strength than 80 bits⎯e.g., triple-length TDEA, AES⎯shall have a bit strength at least 112 bits (2048 RSA). Does this allow AES keys of any size to be encrypted with 2048 RSA keys? A No. The intent of the allowance of using RSA keys that are weaker in strength than the keys they transport is to leverage the cryptographic algorithms and key strengths in existing …
Modified
p. 9 → 15
Q 17 May (update) 2018: Some HSMs use laptop computers with terminal emulation software (e.g., VT-100) for loading clear-text secret or private key components/shares to the HSM due to the lack of availability of dumb terminals or secure cryptographic devices. What controls are required for this usage? A Effective 1 June 2019, 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. An organization using a computer …
Q 1 January (update) 2020: Some HSMs use laptop computers with terminal emulation software (e.g., VT-100) for loading clear-text secret or private key components/shares to the HSM due to the lack of availability of dumb terminals or secure cryptographic devices. What controls are required for this usage? A 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. An organization using a computer outside of a secure …
Removed
p. 10
• The computer is dedicated for the usage and is only operated under dual control
• A minimal OS is used, and no applications other than the terminal emulation software is present
• The computer is stored in a tamper evident authenticable (TEA) bag and logged when removed or placed back into storage
• The computer must be further controlled via storage in either a dual control safe or a dual control compartment within a single control safe
• The computer must be booted from a specially customized CD for boot up using a minimal OS image and the terminal emulation application and this CD stored in the same dual access controlled safe/compartment with the computer.
• The computer must not possess a hard drive or any other storage mechanism.
• A minimal OS is used, and no applications other than the terminal emulation software is present
• The computer is stored in a tamper evident authenticable (TEA) bag and logged when removed or placed back into storage
• The computer must be further controlled via storage in either a dual control safe or a dual control compartment within a single control safe
• The computer must be booted from a specially customized CD for boot up using a minimal OS image and the terminal emulation application and this CD stored in the same dual access controlled safe/compartment with the computer.
• The computer must not possess a hard drive or any other storage mechanism.
Modified
p. 10 → 12
• The computer must be used either locally via a dedicated physically connected cable or used in a controlled environment as defined in ISO 13491.
• The process is performed in a controlled or higher environment as defined in ISO 13491-2.
Modified
p. 10 → 15
Q 18 November 2015: Requirement 13-4 requires that key-loading devices 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. What would meet the requirement for securing the device when not in use? A Key loading/generation devices that are required to be securely stored when not in use require the use of a secure container(s) such as a safe or compartment therein, or …
Q 2 November 2015: Requirement 13-4 requires that key-loading devices 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. What would meet the requirement for securing the device when not in use? A Key loading/generation devices that are required to be securely stored when not in use require the use of a secure container(s) such as a safe or compartment therein, or …
Modified
p. 10 → 15
Q 19 August 2019: New deployments of FIPS 140-2 HSMs that have migrated to the NIST Cryptographic Module Validation Program Historical List are not allowed for new deployments (i.e., additional HSMs and not replacements of existing HSMs with like for like) after December 2019. Does this apply to other Secure Cryptographic Devices (SCDs) such as Key Loading Devices (KLDs) that are dependent upon FIPS certification to qualify as an SCD. A Yes it does apply to other SCDs used to …
Q 3 August 2019: New deployments of FIPS 140-2 HSMs that have migrated to the NIST Cryptographic Module Validation Program Historical List are not allowed for new deployments⎯i.e., additional HSMs and not replacements of existing HSMs with like for like⎯after December 2019. Does this apply to other Secure Cryptographic Devices (SCDs) such as Key Loading Devices (KLDs) that are dependent upon FIPS certification to qualify as an SCD? A Yes, it does apply to other SCDs used to meet PIN …
Modified
p. 10 → 16
Q 20 December 2017: Asymmetric key pairs or symmetric keys are commonly used for authentication of applications and for display prompts or to facilitate management (e.g., enable functionality) of HSMs. The private or secret keys associated with these activities frequently reside on smartcards, USB sticks, or other devices which do not qualify as SCDs, but are termed Hardware Management Devices (HMDs). How must these HMDs be managed to compensate for their inherent limitations? A These limitations have associated security risks …
Q 1 December 2017: Asymmetric key pairs or symmetric keys are commonly used for authentication of applications and for display prompts or to facilitate management⎯e.g., enable functionality⎯of HSMs. The private or secret keys associated with these activities frequently reside on smartcards, USB sticks, or other devices which do not qualify as SCDs, but are termed Hardware Management Devices (HMDs). How must these HMDs be managed to compensate for their inherent limitations? A These limitations have associated security risks which must …
Modified
p. 10 → 16
• If the HMD is decommissioned for any reason, all keying material within the HMD must be rendered irrecoverable in accordance with requirement 31
• If the HMD is decommissioned for any reason, all keying material within the HMD must be rendered irrecoverable in accordance with requirement 31.
Modified
p. 10 → 16
• If the HMD is required to generate keys, e.g., its own key pair, it must be capable of meeting requirement 5.
• If the HMD is required to generate keys⎯e.g., its own key pair⎯it must be capable of meeting requirement 5.
Removed
p. 11
Q 22 November 2015: Is the implementation of TR-31 the only method for meeting the requirement that encrypted symmetric keys must be managed in structures called key blocks? A No. TR-31 or any equivalent method can be used. Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods. Any binding or unbinding of key-usage information from the key must take place within the secure cryptographic boundary of the device.
Q 24 July 2019: PIN Security Requirement 18-3 requires the implementation of key blocks.
Q 24 July 2019: PIN Security Requirement 18-3 requires the implementation of key blocks.
Modified
p. 11 → 16
• If the HMD is conveyed between locations, the mechanisms (e.g., PINs) to become operational must not be conveyed using the same communication channel as the HMD. Both the HMD and the operational mechanisms must be conveyed using pre-numbered, tamper-evident, authenticable mailers. The HMD must be inspected for signs of tampering upon receipt. Any other usage where keys or multiple cleartext components or shares sufficient to form a key are stored or transported within a single device, requires that the …
• If the HMD is conveyed between locations, the mechanisms⎯e.g., PINs⎯to become operational must not be conveyed using the same communication channel as the HMD. Both the HMD and the operational mechanisms must be conveyed using pre-numbered, tamper-evident, authenticable mailers. The HMD must be inspected for signs of tampering upon receipt.
Modified
p. 11 → 17
Q 21 December (update) 2016: When encrypted symmetric keys are managed in structures called key blocks, does this apply to both when the keys are transported and when stored? A Yes, it applies to the secure exchange of keys between two devices that share a symmetric key exchange key and for the storage of keys under a symmetric key. It is applicable to anytime an encrypted key exists outside of a SCD. This applies for both fixed and master/session key …
Q 1 December (update) 2016: When encrypted symmetric keys are managed in structures called key blocks, does this apply to both when the keys are transported and when stored? A Yes. It applies to the secure exchange of keys between two devices that share a symmetric key exchange key and for the storage of keys under a symmetric key. It is applicable to anytime an encrypted key exists outside of a SCD. This applies for both fixed and master/session key …
Modified
p. 11 → 17
Q 23 November 2018: PIN Security Requirement 18 states that encrypted symmetric keys must be managed in structures called key blocks. This applies to both conveyance and storage. Does this only apply to only TDEA keys? A No. As stipulated in ANSI X9.24-1: Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques, both AES and TDEA keys are required to be managed in key blocks.
Q 3 November 2018: PIN Security Requirement 18 states that encrypted symmetric keys must be managed in structures called key blocks. This applies to both conveyance and storage. Does this only apply to only TDEA keys? A No. As stipulated in ANSI X9.24-1: Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques, both AES and TDEA keys are required to be managed in key blocks.
Modified
p. 11 → 19
Interoperable methods include those defined in ANSI TR-31 and ISO 20038. The requirement also allows for any equivalent method whereby the equivalent method includes the cryptographic binding of the key-usage information to the key value using accepted methods. How are equivalent methods determined? A Equivalent methods must be subject to an independent expert review and said review is publicly available:
Q 9 October (update) 2022: PIN Security Requirement 18-3 requires the implementation of key blocks. Interoperable methods include those defined in ANSI X9.143 and ISO 20038. The requirement also allows for any equivalent method whereby the equivalent method includes the cryptographic binding of the key-usage information to the key value using accepted methods. How are equivalent methods determined? A Equivalent methods must be subject to an independent expert review and said review is publicly available:
Removed
p. 12
• Is recognized by his/her peers in the field (e.g., awarded the Fellow or Distinguished Fellow or similar professional recognition by an appropriate body, e.g., ACM, BCS, IEEE, IET, IACR) and
Modified
p. 12 → 19
• The independent expert must be qualified via a combination of education, training and experience in cryptology to provide objective technical evaluations that are independent of any ties to vendors and special interests. Independent expert is further defined below.
• The independent expert must be qualified via a combination of education, training, and experience in cryptology to provide objective technical evaluations that are independent of any ties to vendors and special interests. Independent expert is further defined below.
Modified
p. 12 → 19
• Holds one or more professional credentials applicable to the field, e.g., doctoral-level qualifications in a relevant discipline or government certification in cryptography by an authoritative body (e.g., NSA, CES, or GCHQ) and
• Holds one or more professional credentials applicable to the field⎯e.g., doctoral-level qualifications in a relevant discipline or government certification in cryptography by an authoritative body (e.g., NSA, CES, or GCHQ);
Modified
p. 12 → 19
• Has ten or more years of experience in the relevant subject and
• Has ten or more years of experience in the relevant subject;
Modified
p. 12 → 19
• Has published at least two articles in peer-reviewed publications on the relevant subject or
• Has published at least two articles in peer-reviewed publications on the relevant subject or is recognized by his/her peers in the field⎯e.g., awarded the Fellow or Distinguished Fellow or similar professional recognition by an appropriate body, e.g., ACM, BCS, IEEE, IET, IACR.
Modified
p. 12 → 19
• Subscribes to an ethical code of conduct and would be subject to an ethics compliance process if warranted.
• Subscribes to an ethical code of conduct and would be subject to an ethics compliance process if warranted;
Modified
p. 12 → 22
Q 25 December 2016: POI devices must implement unique per device secret and private keys for any function directly or indirectly related to PIN protection. This means not only the PIN-encryption key(s), but also keys that are used to protect other keys, firmware- authentication keys, payment-application authentication and display-prompt control keys. Does this apply to initial/start-up keys that are only used to download an initial DUKPT key or a unique terminal master key. A Yes. The intent of the requirement …
Q 1 December 2016: POI devices must implement unique per device secret and private keys for any function directly or indirectly related to PIN protection. This means not only the PIN-encryption key(s), but also keys that are used to protect other keys, firmware- authentication keys, payment-application authentication, and display-prompt control keys. Does this apply to initial/start-up keys that are only used to download an initial DUKPT key or a unique terminal master key? A Yes. The intent of the requirement …
Modified
p. 13 → 22
Q 26 November 2018: Entities processing or injecting DUKPT or other key-derivation methodologies must incorporate a segmentation strategy in their environments based upon one or more of the following techniques:
• Different BDKs for each financial institution
• Different BDKs for each financial institution
Q 2 November 2018: Entities processing or injecting DUKPT or other key-derivation methodologies must incorporate a segmentation strategy in their environments based upon one or more of the following techniques:
• Different BDKs for each financial institution
• Different BDKs for each financial institution
Modified
p. 13 → 22
• Different BDKs by injection vendor (e.g., ESO), terminal manufacturer, or terminal model
• Different BDKs by injection vendor⎯e.g., ESO⎯, terminal manufacturer, or terminal model
Modified
p. 13 → 22
• Different BDKs by geographic region, market segment, processing platform, or sales unit How is this applied to a merchant host or a processor with a single sponsoring financial institution? A An entity may use the same BDK for its entire population of POI devices if there is only a single:
• Different BDKs by geographic region, market segment, processing platform, or sales unit
Modified
p. 13 → 22
• Within the same geographic region (e.g., within the US).
• Within the same geographic region⎯e.g., within the US.
Modified
p. 13 → 23
Q 27 June 2015: Can key components of different keys belonging to the same key custodian be stored in the same sealed opaque, pre-numbered tamper-evident, authenticable packaging or must each component be in its own package? A Each key component must be in its own package. While they may be conveyed in a single TEA package, they must be uniquely identifiable packaging, e.g. individually within PIN Mailers.
Q 1 January (update) 2020: Can key components of different keys belonging to the same key custodian be stored in the same sealed opaque, pre-numbered tamper-evident, authenticable packaging or must each component be in its own package? A Each key component must be stored in its own TEA package. While they may be conveyed in a single TEA package, they must be uniquely identifiable packaging⎯e.g., individually within PIN Mailers.
Modified
p. 13 → 23
Q 28 March 2015: Requirement 23 stipulates that 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. A transaction processing organization uses the same MFK on both their transaction processing system and a stand-alone system used for key generation. The MFK is used as a KEK to transport keys from the key generation system to the transaction processing …
•and variants of the MFK
•must not be used external to the (logical) configuration that houses the MFK itself. A transaction processing organization uses the same MFK on both their transaction processing system and a stand-alone system used for key generation. The MFK is used as a KEK to transport keys from the key generation system to the transaction processing …
Q 1 March 2015: Requirement 23 stipulates that 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. A transaction processing organization uses the same MFK on both their transaction processing system and a stand-alone system used for key generation. The MFK is used as a KEK to transport keys from the key generation system to the transaction processing …
•and variants of the MFK
•must not be used external to the (logical) configuration that houses the MFK itself. A transaction processing organization uses the same MFK on both their transaction processing system and a stand-alone system used for key generation. The MFK is used as a KEK to transport keys from the key generation system to the transaction processing …
Modified
p. 14 → 23
Q 29 June 2015: An entity is using the same MFK for both issuing and acquiring
• does that violate any of the requirements? A The following scenarios apply:
• does that violate any of the requirements? A The following scenarios apply:
Q 2 June 2015: An entity is using the same MFK for both issuing and acquiring
• does that violate any of the requirements? A The following scenarios apply:
• does that violate any of the requirements? A The following scenarios apply:
Modified
p. 14 → 23
PIN Security Requirement 29
PIN Security Requirement 26
Modified
p. 14 → 24
Q 30 November 2015: PIN requirement 29 states that HSMs used for acquiring functions shall not be configured to output clear-text PINs. How is this to be achieved? A All commands and configuration options associated with the outputting of clear PINs must be disabled or removed from HSMs used for acquiring. HSMs temporarily used for PIN issuance may be reconfigured but must use a separate key hierarchy e.g., a different master file key.
Q 1 November 2015: PIN requirement 29 states that HSMs used for acquiring functions shall not be configured to output clear-text PINs. How is this to be achieved? A All commands and configuration options associated with the outputting of clear PINs must be disabled or removed from HSMs used for acquiring. HSMs temporarily used for PIN issuance may be reconfigured but must use a separate key hierarchy⎯e.g., a different master file key.
Modified
p. 14 → 24
Q 31 November 2015: Requirement 29-2 stipulates the implementation of a documented chain of custody to ensure that all devices are controlled from receipt through to placement into service. It further states that the chain of custody must include records to identify responsible personnel for each interaction with the devices. What would constitute an effective and compliant chain of custody? A An effective and compliant chain of custody includes procedures, as stated in requirement 29-1, that ensures that access to …
Q 2 November 2015: Requirement 29-2 stipulates the implementation of a documented chain of custody to ensure that all devices are controlled from receipt through to placement into service. It further states that the chain of custody must include records to identify responsible personnel for each interaction with the devices. What would constitute an effective and compliant chain of custody? A An effective and compliant chain of custody includes procedures, as stated in requirement 29-1, that ensures that access to …
Modified
p. 14 → 24
Q 32 November 2015: When do POI devices require direct oversight to prevent unauthorized access up to the point of deployment? A If a POI device is held in a secure location where access is restricted to individuals authorized for device access, e.g., a secure room or cabinet, it does not require direct oversight. If the POI device is in an unsecure area, without access restricted to individuals authorized for device access, it requires direct oversight, i.e., the devices must …
Q 3 November 2015: When do POI devices require direct oversight to prevent unauthorized access up to the point of deployment? A If a POI device is held in a secure location where access is restricted to individuals authorized for device access⎯e.g., a secure room or cabinet⎯it does not require direct oversight. If the POI device is in an unsecure area, without access restricted to individuals authorized for device access, it requires direct oversight⎯i.e., the devices must be under direct …
Modified
p. 15 → 24
Q 33 September 2016: Requirement 31 states that SCDs removed from service, even if only temporarily for repair, must render all keying material irrecoverable. Are there any exceptions to this? A Yes, PIN pads and integrated circuit card readers used in unattended devices that have anti- removal mechanisms to protect against unauthorized removal and/or unauthorized re-installation may not require zeroization of keys if the nature of the repair is such that it can be performed while all tamper response mechanisms …
Q 4 January (update) 2020: Requirement 31 states that SCDs removed from service temporarily for repair, must render all keying material irrecoverable. Are there any exceptions to this? Yes. PIN pads and integrated circuit card readers used in unattended devices that have anti- removal mechanisms to protect against unauthorized removal and/or unauthorized re-installation may not require zeroization of keys if the nature of the repair such that it can be performed while all tamper response mechanisms other than the device …
Modified
p. 15 → 27
Q 34 November 2015: Does the loading of secret or private keys to POI devices encrypted using asymmetric keys require compliance with Annex A? A Whenever 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, then Annex A does not apply. Remotely means whenever the key loading device and the POI device are not co-located and connected via …
•even
Q 1 January (update) 2020: Does the loading of secret or private keys to POI devices encrypted using asymmetric keys require compliance with Annex A? A Whenever the key loading is not performed remotely⎯e.g., in a key-injection facility that meets the requirements in Annex B⎯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. The secure environment and operational controls are depended …
Modified
p. 16 → 27
Q 35 November 2018: Two sets of RSA keys pairs, generated respectively by the POI device and the Key Distribution Host (KDH), are used for transport of an initial key to the POI device. Hashes of each public key are sent by a separate channel for loading to the other device (POI hash to KDH and vice versa) such that self-signed certificates are not used as the sole method of authentication. A certification authority is not used. Does this require …
Q 2 November 2018: Two sets of RSA keys pairs, generated respectively by the POI device and the Key Distribution Host (KDH), are used for transport of an initial key to the POI device. Hashes of each public key are sent by a separate channel for loading to the other device (POI hash to KDH and vice versa) such that self-signed certificates are not used as the sole method of authentication. A certification authority is not used. Does this require …
Modified
p. 16 → 28
Q 36 November 2018: Key-establishment and distribution procedures must be designed such that within an implementation design, there shall be no means available for “man-in-the- middle” attacks. What are acceptable methods for remote key distribution using asymmetric techniques methodologies to protect against man-in-the-middle attacks and the hijacking of PIN-acceptance devices? A There are several techniques available, four of which are:
Q 1 November 2018: Key-establishment and distribution procedures must be designed such that within an implementation design, there shall be no means available for “man-in-the- middle” attacks. What are acceptable methods for remote key distribution using asymmetric techniques methodologies to protect against man-in-the-middle attacks and the hijacking of PIN-acceptance devices? A There are several techniques available, four of which are:
Modified
p. 16 → 28
• For devices under a PKI hierarchy that facilitates more than one acquirer (e.g., a hierarchy under a PIN-acceptance device vendor’s root), an acceptable technique is to force the PIN- acceptance device to bind to a specific transaction-processing host’s certificate(s), and not accept commands digitally signed by any other hosts. This is frequently done at initialization of a new PIN-acceptance device, and subject to unbinding techniques as noted in another FAQ. Note: A third party may operate the KDH(s) on …
• For devices under a PKI hierarchy that facilitates more than one acquirer⎯e.g., a hierarchy under a PIN-acceptance device vendor’s root⎯an acceptable technique is to force the PIN- acceptance device to bind to a specific transaction-processing host’s certificate(s), and not accept commands digitally signed by any other hosts. This is frequently done at initialization of a new PIN-acceptance device, and subject to unbinding techniques as noted in another FAQ. Note: A third party may operate the KDH(s) on behalf of …
Modified
p. 16 → 28
• Certificate Revocation Lists can be distributed to the device to identify compromised key distribution hosts. This requires that device vendors maintain and distribute the CRLs for KDH keys that are part of their remote key distribution PKI. It further requires that the CRLs
• Certificate Revocation Lists can be distributed to the device to identify compromised key distribution hosts. This requires that device vendors maintain and distribute the CRLs for KDH keys that are part of their remote key distribution PKI. It further requires that the CRLs have a lifetime not to exceed one week to minimize the exposure window. Furthermore, it requires that the device cease processing if it does not possess a valid unexpired CRL.
Modified
p. 17 → 29
Q 37 November 2018: ANSI TR-34 describes two protocols for implementing the distribution of symmetric keys using asymmetric techniques. The two techniques are described as the Two Pass method and the One Pass method and should be used as follows:
• The Two Pass method is appropriate for where the POI and KDH can communicate in real time. It uses random nonces for the prevention of replay attacks.
• The Two Pass method is appropriate for where the POI and KDH can communicate in real time. It uses random nonces for the prevention of replay attacks.
Q 2 November 2018: ANSI TR-34 describes two protocols for implementing the distribution of symmetric keys using asymmetric techniques. The two techniques are described as the Two Pass method and the One Pass method and should be used as follows:
• The Two Pass method is appropriate for where the POI and KDH can communicate in real time. It uses random nonces for the prevention of replay attacks.
• The Two Pass method is appropriate for where the POI and KDH can communicate in real time. It uses random nonces for the prevention of replay attacks.
Modified
p. 17 → 29
• The One Pass method is appropriate for environments where the POI and KDH will not be able to communicate in real-time i.e. the POI cannot initiate the sequence of cryptographic protocol messages. In these environments, the KDH will generate the cryptographic message that can be transported to the POI over untrusted channels in non-real time. It includes the use of time-stamps in lieu of random nonces to prevent replay attacks.
• The One Pass method is appropriate for environments where the POI and KDH will not be able to communicate in real-time⎯i.e., the POI cannot initiate the sequence of cryptographic protocol messages. In these environments, the KDH will generate the cryptographic message that can be transported to the POI over untrusted channels in non-real time. It includes the use of time stamps in lieu of random nonces to prevent replay attacks.
Modified
p. 17 → 29
Q 38 May 2019: Requirement 18-5 in Annex A states: Key Distribution Hosts (KDHs) shall only communicate with POIs for the purpose of key management and normal transaction processing, and with CAs for the purpose of certificate signing and certificate (entity) status checking. Does this requirement preclude a terminal management system (TMS) from existing on the same platform as a KDH? A KDH is a functionality and it is not intended to infer a dedicated physical platform. A TMS functionality …
Q 3 May 2019: Requirement 18-5 in Annex A states: Key Distribution Hosts (KDHs) shall only communicate with POIs for the purpose of key management and normal transaction processing, and with CAs for the purpose of certificate signing and certificate (entity) status checking. Does this requirement preclude a terminal management system (TMS) from existing on the same platform as a KDH? A KDH is a functionality, and it is not intended to infer a dedicated physical platform. A TMS functionality …
Modified
p. 17 → 30
Q 39 June 2015: CAs may use several methods to validate the identity of certificate requestors and recipients before issuance of digital certificates. One of those methods is to use confirmation by telephone, confirmatory postal mail, and/or a comparable procedure. Does email constitute a comparable procedure? A Yes, email may be used in lieu of confirmation by telephone or confirmatory postal mail wherever those are specified as options.
Q 1 June 2015: CAs may use several methods to validate the identity of certificate requestors and recipients before issuance of digital certificates. One of those methods is to use confirmation by telephone, confirmatory postal mail, and/or a comparable procedure. Does e-mail constitute a comparable procedure? A Yes. E-mail may be used in lieu of confirmation by telephone or confirmatory postal mail wherever those are specified as options.
Modified
p. 18 → 30
Q 40 November 2015: Requirement 32 of Annex A states that a physically secure, dedicated room must be used to house the CA and RA database and application servers and cryptographic devices and that this room not be used for any other business activities but certificate operations. This applies whenever a Public Key Infrastructure (PKI) is implemented to support remote key distribution using asymmetric techniques for use in connection with PIN encryption to transaction originating devices (POIs). Can this room …
Q 1 November 2015: Requirement 32 of Annex A states that a physically secure, dedicated room must be used to house the CA and RA database and application servers and cryptographic devices and that this room not be used for any other business activities but certificate operations. This applies whenever a Public Key Infrastructure (PKI) is implemented to support remote key distribution using asymmetric techniques for use in connection with PIN encryption to transaction originating devices (POIs). Can this room …
Modified
p. 18 → 31
If the CA room has a wall adjoining another company in a shared facility, the common wall must be reinforced and constructed of metal studded fire rated sheet rock (drywall) with expanded metal (security) mesh. The mesh must be constructed of steel or a stronger material and meet the ASTM F1267-12 or EMMA 557-12 standard. The construction must include vibration detectors to detect any attempts to cut through. The expanded metal (security) mesh shall meet the following minimum requirements:
Modified
p. 19 → 31
Q 42 July 2017: If a caged environment is used to meet requirement 32 for a CA room, what is the minimum criteria for the fencing materials used? A The fencing shall consist of the following minimums:
Q 3 January (update) 2020: If a caged environment is used to meet requirement 32 for an online CA room, what is the minimum criteria for the fencing materials used? A The fencing shall consist of the following minimums:
Modified
p. 19 → 31
• Chain link, welded or expanded steel metal fencing.
• Chain link, welded, or expanded steel metal fencing.
Modified
p. 19 → 31
• e.g., boxes, whiteboards, or other covering materials must not be present. This does not alleviate the need to use blinds or similar materials during key injection activities to prevent observation from outside the secure area, however, this must be on the interior side of the fencing.
• The exterior side of the fencing must be kept clear to prevent the hiding of tamper evidence⎯e.g., boxes, whiteboards, or other covering materials must not be present. This does not alleviate the need to use blinds or similar materials during key injection activities to prevent observation from outside the secure area, however, this must be on the interior side of the fencing.
Modified
p. 19 → 32
Q 43 June 2015: Does Annex B - Key Injection Facilities apply to both acquirer and manufacturer keys? A The intent of Annex B is to apply to acquirer keys e.g., PIN keys, TMKs, etc. Manufacturer keys are separately addressed as part of the PTS POI Security Requirements and the PTS HSM Security Requirements.
Q 1 June 2015: Does Annex B - Key Injection Facilities apply to both acquirer and manufacturer keys? A The intent of Annex B is to apply to acquirer keys⎯e.g., PIN keys, TMKs, etc. Manufacturer keys are separately addressed as part of the PTS POI Security Requirements and the PTS HSM Security Requirements.
Modified
p. 19 → 32
Q 44 December 2015: If a KIF uses a Base Derivation Key to derive initial DUKPT keys used for DUKPT in POI devices, is that considered key generation? A Yes. As defined in ISO 11568, symmetric keys and their components are generated by one of the following:
Q 2 December 2015: If a KIF uses a Base Derivation Key to derive initial DUKPT keys used for DUKPT in POI devices, is that considered key generation? A Yes. As defined in ISO 11568, symmetric keys and their components are generated by one of the following:
Modified
p. 20 → 33
Q 45 July (update) 2017: Are there scenarios where a single key injection operator can perform key loading? A For injection in a secure KIF room, a single key injection operator may perform key injections under the following circumstances:
Q 3 July (update) 2017: Are there scenarios where a single key injection operator can perform key loading? A For injection in a secure KIF room, a single key injection operator may perform key injections under the following circumstances:
Modified
p. 20 → 33
• Two authorized key injection operators log in and initialize the key loading device (KLD) so that it is ready to inject keys, i.e., load the Base Derivation Key.
• Two authorized key injection operators log in and initialize the key loading device (KLD) so that it is ready to inject keys⎯i.e., load the Base Derivation Key.
Modified
p. 20 → 34
Q 46 December 2015: Can an ESO perform key injections using either non-compliant keys and/or non-complaint SCDs and still be considered compliant? A ESOs that inject non-compliant keys into SCDs, or inject keys into non-compliant SCDs can still be considered compliant if the devices in this instance are not intended to acquire transactions of PCI payment brands or affiliates who require compliance to the PCI PIN Security Requirements. Such operations should be considered out of scope of the PCI PIN …
Q 1 December 2015: Can an ESO perform key injections using either non-compliant keys and/or non-complaint SCDs and still be considered compliant? A ESOs that inject non-compliant keys into SCDs or inject keys into non-compliant SCDs can still be considered compliant if the devices in this instance are not intended to acquire transactions of PCI payment brands or affiliates who require compliance to the PCI PIN Security Requirements. Such operations should be considered out of scope of the PCI PIN …
Removed
p. 21
Q 49 December 2016: Symmetric keys must be managed in structures called key blocks when stored or transported. Does this apply to symmetric keys that are injected directly from a key loading device (KLD) to a POI or HSM device? A No, the requirement only applies to encrypted symmetric keys that are stored at a transaction host or in a POI device, or are transported over a network connection. It is not intended to apply to keys, encrypted or cleartext, when injected by being directly cabled to a KLD.
Modified
p. 21 → 34
Q 47 November 2015: Requirement 1-5 details the need for documentation detailing the distributed KIF architecture and key-management flows. Does this only apply to KIF platforms that have a distributed KIF architecture or does it apply to all KIF platforms regardless of architecture. A All KIF platforms are required to meet the requirements detailed in 1-5. Specifically, the KIF Platform provider must:
Q 2 November 2015: Requirement 1-5 details the need for documentation detailing the distributed KIF architecture and key-management flows. Does this only apply to KIF platforms that have a distributed KIF architecture or does it apply to all KIF platforms regardless of architecture? A All KIF platforms are required to meet the requirements detailed in 1-5. Specifically, the KIF Platform provider must:
Modified
p. 21 → 34
Q 48 July (update) 2017: PIN Entry Devices (PEDs), PCI approved or otherwise, may have their firmware modified to support usage for key injection. Are these devices considered Secure Cryptographic Devices (SCDs) for PCI purposes? A Modified PEDs, even if previously PCI approved, are not considered SCDs unless validated and approved to the KLD approval class. As such, they are only approved for key injection when performed in conformance with requirement 13 of Annex B. In addition, they are not …
Q 1 July (update) 2017: PIN Entry Devices (PEDs), PCI approved or otherwise, may have their firmware modified to support usage for key injection. Are these devices considered Secure Cryptographic Devices (SCDs) for PCI purposes? A Modified PEDs, even if previously PCI approved, are not considered SCDs unless validated and approved to the KLD approval class. As such, they are only approved for key injection when performed in conformance with requirement 13 of Annex B. In addition, they are not …
Modified
p. 22 → 36
Q 50 December 2015: The introductory text to Requirement 29 in Annex B states that secure areas must be established for the inventory of PEDs that have not had keys injected. However, these requirements are not detailed in the ‘numbered’ requirements or have associated testing procedures. How should these be assessed during an assessment? A As noted in the text, this area must have extended walls from the real floor to the real ceiling using sheetrock, wire mesh, or equivalent. …
Q 1 January (update) 2020: The introductory text to Requirement 29 in Annex B states that secure room must be established for the inventory of PEDs that have not had keys injected. However, these requirements are not detailed in the “numbered” requirements or have associated testing procedures. How should these be assessed during an assessment? A As noted in the text, this room must have extended walls from the real floor to the real ceiling using sheetrock, wire mesh, or …
Modified
p. 22 → 36
Q 51 November 2018: Only encrypted key loading is allowed for POI v3 or higher devices after 2020 for entities engaged in key injection on behalf of others. Does this apply to manufacturer’s keys? A The PIN requirements are applicable to the keys used in the acquisition and protection of PIN data, and the keys associated with protection of those keys. This includes the following:
Q 1 November (update) 2020: Only encrypted key loading is allowed for POI v5 or higher devices after 2023 for entities engaged in key injection on behalf of others. Does this apply to manufacturer’s keys? A The PIN requirements are applicable to the keys used in the acquisition and protection of PIN data, and the keys associated with protection of those keys. This includes the following:
Modified
p. 22 → 36
• Device-specific private keys for use in connection with remote key loading using asymmetric techniques
• Device-specific private keys for use in connection with remote key loading using asymmetric techniques.
Modified
p. 22 → 36
Q 52 July (update) 2017: When does the injection of clear text secret or private keys or their components to POI devices require the use of a secure room in accordance with requirement 32-10 of Annex B? A A secure room must be used any time clear keys/components appear in unprotected memory outside the tamper protected boundary of an SCD during the process of loading/injecting keys into a SCD.
Q 2 July (update) 2017: When does the injection of clear-text secret or private keys or their components to POI devices require the use of a secure room in accordance with requirement 32-9 of Annex B? A A secure room must be used any time clear keys/components appear in unprotected memory outside the tamper protected boundary of an SCD during the process of loading/injecting keys into a SCD.
Modified
p. 23 → 37
Q 53 July (update) 2016: Requirement 32 stipulates that a secure area (room) is used for key injection where any secret or private keys or their components appear in unprotected memory during the process of loading/injecting keys into an SCD. The secure area must have walls made of solid materials, and additionally if the solid walls do not extend from the real floor to the real ceiling, the secure area must have extended walls from the real floor to the …
Q 3 January (update) 2020: Requirement 32 stipulates that a secure room is used for key injection where any secret or private keys or their components appear in unprotected memory during the process of loading/injecting keys into an SCD. The secure room must have walls made of solid materials, and additionally if the solid walls do not extend from the real floor to the real ceiling, the secure room must have extended walls from the real floor to the real …
Modified
p. 23 → 37
• Restrict Observation
• Restricts Observation
Modified
p. 23 → 37
• Facilitate the effective use of motion activated CCTV systems
• Facilitates the effective use of motion activated CCTV systems
Modified
p. 23 → 37
• Prevent the passing of restricted materials through openings.
• Prevents the passing or capture of restricted materials through openings.
Modified
p. 24 → 38
• Chain link, welded or expanded steel metal fencing.
• Chain link, welded, or expanded steel metal fencing.
Modified
p. 24 → 38
• e.g., boxes, whiteboards, or other covering materials must not be present. This does not alleviate the need to use blinds or similar materials during key injection activities to prevent observation from outside the secure area, however, this must be on the interior side of the fencing.
• The exterior side of the fencing must be kept clear to prevent the hiding of tamper evidence⎯e.g., boxes, whiteboards, or other covering materials must not be present. This does not alleviate the need to use blinds or similar materials during key injection activities to prevent observation from outside the secure area, however, this must be on the interior side of the fencing.
Modified
p. 24 → 38
Q 54 July 2016: If a caged environment is used to meet requirement 32 for a KIF room, what is the minimum criteria for the fencing materials used? A The fencing shall consist of the following minimums:
Q 4 January (update) 2020: If a caged environment is used to meet requirement 32 for a KIF room, what is the minimum criteria for the fencing materials used? A The fencing shall consist of the following minimums:
Modified
p. 24 → 38
• Fencing will attach to the post and rails with a minimum 11-gauge tension band or fence brace and bolted together, or metal fencing will attach with vendor provided mounting bolts. Tie wires shall not be used at any time.
• Fencing will attach to the post and rails with a minimum 11-gauge tension band or fence brace bolted together, or metal fencing will attach with vendor provided mounting bolts. Tie wires shall not be used at any time.
Modified
p. 24 → 38
Q 55 August 2019: Requirement 32-9 only prohibits cleartext key injection for POI v3 and higher devices. Is that meant to continue to permit cleartext key injection for POI v2 and earlier devices, even after the stated effective dates? A Yes, the injection of cleartext keys into POI v2 and earlier devices will continue to be acceptable past the January 2021 date for entities engaged in key injection on behalf of others and the January 2023 date for entities engaged …
Q 5 November (update) 2020: Requirement 32-9 only prohibits clear-text key injection for POI v5 and higher devices. Is that meant to continue to permit clear-text key injection for POI v4 and earlier devices, even after the stated effective dates? A Yes. The injection of clear-text keys into POI v4 and earlier devices will continue to be acceptable past the January 2024 date for entities engaged in key injection on behalf of others and the January 2026 date for entities …