Document Comparison
PCI_PIN_Technical_FAQs_v3_June_2025.pdf
→
PCI_PIN_Technical_FAQs_v3_August_2025.pdf
99% similar
40 → 40
Pages
17003 → 17009
Words
115
Content Changes
Content Changes
115 content changes. 11 administrative changes (dates, page numbers) hidden.
Added
p. 22
• Different BDKs by injection vendor⎯e.g., ESO⎯, terminal manufacturer, or terminal model
• 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:
• Financial Institution (Sponsor), and
• Injection Vendor, and they are
• Use dual-control techniques;
• Prevent replay of authorization data; and
• Cause the device to not process PIN data until authorized to do so.
• 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:
• Financial Institution (Sponsor), and
• Injection Vendor, and they are
• Use dual-control techniques;
• Prevent replay of authorization data; and
• Cause the device to not process PIN data until authorized to do so.
Added
p. 31
• 16-gauge metal studs are used with 12inch (305mm) on center
• 0.75inch #9 steel mesh or 3/4inch #9 or 19mm #9
• Thickness 0.120 inches (3mm) 0.01-inch tolerance (0.5mm)
• 0.75inch #9 steel mesh or 3/4inch #9 or 19mm #9
• Thickness 0.120 inches (3mm) 0.01-inch tolerance (0.5mm)
Added
p. 37
• Restricts Observation
• Facilitates the effective use of motion activated CCTV systems
• Facilitates the effective use of motion activated CCTV systems
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 mechanismse.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? Yes, but only for local key injectioni.e., directly cableand 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.
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.
Modified
p. 4
Q 5 January 2020: Can an acquirer use third-party hosted HSM servicei.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 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.
Modified
p. 4
• 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.
Modified
p. 4
• 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.
Modified
p. 4
• Access to the cabinets housing the cloud provider’s HSMs and/or peripheral equipment⎯e.g., firewalls⎯must either be:
Modified
p. 5
Q 11 May 2024: Can a service provider providing multi-tenant HSM services share the same master/storage ("Local Master Key" or "Master File Key") keys between HSMs? A No. Where multi-tenant HSM services are provided, master/storage keys that are not directly managed or owned by the HSM tenant must be unique per HSM instance, except in cases where a tenant instance pair/cluster has a designated purpose of load balancing or hot-spare backup.
Q 11 May 2024: Can a service provider providing multi-tenant HSM services share the same master/storage ("Local Master Key" or "Master File Key") keys between HSMs? A No. Where multi-tenant HSM services are provided, master/storage keys that are not directly managed or owned by the HSM tenant must be unique per HSM instance, except in cases where a tenant instance pair/cluster has a designated purpose of load balancing or hot- spare backup.
Modified
p. 8
• The HSM’s FIPS 140-2 certificate must include at least the hardware where all cryptographic processes are executed and secret data is stored.
Modified
p. 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.
Modified
p. 8
• Effective 1 July 2020 for new deployments⎯i.e., additional HSMs and not replacements of existing HSMs with like for like⎯the HSM’s FIPS 140-2 certification scope (the Target of Evaluation) must include the tamper responsive boundaries within which PIN translation occurs.
Modified
p. 9
Q 4 December 2016: Entities acquiringe.g., the processorPIN-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 …
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. 9
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 …
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. 9
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
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. 10
Q 2 September 2021: What is master key/session key management? A Master key/session key management is a method for managing transaction keys using a key- encipherment key, called a master key, that is used to encrypt for distribution new or replacement key-encipherment keys, derivation keys and/or Session (e.g., PIN encryption keys) keys. This method is also known as the master key/transaction key method.
Q 2 September 2021: What is master key/session key management? A Master key/session key management is a method for managing transaction keys using a key-encipherment key, called a master key, that is used to encrypt for distribution new or replacement key-encipherment keys, derivation keys and/or Session (e.g., PIN encryption keys) keys. This method is also known as the master key/transaction key method.
Modified
p. 11
Q 1 May 2019: Printers used for printing key components must not be used for other purposes and must not be networkedi.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 …
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. 11
• Deny all services not explicitly permitted.
Modified
p. 11
• Disable or remove all unnecessary services, protocols, and ports.
Modified
p. 11
• Fail to a configuration that denies all services and require a firewall administrator to re- enable services after a failure.
Modified
p. 11
• Disable source routing on the firewall.
Modified
p. 11
• Not accept traffic on its external interfaces that appears to be coming from internal network addresses.
Modified
p. 11
• 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. 11
• Run on a dedicated computer: All non-firewall related software, such as compilers, editors, communications software, etc., must be deleted or disabled.
Modified
p. 11
• All activities on the firewall are logged, monitored, and reviewed.
Modified
p. 12
Q 2 September 2022: When can a manual (handwritten) capture of generated key components be performed outside of a secure room? A It may be acceptable to generate and manually write down key shares/components outside of a secure room for the purpose of establishing shared keys with other organizations, when there exists no other compatible way of communicatione.g., smart cards under the following conditions (see requirement 13-2 for loading of clear-text keying material):
Q 2 September 2022: When can a manual (handwritten) capture of generated key components be performed outside of a secure room? A It may be acceptable to generate and manually write down key shares/components outside of a secure room for the purpose of establishing shared keys with other organizations, when there exists no other compatible way of communication⎯e.g., smart cards⎯ under the following conditions (see requirement 13-2 for loading of clear-text keying material):
Modified
p. 12
• Only approved Secure Cryptographic Devices (SCDs) are used⎯i.e., key shares/components are displayed on the integrated display of a PCI or FIPS approved SCD (e.g., an HSM or KLD). Key shares must never appear in memory outside the tamper- protected boundaries of an SCD or a Hardware Management Device (HMD).
Modified
p. 12
• The process is performed in a controlled or higher environment as defined in ISO 13491-2.
Modified
p. 12
• The principles of dual control and split knowledge must be followed.
Modified
p. 12
• 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).
Modified
p. 13
Q 3 November 2018: PIN Security Requirement 10 states that RSA keys encrypting keys greater in strength than 80 bitse.g., triple-length TDEA, AESshall 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 …
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. 15
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 deploymentsi.e., additional HSMs and not replacements of existing HSMs with like for likeafter 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 …
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. 15
• Use an SCD that is listed as a PCI HSM Remote Administration Platform (RAP) approval class or • Is designated as a valid mechanism⎯i.e., function provided⎯on the Approved PTS Devices website in conjunction with the specific HSM approval(s) for which they are intended to be used. Note that mechanisms not validated to the RAP approval class require the use of a separate hardware-based appliance approved under the PCI PTS requirements as a Key Loading Device for the loading of …
Modified
p. 16
Q 1 December 2017: Asymmetric key pairs or symmetric keys are commonly used for authentication of applications and for display prompts or to facilitate managemente.g., enable functionalityof 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 …
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. 16
• The HMD must be maintained in a secure storage location, such as a safe or compartment therein, and accessible only under dual control to the authorized custodians.
Modified
p. 16
• When removed from the secure storage location, the HMD must be in the physical possession of only the designated custodians and only for the minimum practical time necessary to complete the signing process.
Modified
p. 16
• The HMD must be physically safeguarded at all times when removed from secure storage.
Modified
p. 16
• 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. 16
• If the HMD is required to generate keys⎯e.g., its own key pair⎯it must be capable of meeting requirement 5.
Modified
p. 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.
Modified
p. 17
Q 4 June (update) 2021: Organizations must implement key blocks for external connections to Associations and Networks by 1 January 2023. If a service provider cannot implement key blocks for all connections to other organizations because one or more of the external organizations do not support key blocks, what are the service provider’s options for meeting the requirement? A The service provider must implement key blocks for all external organizations that support key blocks by the deadline. The assessor must …
Q 4 June (update) 2021: Organizations must implement key blocks for external connections to Associations and Networks by 1 January 2023. If a service provider cannot implement key blocks for all connections to other organizations because one or more of the external organizations do not support key blocks, what are the service provider’s options for meeting the requirement? A The service provider must implement key blocks for all external organizations that support key blocks by the deadline. The assessor must …
Modified
p. 18
Q 6 April 2021: Key blocks for the transport and storage of symmetric keysi.e., AES and TDES keysare required to be implemented in accordance with a three phased approach. Allowed formats for these key blocks are defined by the standards bodies, ANSI and ISO. In addition, proprietaryi.e., non-ANSI or ISO recognizedmethods have been allowed if “equivalent.” In September 2020, specific criteria that proprietary methods must meet in order to be verified as equivalent was published in the PCI PTS HSM …
Q 6 April 2021: Key blocks for the transport and storage of symmetric keys⎯i.e., AES and TDES keys⎯are required to be implemented in accordance with a three phased approach. Allowed formats for these key blocks are defined by the standards bodies, ANSI and ISO. In addition, proprietary⎯i.e., non-ANSI or ISO recognized⎯methods have been allowed if “equivalent.” In September 2020, specific criteria that proprietary methods must meet in order to be verified as equivalent was published in the PCI PTS HSM …
Modified
p. 19
• The review by the independent expert must include proof that in the equivalent method the encrypted key and its attributes in the Key Block have integrity protection such that it is computationally infeasible for the key to be used if the key or its attributes have been modified. Modification includes, but is not limited to:
Modified
p. 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.
Modified
p. 19
• The PTS laboratory will validate that any device vendors implementing this methodology have done so following all guidelines of said evaluation and peer review, including any recommendations for associated key management.
Modified
p. 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); • Has ten or more years of experience in the relevant subject; • Subscribes to an ethical code of conduct and would be subject to an ethics compliance process if warranted; • Has published at least two articles in peer-reviewed publications on the relevant subject or is recognized by …
Modified
p. 20
Q 11 February (update) 2025: What key block methods are compliant? A For storage and distribution of symmetric keys using symmetric techniques the following are compliant:
Q 11 August (update) 2025: What key block methods are compliant? A For storage and distribution of symmetric keys or private keys using symmetric techniques the following are compliant:
Modified
p. 20
• ECDH to allow derivation of a shared secret key or keys. The ECDH based protocol must include mutual authentication of both parties. The key derivation process or protocol used must include a means to constrain the usage of each derived shared secret(s) and/or ephemeral key(s) to a single intended purpose while employed in the exchange. Any subject keys sent encrypted via a derived key must be bound to their attributes, as defined below, via signature or using an acceptable …
• ECDH to allow derivation of a shared secret key or keys. The ECDH based protocol must include mutual authentication of both parties. The key derivation process or protocol used must include a means to constrain the usage of each derived shared secret(s) and/or ephemeral key(s) to a single intended purpose while employed in the exchange. Any subject keys sent encrypted via a derived key must be bound to their attributes, as defined below, via signature or using an acceptable …
Modified
p. 20
• One or more attributes as set by the intended purpose definition that define the operations for which the key can be used.
• One or more attributes as set by the intended purpose definition that defines the operations for which the key can be used.
Modified
p. 20
• One or more attributes that define whether the protected key may be transferred outside the cryptographic domain in which the key is found i.e., exportability. +
• One or more attributes that define whether the protected key may be transferred outside the cryptographic domain in which the key is found i.e., exportability.
Modified
p. 20
Additionally, as the industry continues to migrate the POI and HSM infrastructure, key length obfuscation padding of symmetric keys to the maximum length for the algorithm, 192 bits for TDEA and 256 bits for AES will be required for new deployments once appropriate future updates to the PCI Security Requirements for POI and HSM devices are published and take effect.
Removed
p. 22
Different BDKs for each financial institution Different BDKs by injection vendore.g., ESO, terminal manufacturer, or terminal model 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:
Modified
p. 22
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 …
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. 22
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:
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
Modified
p. 22
• Within the same geographic region⎯e.g., within the US.
Modified
p. 23
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 packaginge.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. 23
• The issuing and acquiring platform(s) are part of the same logical configuration and the HSMs are either physically or logically (same partition) the same. This is allowed as long as the HSM(s) used do not support functions prohibited in requirement 29.
Modified
p. 23
• The issuing and acquiring platform(s) are part of the same logical configuration and the HSMs are either physically or logically separate. This is allowed as long as the HSM(s) used for acquiring do not support functions prohibited in requirement 29.
Modified
p. 23
• The issuing and acquiring platform(s) are not part of the same logical configuration. In this scenario the MFKs must be different for issuing vs. acquiring.
Modified
p. 24
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 hierarchye.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. 24
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 accesse.g., a secure room or cabinetit 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 oversighti.e., the devices must be under direct …
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. 24
• Provide accountability and traceability including logging of user IDs, date and time stamp, and actions performed;
Modified
p. 26
• Non-console HSM access for the purposes of management and configuration must require the use of multifactor authentication.
Modified
p. 26
• Non-console HSM access for the purposes of management and configuration must be performed using a secure channel⎯e.g., TLS connection. This bullet is a best practice until 1 April 2025, after which it will be required and must be fully considered during a PCI PIN assessment.
Modified
p. 26
• Clear-text key components and/or key shares input to or output from the HSM must be secured through dual control and split knowledge.
Modified
p. 26
• Non-console access which may be used for the loading of clear-text private and secret key components or key shares must originate from secure cryptographic devices that are validated and approved against one of the following:
Modified
p. 26
• Non-console access used for the loading of clear-text private and secret key components or key shares must use a key-encryption key that is specific for the purposes of key transport. Use of encryption provided by a secure channel is not sufficient to meet this requirement.
Modified
p. 27
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 remotelye.g., in a key-injection facility that meets the requirements in Annex Band 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 …
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. 27
Q 3 November 2020: The introduction to Annex A states that ANSI TR-34: Interoperable Method for Distribution of Symmetric Keys using Asymmetric Techniques: Part 1
• Using Factoring-Based Public Key Cryptography Unilateral Key Transport represents a methodology complaint to Annex A. Under TR-34, both the Key Distribution Host (KDH) and the Key Receiving Device (KRD) have a common relationship with a Certificate Authority. In this context, what does common relationship mean? A Common relationship means the KDH and KRD are part …
• Using Factoring-Based Public Key Cryptography Unilateral Key Transport represents a methodology complaint to Annex A. Under TR-34, both the Key Distribution Host (KDH) and the Key Receiving Device (KRD) have a common relationship with a Certificate Authority. In this context, what does common relationship mean? A Common relationship means the KDH and KRD are part …
Q 3 November 2020: The introduction to Annex A states that ANSI TR-34: Interoperable Method for Distribution of Symmetric Keys using Asymmetric Techniques: Part 1
• Using Factoring-Based Public Key Cryptography Unilateral Key Transport represents a methodology complaint to Annex A. Under TR-34, both the Key Distribution Host (KDH) and the Key Receiving Device (KRD) have a common relationship with a Certificate Authority. In this context, what does common relationship mean? A Common relationship means the KDH and KRD are part …
• Using Factoring-Based Public Key Cryptography Unilateral Key Transport represents a methodology complaint to Annex A. Under TR-34, both the Key Distribution Host (KDH) and the Key Receiving Device (KRD) have a common relationship with a Certificate Authority. In this context, what does common relationship mean? A Common relationship means the KDH and KRD are part …
Modified
p. 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 behalf of …
Modified
p. 28
• The acquirer KDH public key can be loaded only once and requires a factory return (preceded by a zeroization of acquirer keys function) to put the device back to ready state.
Modified
p. 28
• An acquirer specific PKI hierarchy can be implemented. For this scenario, because of the rigor of criteria for operating a Certification Authority as stated in Annex A, it is best to have the PIN-acceptance device vendor operate the hierarchy, or else use a company that provides professional Certification Authority services.
Modified
p. 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 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. 29
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.
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.
Modified
p. 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.
Modified
p. 30
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 …
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. 31
Q 2 January (update) 2020: What are the minimum criteria for construct of Certification Authority room walls for offlinee.g., rootCAs? 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 …
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 …
Modified
p. 31
• Expanded metal mesh is anchored to the stud with vendor supplied mesh anchors every 12 inches (305mm) and installed per the manufacturer’s requirements.
Modified
p. 31
• Chain link, welded, or expanded steel metal fencing.
Modified
p. 31
• Minimum of 11-gauge wire used in the fencing.
Modified
p. 31
• Have a gap no more than 2’’ x 2” (50mm x 50mm).
Modified
p. 31
• The fencing shall mount to steel fence posts, rails, or metal studs.
Modified
p. 31
• 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.
Modified
p. 31
• Fencing will go from floor to true ceiling or fenced ceiling.
Modified
p. 31
• 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. 32
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 keyse.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. 32
• Non-repeatable key generation using
Modified
p. 32
• Repeatable key generation using
Modified
p. 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.
Modified
p. 33
• The initial DUKPT or TMK keys are encrypted from the KLD to the POI devices with a key of equal or greater strength.
Modified
p. 33
• The initial DUKPT or TMK keys are encrypted from the KLD to the POI devices with a key of equal or greater strength.
Modified
p. 33
• The KLD is secured in a dual locked cage, rack or cabinet that prevents a single key injection operator from performing any function other than injecting initial DUKPT into POI devices.
Modified
p. 33
• The KLD is in a secure mobile cart that uses dual locks that support dual control over access to the KLD inside the cart. When the mobile cart is not being used for injection it is stored in a secure room with access and CCTV controls similar to a secure KIF room.
Modified
p. 33
• Two authorized custodians are required to unlock the door to the secure mobile cart. Then all controls are the same as for the secure KIF room.
Modified
p. 33
• Two authorized key injection operators log in and initialize the key loading device so that it is ready to inject keys.
Modified
p. 33
• The KLD is secured in a dual locked mobile cage that prevents a single key injection operator from performing any function other than injecting initial keys into POI devices.
Modified
p. 34
• Maintain current documentation that describes or illustrates the architecture of the KIF, including all KIF functionality.
Modified
p. 34
• 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 is integrated into the flow.
Modified
p. 34
Q 1 November 2020: Does the use of TLS to convey keys in a KIF from a key loading device to a POI device constitute encrypted key loading? A If the origin and termination points of the TLS connection are within the secure boundaries of the source and target devicesi.e., the KLD and the POI devicesthen it constitutes encrypted key loading. If any private or secret keying material is in the clear outside of the secure boundaries of the source …
Q 1 November 2020: Does the use of TLS to convey keys in a KIF from a key loading device to a POI device constitute encrypted key loading? A If the origin and termination points of the TLS connection are within the secure boundaries of the source and target devices⎯i.e., the KLD and the POI devices⎯then it constitutes encrypted key loading. If any private or secret keying material is in the clear outside of the secure boundaries of the source …
Modified
p. 35 → 36
PIN Security Requirement 29
PIN Security Requirement 32
Modified
p. 35 → 36
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 …
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. 36
• Device-specific private keys for use in connection with remote key loading using asymmetric techniques.
Modified
p. 36
• Secret and private keys used for the protection of PIN data when conveyed between non- integrated components of a POI device
•e.g., an SCR and a PIN pad.
•e.g., an SCR and a PIN pad.
Modified
p. 36
• Terminal Master Keys (TMKs) and initial DUKPT keys.
Modified
p. 37
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 …
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. 37
• Prevents the passing or capture of restricted materials through openings.
Modified
p. 38
• Chain link, welded, or expanded steel metal fencing.
Modified
p. 38
• Minimum of 11-gauge wire used in the fencing.
Modified
p. 38
• Have a gap no more than 2’’ x 2” (50mm x 50mm).
Modified
p. 38
• The fencing shall mount to steel fence posts, rails, or metal studs.
Modified
p. 38
• Fencing will go from floor to true ceiling or fenced ceiling.
Modified
p. 38
• 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. 38
• 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. 38
• The injection system should be far enough away from the fencing to prevent an attacker from attaching a tapping device through the fence.