Document Comparison
PCI_PTS_HSM_Technical_FAQs_v3_June%202025.pdf
→
PCI_PTS_HSM_Technical_FAQs_v4_June_2025.pdf
52% similar
26 → 21
Pages
13151 → 8130
Words
80
Content Changes
Content Changes
80 content changes. 23 administrative changes (dates, page numbers) hidden.
Added
p. 6
Q 12 June 2022: Where a requirement specifies a need for the use of “cryptographic methods,” or the application of cryptography, to provide security. What is the intent of such requirements? A The intent of any requirement that references the need for cryptographic controls or the application of cryptography, is to ensure that the security of that system is based on the security of the underlying cryptographic protocol and key. It is not sufficient in such cases to rely solely on the use of strong cryptographic algorithms or protocols, the security and entropy of any cryptographic keys must also be sufficient. Sufficient entropy is considered to be an entropy that is at least equal to the bit strength of the cryptographic keys used.
Q 13 July 2022: Some HSM vendors use remote administration solutions that consist of vendor- provided smartcards used in conjunction with off-the-shelf, customer-provided personal computers. Can these be …
Q 13 July 2022: Some HSM vendors use remote administration solutions that consist of vendor- provided smartcards used in conjunction with off-the-shelf, customer-provided personal computers. Can these be …
Added
p. 9
Q 19 May 2023: Error logs cannot be accessed without assuming an authenticated role supported by the cryptographic module. Does this apply in all circumstances? A In the case that the error log does not contain any sensitive module information, an operator can assume an authorized (any defined role) role that does not require authentication in order to gain access to the module’s error log. CSPs cannot be present in the error log. The access also must not allow the modification or substitution of PSPs.
Added
p. 11
Q 27 June 2022: Is it acceptable to generate security related cryptographic keys solely from known or low-entropy data, such as passwords or serial numbers? A No. Any process used to generate cryptographic keys must ensure that there is sufficient entropy provided for the output key, and that the key-generation process includes consideration for dual control and split knowledge requirements. Sufficient entropy is considered to be an entropy that is at least equal to the bit strength of the output key. This entropy may be provided through use of an existing key-derivation key, such as with the use of a Base Derivation Key which may be applied to known data such as a device serial number, random values generated from a compliant random number generation source, or use of key-agreement protocols which themselves use random values from compliant random number generation sources.
Use of non-keyed, password-based key-derivation functions for the generation …
Use of non-keyed, password-based key-derivation functions for the generation …
Added
p. 12
Q 34 November (update) 2022: ANSI X9.143 defines three keys. A key block protection key (KBPK), a key block encryption key (KBEK), and a key block MAC key (KBMK). The KBPK is used to calculate the KBEK and the KBMK. Can the KBPK be used for any other purpose? A No. In order to meet the requirement that a key is used only for a single purpose as defined in ANSI X9.24, the key block protection key is only used to calculate the KBEK and the KBMK, and is not used for any other purpose. Only the KBPK is used to generate the KBEK and the KBMK key; no other key is used for this purpose.
Added
p. 15
Q 42 December 2022: For Key Blocks, is the same MAC key allowed to be used across different MAC algorithms, or is a key unique to each algorithm implemented required? A A key unique to each implemented MAC algorithm must be used as specified in ANSI X9.143.
Q 43 March (update) 2024: Can an HSM support other key distribution using asymmetric techniques ASC X9 TR 34? A If the HSM supports key distribution using asymmetric techniques, it must support TR-34; or ECDH to allow derivation of a shared secret key followed by symmetric encryption of, at least, the symmetric key with ECDSA signature over the encrypted key and attributes. Other key distribution using asymmetric techniques can also exist on the device.
Q 44 December (update) 2023: HSMs support Elliptic Curve Cryptography for various functions, including personalization, key conveyance and transaction processing. Are there any specific implementations required? A In support of ECC …
Q 43 March (update) 2024: Can an HSM support other key distribution using asymmetric techniques ASC X9 TR 34? A If the HSM supports key distribution using asymmetric techniques, it must support TR-34; or ECDH to allow derivation of a shared secret key followed by symmetric encryption of, at least, the symmetric key with ECDSA signature over the encrypted key and attributes. Other key distribution using asymmetric techniques can also exist on the device.
Q 44 December (update) 2023: HSMs support Elliptic Curve Cryptography for various functions, including personalization, key conveyance and transaction processing. Are there any specific implementations required? A In support of ECC …
Added
p. 17
Q 48 May 2022: If a PIN block translating HSM does not enforce a unique key per transaction encryption for the resulting PIN block, what restrictions apply to prevent the misuse of card issuance-related functions? A The following restrictions apply:
• Standard PIN block formats⎯i.e., ISO format 0, 1, 2, 3 and 4⎯shall not be translated into non-standard PIN block formats and translations between these PIN block formats shall be restricted as specified in the table in DTR B14.
• PIN block translations where the real PAN or PAN Token changes⎯i.e., PAN translation⎯shall not be permitted, except in any of the following circumstances:
For card issuance, where i) the translation is between PIN blocks using real PANs, ii) the introduction of a new PAN is required to support account number changes, and iii) it is not performed in interchange processing systems; or For translation between a tokenized PAN and a “real” …
• Standard PIN block formats⎯i.e., ISO format 0, 1, 2, 3 and 4⎯shall not be translated into non-standard PIN block formats and translations between these PIN block formats shall be restricted as specified in the table in DTR B14.
• PIN block translations where the real PAN or PAN Token changes⎯i.e., PAN translation⎯shall not be permitted, except in any of the following circumstances:
For card issuance, where i) the translation is between PIN blocks using real PANs, ii) the introduction of a new PAN is required to support account number changes, and iii) it is not performed in interchange processing systems; or For translation between a tokenized PAN and a “real” …
Added
p. 20
Q 57 August 2022: Vendors can have various options for both hardware and firmware that may be either security- or non-security-relevant. For non-security-relevant options, vendors are allowed to designate in their hardware/firmware identifiers a lower case “x” in the relevant position. Security-relevant options must have specific numbers and/or letters assigned and listed as part of the approval. The Program Guide specifies that options, both security- and non-security-relevant must be clearly defined and documented as to the options available and their function in the device’s Security Policy. Through oversight, some Security Policies do not have this information. Does this information need to be included? A Yes. All report submittals, whether “New” or “Delta” must ensure that the device’s Security Policy required for the PCI website includes this information. This includes necessary updates to existing Security Policies.
Q 58 April 2023: HSM virtualization systems that are not implemented within a physical system that …
Q 58 April 2023: HSM virtualization systems that are not implemented within a physical system that …
Modified
p. 1
Payment Card Industry (PCI) PTS HSM Security Requirements Technical FAQs for use with Version 3
Payment Card Industry (PCI) PTS HSM Security Requirements Technical FAQs for use with Version 4
Removed
p. 3
Q 2 October 2011: Some requirements are derived from requirements in Federal Information Processing Standard 140-2 (FIPS 140-2). These requirements are identified with an asterisk (*) in the security requirements number column. How much reliance may an evaluator place upon work performed under FIPS 140-2? A Evaluations performed under the FIPS 140-2 program that resulted in a FIPS 140-2 certification may be considered in a PCI HSM evaluation. In order to do so, the PCI evaluating laboratory must have access to the prior evaluation report(s) under the FIPS 140-2 program. The evaluator then will establish:
• The HSM components that were evaluated;
• The security level of the evaluation;
• That the existing FIPS certification covers the full HSM functionality for all the related requirements.
In all cases, regardless of any prior work, the evaluating lab is responsible for performing the degree of work necessary to ensure the compliance of the device under evaluation …
• The HSM components that were evaluated;
• The security level of the evaluation;
• That the existing FIPS certification covers the full HSM functionality for all the related requirements.
In all cases, regardless of any prior work, the evaluating lab is responsible for performing the degree of work necessary to ensure the compliance of the device under evaluation …
Modified
p. 3
Q 1 Typical HSM deployments include those at data centers or other secure facilities such as payment card personalizers. Are there any stipulations or restrictions by PCI on either form factors or usage scenarios? A PCI shall approve devices that are intended for use as HSMs in secure facilities and which meet the PCI HSM security requirements. Implementation and deployment considerations are the responsibly of the individual payment brands.
Q 1 Typical HSM deployments include those at data centers or other secure facilities such as payment card personalizers. Are there any stipulations or restrictions by PCI on either form factors or usage scenarios? A PCI shall approve devices that are intended for use as HSMs in secure facilities and which meet the PCI HSM security requirements. Implementation and deployment considerations are the responsibility of the individual payment brands.
Modified
p. 3
Q 3 June 2012: What part of the HSM lifecycle does the PCI HSM standard cover? A The PCI HSM standard covers the lifecycle of the HSM up to the point of its first delivery to the initial point of deployment facility. Subsequent stages of the HSM’s lifecycle continue to be of interest to PCI and are controlled by other PCI standards
Q 2 June 2012: What part of the HSM lifecycle does the PCI HSM standard cover? A The PCI HSM standard covers the lifecycle of the HSM up to the point of its first delivery to the initial point of deployment facility. Subsequent stages of the HSM’s lifecycle continue to be of interest to PCI and are controlled by other PCI standards.
Removed
p. 4
Q 6 September 2015: When is an “N/A” response to a requirement acceptable? A An “N/A” response is acceptable in two cases: First, if compliance is achieved by meeting another requirement option, if one exists. Second, if the characteristics governed by the requirement are absent in the device. The evaluation laboratory will verify that all responses are appropriate.
Q 7 May (update) 2018: What is the definition of “Secret Information?” A “Secret information” is any cryptographic keys or passwords/authentication codes that the device relies on to maintain security characteristics governed by PCI requirements.
Q 8 September 2015: Some components of a device may include cryptographic keys that cannot be erased. Are there any instances when this would be acceptable? See Requirements A1 and A5. A Cryptographic keys that are never used to encrypt or decrypt data; or are not used for authentication, do not need to be considered secret data, and therefore …
Q 7 May (update) 2018: What is the definition of “Secret Information?” A “Secret information” is any cryptographic keys or passwords/authentication codes that the device relies on to maintain security characteristics governed by PCI requirements.
Q 8 September 2015: Some components of a device may include cryptographic keys that cannot be erased. Are there any instances when this would be acceptable? See Requirements A1 and A5. A Cryptographic keys that are never used to encrypt or decrypt data; or are not used for authentication, do not need to be considered secret data, and therefore …
Modified
p. 4 → 3
Q 4 December 2013: If a user has taken delivery of an HSM for which the hardware has been approved for PCI HSM, and all of the PCI HSM requirements relating to manufacturing and to delivery to the point of initial deployment have been met, but the shipped firmware/software has not been approved for PCI HSM does the HSM become PCI HSM compliant when approved firmware/software is installed or the shipped firmware/software becomes approved at a later date? Yes, subject …
Q 3 December 2013: If a user has taken delivery of an HSM for which the hardware has been approved for PCI HSM, and all of the PCI HSM requirements relating to manufacturing and to delivery to the point of initial deployment have been met, but the shipped firmware/software has not been approved for PCI HSM, does the HSM become PCI HSM compliant when approved firmware/software is installed, or does the shipped firmware/software become approved at a later date? A …
Modified
p. 4 → 3
The software version identifiers for the approved and non-approved firmware/software versions must be distinct, with the identifier for the approved firmware/software appearing on the PCI HSM approval. The HSM is only compliant with PCI HSM during the period that it is running firmware/software has been approved for PCI HSM.
The software version identifiers for the approved and non-approved firmware/software versions must be distinct, with the identifier for the approved firmware/software appearing on the PCI HSM approval. The HSM is only compliant with PCI HSM during the period that it is running firmware/software that has been approved for PCI HSM.
Modified
p. 4
Q 5 December 2013: Is it permissible to install firmware/software which is not PCI HSM approved on an HSM which is fully PCI HSM compliant, and for the PCI HSM compliance of the HSM to be restored at a later date by installing an approved version of firmware/software? A The PCI HSM compliance of the HSM ceases when the non-approved firmware/software is installed. The PCI HSM compliance of the HSM is restored if approved firmware/software is subsequently installed, subject to …
Q 4 December 2013: Is it permissible to install firmware/software which is not PCI HSM approved on an HSM which is fully PCI HSM compliant, and for the PCI HSM compliance of the HSM to be restored at a later date by installing an approved version of firmware/software? A The PCI HSM compliance of the HSM ceases when the non-approved firmware/software is installed. The PCI HSM compliance of the HSM is restored if approved firmware/software is subsequently installed, subject to …
Removed
p. 5
Q 9 September 2015: What is a “Delta” Revisions to approved devices are termed “deltas.” Delta reviews involve the laboratory assessing the changes based on the current major version (e.g., 1.x, 2.x, etc.) of the requirements that were used for the approval of the device. Examples of deltas include:
• Revisions to existing firmware or hardware on existing approved devices to add or modify functionality
• Maintenance fixes on devices that have expired and are no longer approved for new deployments
• The porting of a new set of firmware to an existing approved device.
Q 10 September 2015: Does the device have to show the version numbers of the hardware, firmware and Application? A The device must show the version numbers of hardware and firmware like they have been approved and they are shown in the list of approved devices. The hardware number must be shown on a label attached to the device. …
• Revisions to existing firmware or hardware on existing approved devices to add or modify functionality
• Maintenance fixes on devices that have expired and are no longer approved for new deployments
• The porting of a new set of firmware to an existing approved device.
Q 10 September 2015: Does the device have to show the version numbers of the hardware, firmware and Application? A The device must show the version numbers of hardware and firmware like they have been approved and they are shown in the list of approved devices. The hardware number must be shown on a label attached to the device. …
Removed
p. 5
Q 13 September 2015: Are PC-based instruments like protocol sniffers, USB attached oscilloscope adapters and graphical multimeters, etc. considered standard or specialized equipment. A PC-based instrument like those mentioned above shall be considered standard equipment, especially if they do not require dedicated hardware or adapters.
Q 16 September 2015: Security requirements are normally available for a four-year period from date of publication for new evaluations of products. Products are approved until six years after the retirement/expiration of the version of security requirements against which they were approved. This results in approvals that are a minimum of six years and a maximum of ten years, depending on the timeframe in which the approval occurs in relation to the life cycle of the applicable security requirements. Modifications for approved devices, termed “deltas,” can occur at any time during the product’s approval.
Can products for which the approval has expired undergo deltas? A Yes. Vendors …
Q 16 September 2015: Security requirements are normally available for a four-year period from date of publication for new evaluations of products. Products are approved until six years after the retirement/expiration of the version of security requirements against which they were approved. This results in approvals that are a minimum of six years and a maximum of ten years, depending on the timeframe in which the approval occurs in relation to the life cycle of the applicable security requirements. Modifications for approved devices, termed “deltas,” can occur at any time during the product’s approval.
Can products for which the approval has expired undergo deltas? A Yes. Vendors …
Modified
p. 6 → 4
Q 14 September 2015: Some attacks are technically simple in that they do not require an extensive identification, like sniffing a communication on standard interfaces like USB/Ethernet between devices. How is the attack value calculation to be performed then? A For technically simple attacks that do not require an extensive identification, like sniffing a communication on standard interfaces like USB/Ethernet between devices, all cost factors besides time and expertise should be disregarded. Also, attack time and expertise is to be …
Q 5 September 2015: Some attacks are technically simple in that they do not require an extensive identification, such as sniffing a communication on standard interfaces like USB/Ethernet between devices. How is the attack value calculation to be performed then? A For technically simple attacks that do not require an extensive identification, such as sniffing a communication on standard interfaces like USB/Ethernet between devices, all cost factors besides time and expertise should be disregarded. Also, attack time and expertise is …
Modified
p. 6 → 4
Q 15 September 2015: In occurrences where it is necessary to return a device to the device vendor for maintenance, are there any restrictions on what must happen to the secret keys in the device? A When a device is returned to the vendor for maintenance, mechanisms must be in place to automatically cause the erasure of all previously loaded acquirer secret keys upon servicing the device•e.g., loading a new public RSA key causes the erasure of all previously loaded …
Q 6 September 2015: In occurrences where it is necessary to return a device to the device vendor for maintenance, are there any restrictions on what must happen to the secret keys in the device? A When a device is returned to the vendor for maintenance, mechanisms must be in place to automatically cause the erasure of all previously loaded acquirer secret keys upon servicing the device•e.g., loading a new public RSA key causes the erasure of all previously loaded …
Removed
p. 7
In all cases, the evaluation laboratory must advise PCI SSC of the circumstances, and PCI SSC will make the final decision based upon the circumstances. Additionally, for both new and delta evaluations, the laboratory will also state in their submission the version of the security requirements used in the evaluations, as well as the publication date of the technical FAQs used.
Q 18 September 2015: The program manual stipulates that "Vendors or other third parties licensing approved products from other vendors to market or distribute under their own names are not required to pay a new evaluation fee if the only change is to the name plate. If firmware and/or hardware changes are made that require a PCI-recognized test laboratory to evaluate the changes for potential security impact, then the licensee shall be required to pay the new evaluation fee. In all cases the licensed device will receive a new approval …
Q 18 September 2015: The program manual stipulates that "Vendors or other third parties licensing approved products from other vendors to market or distribute under their own names are not required to pay a new evaluation fee if the only change is to the name plate. If firmware and/or hardware changes are made that require a PCI-recognized test laboratory to evaluate the changes for potential security impact, then the licensee shall be required to pay the new evaluation fee. In all cases the licensed device will receive a new approval …
Removed
p. 8
Q 19 September 2015: For attack potential calculations, information is classified as Public, Restricted or Sensitive. What are examples of each? A Information is considered Public if it can be easily obtained from the Internet or is provided without any control mechanisms. Examples include open protocol specifications and electronic component datasheets. Information with automated access controls mechanisms (such as online account subscription) without human intervention classifies as Public. Restricted information is distributed upon request and is subject to human-based control mechanisms. Examples of Restricted information are mechanical drawings for OEM device integration, external command API specifications, partial Gerber files, and secure processor datasheets available under NDA. Sensitive information is not intended to be distributed to external entities and is obtained by means such as “social engineering” theft or coercion. Typical examples are device schematics and firmware source code.
Q 20 September 2015: For attack-potential calculations, if the same equipment used for …
Q 20 September 2015: For attack-potential calculations, if the same equipment used for …
Modified
p. 11 → 5
Q 34 October 2015: Are HSMs that provide for multiple ‘virtualized’ instances operating with different keysets within a single physical HSM permitted under the PCI HSM approval process? A PCI does not aim to mandate or prevent any specific implementations or instantiations of HSM devices, but requires that any device that is to be advertised as PCI HSM approved meets the requirements outlined in the current version of the PCI HSM DTRs. Multiple ‘virtualized’ instances of HSMs are permitted, but …
Q 8 October 2015: Are HSMs that provide for multiple “virtualized” instances operating with different keysets within a single physical HSM permitted under the PCI HSM approval process? A PCI does not aim to mandate or prevent any specific implementations or instantiations of HSM devices but requires that any device that is to be advertised as PCI HSM approved meets the requirements outlined in the current version of the PCI HSM DTRs. Multiple “virtualized” instances of HSMs are permitted but …
Removed
p. 12
Q 36 September 2016: The program manual states that hardware and firmware version number identifiers may consist of a combination of fixed and variable alphanumeric characters, whereby a lowercase "x" is used by PCI to designate all variable fields. The "x" represents fields that the vendor can change at any time to denote a different device configuration. Examples include: country usage code, customer code, communication interface, device color, etc. What are examples of options that cannot be addressed by use of a variable field, but must be addressed by a fixed character? A Options that cannot be a variable character include those that directly pertain to meeting security requirements. Examples include remote administration, KLD, privacy shield, FIPS mode or PCI mode support. If wildcards are used, the specific configurations validated by the PTS Recognized Lab must be explicitly noted on the approval. In addition, all wildcard options, both security and …
Modified
p. 12 → 5
Q 35 June 2016: Some HSMs exist as standalone cards/components which are meant to be installed into a larger chassis/compound enclosure. Are there any special requirements which must be met for HSMs with this form factor? A Yes. If an HSM is meant to be installed into a chassis/compound enclosure, a mechanism must be provided to validate the hardware and firmware version of the HSM. If this mechanism requires performing a procedure to retrieve this information (I.e., via a software …
Q 9 June 2016: Some HSMs exist as standalone cards/components which are meant to be installed into a larger chassis/compound enclosure. Are there any special requirements which must be met for HSMs with this form factor? A Yes. If an HSM is meant to be installed into a chassis/compound enclosure, a mechanism must be provided to validate the hardware and firmware version of the HSM. If this mechanism requires performing a procedure to retrieve this information⎯i.e., via a software library …
Modified
p. 13 → 5
Q 38 November (update) 2018: Several requirements stipulate that if the device is restricted to deployment in Controlled Environments as defined in ISO 13491, then specific restrictions apply in the attack techniques that can be used. If the restrictions preclude any viable attacks for a specific requirement, how must that be presented in the evaluation report? A The report must present attack scenarios as stipulated in the derived test requirements. These must be presented without the restrictions of the Controlled …
Q 10 November (update) 2018: Several requirements stipulate that if the device is restricted to deployment in Controlled Environments as defined in ISO 13491, then specific restrictions apply in the attack techniques that can be used. If the restrictions preclude any viable attacks for a specific requirement, how must that be presented in the evaluation report? A The report must present attack scenarios as stipulated in the derived test requirements. These must be presented without the restrictions of the Controlled …
Modified
p. 13 → 5
Q 39 November 2021: PTS vendors are required to make all source code pertinent to Security Requirements available to the test laboratories. Multiple test requirements require the test laboratories to review that code to facilitate validation to the applicable Security Requirements. Should those code segments (snippets) be included in the reports? A Yes, unless stated in the test requirement that the sample is not required, the segment or snippet is considered evidence of meeting the security requirement. Code samples serve …
Q 11 November 2021: PTS vendors are required to make all source code pertinent to Security Requirements available to the test laboratories. Multiple test requirements require the test laboratories to review that code to facilitate validation to the applicable Security Requirements. Should those code segments (snippets) be included in the reports? A Yes. Unless stated in the test requirement that the sample is not required, the segment or snippet is considered evidence of meeting the security requirement. Code samples serve …
Modified
p. 13 → 7
Q 40 June 2025: Devices may support Post-Quantum Cryptography (PQC), also known as Quantum Resistant, in addition to classic cryptography. Specifically, cryptographic algorithms that are currently thought - e.g., as published by NIST - to be secure against a cryptanalytic attack by a quantum computer. Is there an option for this to be noted as part of the PCI approval? A Yes. Where the lab validates the support of PQC algorithms in the API and/or processing of the device and …
Q 14 June 2025: Devices may support Post-Quantum Cryptography (PQC), also known as Quantum Resistant, in addition to classic cryptography. Specifically, cryptographic algorithms that are currently thought - e.g., as published by NIST - to be secure against a cryptanalytic attack by a quantum computer. Is there an option for this to be noted as part of the PCI approval? Yes. Where the lab validates the support of PQC algorithms in the API and/or processing of the device and includes …
Modified
p. 14 → 8
Q 41 September 2015: In the event of tamper, the device must become immediately inoperable and result in the automatic and immediate erasure of any secret information that may be stored in the device, such that it becomes infeasible to recover the secret information. Guidance notes provide that secret or private keys do not need to be zeroized if either or both of the following conditions exist:
• If any of these keysare not zeroized, then other mechanisms must exist …
• If any of these keys
Q 15 September 2015: In the event of tamper, the device must become immediately inoperable and result in the automatic and immediate erasure of any secret information that may be stored in the device, such that it becomes infeasible to recover the secret information. Guidance notes provide that secret or private keys do not need to be zeroized if either or both of the following conditions exist:
• If any of these keys is not zeroized, other mechanisms must exist to …
• If any of these keys is not zeroized, other mechanisms must exist to …
Modified
p. 14 → 8
• The keys are never used to encrypt or decrypt data, or are not used for authentication.
• The keys are never used to encrypt or decrypt data and are not used for authentication.
Modified
p. 14 → 8
Do any other conditions apply? A The keys (secret or private) are never used to encrypt or decrypt other keys. Keys that can be used to download other keys to make the device operable must either be zeroized or rendered inoperable for use in downloading new keys. E.g., both symmetric KEKs used for key loading using symmetric techniques and private keys associated with key loading using asymmetric techniques. The device must enforce that tampered devices require withdrawal from use for …
Do any other conditions apply? A The keys (secret or private) are never used to encrypt or decrypt other keys. Keys that can be used to download other keys to make the device operable must either be zeroized or rendered inoperable for use in downloading new keys⎯e.g., both symmetric KEKs used for key loading using symmetric techniques and private keys associated with key loading using asymmetric techniques. The device must enforce that tampered devices require withdrawal from use for inspection, …
Modified
p. 14 → 8
Q 42 September 2015: A device uses a key that is randomly generated internally in the secure processor to protect other keys. This key is stored in the clear and protected within a register in the same secure processor. The secure processor resides within a secure area of the device. This key is used to encrypt other keys, which are stored encrypted outside the secure processor•e.g., in flash memory that also resides within the secure area of the device. Upon …
Q 16 September 2015: A device uses a key that is randomly generated internally in the secure processor to protect other keys. This key is stored in the clear and protected within a register in the same secure processor. The secure processor resides within a secure area of the device. This key is used to encrypt other keys, which are stored encrypted outside the secure processor•e.g., in flash memory that also resides within the secure area of the device. Upon …
Modified
p. 14 → 8
Q 1 September 2015: What standards and methods are used for measuring “electro-magnetic emissions”? A Vendors should take into account that EM emissions can be a risk to PIN data, and should design to address this risk. There are many methods for shielding and minimizing EM emissions. The vendor must describe to the laboratory in writing how EM emissions are addressed by the device design. The laboratory will examine evidence provided by the vendor to determine if the evidence supports …
Q 17 September 2015: What standards and methods are used for measuring “electro-magnetic emissions”? A Vendors should take into account that EM emissions can be a risk to PIN data and should design to address this risk. There are many methods for shielding and minimizing EM emissions. The vendor must describe to the laboratory in writing how EM emissions are addressed by the device design. The laboratory will examine evidence provided by the vendor to determine if the evidence supports …
Removed
p. 15
Q 1 Does the device need to have an electronic audit record for power-up self-tests? A Yes. The device must include an audit record showing the self-test execution and record the result.
Q 2 September 2015: What is required to meet B1? A The device must perform an internal self-test automatically at least once every day, in addition to at power-up. Firmware integrity tests may use techniques such as SHA-2 or equivalent. Authenticity testing must use cryptographic methods (MACs, digital signature or encryption). The hash must either be cryptographically protected using a key (e.g., HMAC-SHA-2) or physically protected equivalent to a secret key. LRC, CRC and other non-cryptographic methods and weak cryptographic methods (e.g., SHA-1, MD5) are not allowed as the primary mechanisms for either authentication or integrity checking.
Q 3 September 2015: Is it acceptable to perform a self-test after several minutes of inactivity rather than once every 24 hours? A …
Q 2 September 2015: What is required to meet B1? A The device must perform an internal self-test automatically at least once every day, in addition to at power-up. Firmware integrity tests may use techniques such as SHA-2 or equivalent. Authenticity testing must use cryptographic methods (MACs, digital signature or encryption). The hash must either be cryptographically protected using a key (e.g., HMAC-SHA-2) or physically protected equivalent to a secret key. LRC, CRC and other non-cryptographic methods and weak cryptographic methods (e.g., SHA-1, MD5) are not allowed as the primary mechanisms for either authentication or integrity checking.
Q 3 September 2015: Is it acceptable to perform a self-test after several minutes of inactivity rather than once every 24 hours? A …
Removed
p. 16
Q 1 September 2015: What is considered “firmware”? (OS, EPROM code, DLL’s, parameter files, applications, kernel code)? A Firmware is considered to be any code within the device that provides security protections needed to comply with PCI HSM requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI HSM requirements.
Q 2 September 2015: What methods are acceptable to “certify” firmware? A “Certify firmware” refers to self-certification. This requirement, in essence, requires the vendor to have implemented and to use internal quality control and change control systems. With these systems in place, the vendor is in control of the code and can attest to the fact that the code is free of hidden or unauthorized functions by answering yes to B3.
Q 3 September 2015: Many devices are designed so that third parties can create and load applications. Vendors …
Q 2 September 2015: What methods are acceptable to “certify” firmware? A “Certify firmware” refers to self-certification. This requirement, in essence, requires the vendor to have implemented and to use internal quality control and change control systems. With these systems in place, the vendor is in control of the code and can attest to the fact that the code is free of hidden or unauthorized functions by answering yes to B3.
Q 3 September 2015: Many devices are designed so that third parties can create and load applications. Vendors …
Modified
p. 16 → 9
Q 1 September 2015: What parties may possess keys used for the cryptographic authentication of firmware updates? A The firmware is the responsibility of the device vendor, and as such the cryptographic keys that authenticate it within the device must be held solely by the vendor or their designated agent.
Q 20 September 2015: What parties may possess keys used for the cryptographic authentication of firmware updates? A The firmware is the responsibility of the device vendor, and as such the cryptographic keys that authenticate it within the device must be held solely by the vendor or their designated agent.
Modified
p. 16 → 9
Q 2 September 2015: Firmware updates must be cryptographically authenticated, and if the authentication fails, the update is rejected and deleted. Are there any circumstances where firmware can be updated without authentication? A Some chipsets are not designed for firmware updates, but only to support firmware replacement. The deletion of the existing firmware and cryptographic keys during the replacement does not allow for the authentication of the new firmware to occur.
Q 21 September 2015: Firmware updates must be cryptographically authenticated, and if the authentication fails, the update is rejected and deleted. Are there any circumstances where firmware can be updated without authentication? A Some chipsets are not designed for firmware updates, but only to support firmware replacement. The deletion of the existing firmware and cryptographic keys during the replacement does not allow for the authentication of the new firmware to occur. In such cases it is acceptable to update the …
Removed
p. 17
Q 4 September 2015: Devices may have functions for zeroizing secret and private keys in the device. Are these functions considered sensitive services that require authentication? A Yes, the intentional zeroization of secret or private keys in a non-tamper event is the execution of functions that are not available during normal use. This requires authentication consistent with the implementations of other sensitive services, such as the use of PINs/passphrases. If implemented, the device must force the authentication values to be changed from default values upon configuration of the device. The authentication mechanism may optionally employ dual control techniques.
Modified
p. 17 → 9
Q 3 September 2015: If a device supports firmware updates, the device must cryptographically authenticate the firmware, and if the firmware is not confirmed, the firmware update must be rejected and deleted. Can a device completely load new firmware before checking its authenticity and overwrite its primary copy of existing authenticated code if it retains a secure backup copy of the existing authenticated code? A Yes, provided the following is true:
Q 22 September 2015: If a device supports firmware updates, the device must cryptographically authenticate the firmware, and if the firmware is not confirmed, the firmware update must be rejected and deleted. Can a device completely load new firmware before checking its authenticity and overwrite its primary copy of existing authenticated code if it retains a secure backup copy of the existing authenticated code? A Yes, provided the following is true: • The new code is cryptographically authenticated prior to …
Modified
p. 17 → 10
Q 1 September 2015: Is it acceptable to XOR key components during key loading to satisfy the authentication requirements of B7?
• The XOR of key components alone is not enough to constitute authentication. Some type of authentication of the users that use the key loading function, or authentication of the key- loading command is required.
•
Q 23 September 2015: Is it acceptable to XOR key components during key loading to satisfy the authentication requirements of B6? A The XOR of key components alone is not enough to constitute authentication. Some type of authentication of the users that use the key loading function, or authentication of the key-loading command is required.
Modified
p. 17 → 10
Q 2 September 2015: For devices that require the use of authentication data to access sensitive functions, and the authentication data are static, can the authentication data be sent with the device? A The authentication data can be sent with the device only when the authentication data is in tamper-evident packaging, such as the use of PIN mailers. Otherwise separate communication channels must be used with pre-designated recipients.
Q 24 September 2015: For devices that require the use of authentication data to access sensitive functions, and the authentication data are static, can the authentication data be sent with the device? A The authentication data can be sent with the device only when the authentication data is in tamper-evident packaging, such as the use of PIN mailers. Otherwise, separate communication channels must be used with pre-designated recipients.
Modified
p. 17 → 10
Q 3 September 2015: Plain-text secret or private keys and their components may be injected into a HSM using a key loader (which has to be some type of secure cryptographic device). Are there any restrictions on loading keys via this methodology? A Yes, the loading of plain-text secret or private keys and their components using a key-loader device is restricted to a controlled environment.
Q 25 September 2015: Plain-text secret or private keys and their components may be injected into a HSM using a key loader (which has to be some type of secure cryptographic device). Are there any restrictions on loading keys via this methodology? A Yes. The loading of plain-text secret or private keys and their components using a key-loader device is restricted to a controlled environment.
Removed
p. 18
Q 3 September 2015: What PIN block formats are allowed? A ISO 9564•1 PIN block formats 0, 1, 3 or 4 are acceptable for online transactions.
Q 5 September 2015: Is it acceptable to use TDES ECB mode encryption for session keys when using the Master Key/session key technique? A Yes. TDES ECB mode can be used to encrypt session keys.
For example, it would be acceptable to generate a full-length 128-bit TDES key component, but load it into the device as two 64-bit component halves.
Q 5 September 2015: Is it acceptable to use TDES ECB mode encryption for session keys when using the Master Key/session key technique? A Yes. TDES ECB mode can be used to encrypt session keys.
For example, it would be acceptable to generate a full-length 128-bit TDES key component, but load it into the device as two 64-bit component halves.
Modified
p. 18 → 11
Q 1 Are HSMs allowed to have keys that are not unique per device? A Yes, but only for load balancing and disaster recovery purposes.
Q 28 Are HSMs allowed to have keys that are not unique per device? A Yes, but only for load balancing and disaster recovery purposes.
Modified
p. 18 → 11
Q 2 September 2015: Is it acceptable for a device to have the ability to use Master Keys as both key-encryption keys for session key and as fixed keys•i.e., the Master Key could be used to encrypt PIN blocks and to decrypt session keys? A No. A key must be used for one purpose only as mandated in ANSI X9.24 and ISO 11568.
Q 29 September 2015: Is it acceptable for a device to have the ability to use Master Keys as both key-encryption keys for session key and as fixed keys•i.e., the Master Key could be used to encrypt PIN blocks and to decrypt session keys? A No. A key must be used for one purpose only as mandated in ANSI X9.24 and ISO 11568.
Modified
p. 18 → 11
Q 4 September 2015: Is it acceptable to use the same authentication technique for loading both cryptographic keys and firmware? A The technique may be the same, but the secrets used for authentication must be different. Example: If RSA signatures are used, the RSA private key used to sign cryptographic keys for loading must be different from the private key used to sign firmware.
Q 30 September 2015: Is it acceptable to use the same authentication technique for loading both cryptographic keys and firmware? A The technique may be the same, but the secrets used for authentication must be different. Example: If RSA signatures are used, the RSA private key used to sign cryptographic keys for loading must be different from the private key used to sign firmware.
Modified
p. 18 → 12
Q 6 September 2015: Is it acceptable to load double-length 128-bit TDES key components into a device in smaller bit-values (e.g., two 64-bit parts held by key custodian 1 and two 64-bit parts held by key custodian 2)? A Yes, provided the 128-bit cryptographic TDES keys (and key components) are generated and managed as full double-length 128 bit TDES keys during their entire life cycle in accordance with ANSI X9.24 and ISO 11568.
Q 32 September 2015: Is it acceptable to load double-length 128-bit TDES key components into a device in smaller bit-values⎯e.g., two 64-bit parts held by key custodian 1 and two 64-bit parts held by key custodian 2? A Yes, provided the 128-bit cryptographic TDES keys (and key components) are generated and managed as full double-length 128-bit TDES keys during their entire life cycle in accordance with ANSI X9.24 and ISO 11568. For example, it would be acceptable to generate a …
Modified
p. 18 → 12
It would not be acceptable to generate 64 bit keys or key components separately, and then concatenate them for use as a double length key after generation.
It would not be acceptable to generate 64-bit keys or key components separately, and then concatenate them for use as a double length key after generation.
Modified
p. 18 → 12
If key-check values are used to ensure key integrity, they must be calculated over the entire 128- bit key component or the resultant 128-bit key, but never on a portion of the key or key component. In addition, the resultant key inside the device must be recombined in accordance with PCI requirements and ANSI/ISO standards. Similarly for triple-length keys, the entire 192 bit key component or the resultant 192-bit key must be used to calculate the key-check values.
If key-check values are used to ensure key integrity, they must be calculated over the entire 128- bit key component or the resultant 128-bit key, but never on a portion of the key or key component. In addition, the resultant key inside the device must be recombined in accordance with PCI requirements and ANSI/ISO standards. Similarly for triple-length keys, the entire 192-bit key component or the resultant 192-bit key must be used to calculate the key-check values.
Modified
p. 18 → 12
Q 7 September 2015: Under what conditions is it acceptable for a device to allow single component plain-text cryptographic keys to be loaded via a keypad? A None. A device must not accept entry of single component plain-text cryptographic keys via a keypad. Full-length key components and encrypted keys may be loaded via a keypad if the requirements for sensitive functions are met.
Q 33 September 2015: Under what conditions is it acceptable for a device to allow single component plain-text cryptographic keys to be loaded via a keypad? A None. A device must not accept entry of single component plain-text cryptographic keys via a keypad. Full-length key components and encrypted keys may be loaded via a keypad if the requirements for sensitive functions are met.
Removed
p. 19
Q 8 September 2015: ISO 11568-2 Symmetric ciphers, their key management and life cycle and ANSI X9.24-1 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques stipulate that a key-encipherment key shall be at least of equal or greater strength than the key that it is protecting. What keys does this apply to in a device? A This applies to any key-encipherment keys used for the protection of secret or private keys stored in the device or for keys used to encrypt any secret or private keys for loading or transport to the device. For purpose of this requirement, the following algorithms and keys sizes by row are considered equivalent.
Algorithm DES RSA Elliptic Curve DSA Minimum key size in number of bits 168 2048 224 2048/224 DES refers to non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers …
Algorithm DES RSA Elliptic Curve DSA Minimum key size in number of bits 168 2048 224 2048/224 DES refers to non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers …
Removed
p. 19
Q 10 September 2015: TR-31 defines three keys. A key block protection key (KBPK), a key block encryption key (KBEK) and a key block MAC key (KBMK). The KBPK is used to calculate the KBEK and the KBMK. Can the KBPK be used for any other purpose? A No, in order to meet the requirement that a key is used only for a single purpose as defined in ANSI X9.24, the key block protection key is only used to calculate the KBEK and the KBMK, and is not used for any other purpose. Only the KBPK is used to generate the KBEK and the KBMK key; no other key is used for this purpose.
Q 11 September 2015: A device may support key-check values to validate the successful entry of symmetric key components and/or keys. Are there any restrictions on the use of key- check values? A Yes. Any returned values …
Q 11 September 2015: A device may support key-check values to validate the successful entry of symmetric key components and/or keys. Are there any restrictions on the use of key- check values? A Yes. Any returned values …
Modified
p. 20 → 12
Q 13 September 2015: The Guidance for DTR B11 states, “A device may include more than one compliant key-exchange and storage scheme. This does not imply that the device must enforce TR-31 or an equivalent scheme, but it must be capable of implementing such a scheme as a configuration option.” If the use of TR-31 as the key-exchange mechanism is optional, must there be an explicit device configuration change to enable/disable TR-31 as the "active" key-exchange scheme? A Yes an …
Q 35 November (update) 2022: The Guidance for DTR B10 states, “A device may include more than one compliant key-exchange and storage scheme. This does not imply that the device must enforce ANSI X9.143 or an equivalent scheme, but it must be capable of implementing such a scheme as a configuration option.” If the use of ANSI X9.143 as the key-exchange mechanism is optional, must there be an explicit device configuration change to enable/disable ANSI X9.143 as the "active" key-exchange …
Modified
p. 20 → 13
Q 15 May (update) 2018: Can secret keys or their components be used for other purposes such as passwords/authentication codes to enable the use of sensitive services? A No. The use of secret keys or their components for other purposes violates the requirement that keys be used for their sole intended purpose, e.g., key encipherment or PIN encipherment, etc.
Q 37 May (update) 2018: Can secret keys or their components be used for other purposes, such as passwords/authentication codes, to enable the use of sensitive services? A No. The use of secret keys or their components for other purposes violates the requirement that keys be used for their sole intended purpose⎯e.g., key encipherment or PIN encipherment, etc.
Modified
p. 20 → 13
Q 16 September 2015: The PCI PIN Security Requirements stipulate that any cryptographic device used in connection with the acquisition of PIN data that is removed from service must have all keys stored within the device destroyed that have been used (or potentially could be) for any cryptographic purpose. If necessary to comply with the above, the device must be physically destroyed so that it cannot be placed into service again, or allow the disclosure of any secret data or …
Q 38 September 2015: The PCI PIN Security Requirements stipulate that any cryptographic device used in connection with the acquisition of PIN data that is removed from service must have all keys stored within the device destroyed that have been used (or potentially could be) for any cryptographic purpose. If necessary to comply with the above, the device must be physically destroyed so that it cannot be placed into service again or allow the disclosure of any secret data or …
Removed
p. 21
Q 17 September 2020: PIN Security Requirement 18-3 requires the implementation of key blocks. Interoperable methods include those defined in ASC X9 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 for peer review:
• 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: o Changing or replacing any bit(s) in the attributes or encrypted key o Interchanging any bits of …
• 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: o Changing or replacing any bit(s) in the attributes or encrypted key o Interchanging any bits of …
Modified
p. 21 → 13
• Encryption by a key of equal or greater strength that is itself zeroized, i.e., only cryptograms of the protected keys are recoverable.
• Encryption by a key of equal or greater strength that is itself zeroized⎯i.e., only cryptograms of the protected keys are recoverable.
Removed
p. 22
• new devices must support AES).
Modified
p. 22 → 14
Q 18 September 2020: Devices must support the ANSI TR-31 key-derivation methodology for TDES keys, and for AES keys must support either the TR-31 methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and said review is publicly available as described. What characteristics enforced in TR-31 and ISO 20038 must be considered in determining equivalence? A “Equivalency” must be demonstrated in the context of security proofs. The equivalent …
Q 39 November (update) 2022: Devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and said review is publicly available as described. What characteristics enforced in ANSI X9.143 and ISO 20038 must be considered in determining equivalence? A “Equivalency” must be demonstrated in the context of security …
Modified
p. 22 → 14
a) It must prevent the loading of PIN, MAC, and/or Data keys - or any keys used to manage these within the key hierarchy - from being used for another purpose. IPEK, KEKs, and derivation keys must be uniquely identified where supported. b) It must prevent the determination of key length for variable length keys. c) It must ensure that the key can only be used for a specific algorithm (such as TDES or AES, but not both). d) It …
a) It must prevent the loading of PIN, MAC, and/or Data keys - or any keys used to manage these within the key hierarchy - from being used for another purpose. IPEK, KEKs, and derivation keys must be uniquely identified where supported. b) It must prevent the determination of key length for variable length keys. c) It must ensure that the key can only be used for a specific algorithm (such as TDES or AES, but not both). d) It …
Modified
p. 22 → 14
a) A key version number that prevents the use of older or expired keys.
Modified
p. 22 → 14
b) Support for key “direction” (uni-directional keys) so that a MAC key may be identified as “verify only,” or a data key as “encrypt only.”
Modified
p. 22 → 14
c) Support for key purposes other than PIN, MAC, and Data.
Modified
p. 22 → 14
d) Support for both TDES and AES (where devices implementing the key blocks only support one of these algorithms⎯transitional only⎯new devices must support AES).
Modified
p. 22 → 14
e) To implement confidentiality controls over any key metadata other than the key length.
Modified
p. 22 → 14
f) Support for asymmetric algorithms.
Removed
p. 23
Q 2 September 2015: Can a device use a key-encrypting key to encrypt or decrypt key-tag information along with a key? A Yes, associated key-tag information such as the algorithm, key expiration, usage, or key MAC may be encrypted or decrypted along with the key using a key-encrypting key. The key and its tag are bound together using a chaining mode of encipherment as defined in IS0 10116.
Modified
p. 23 → 15
Q 19 September 2020: HSMs are required to support key blocks using the ASC X9 TR-31 key- derivation methodology for TDES keys, and for AES keys must support either the TR-31 methodology and/or the ISO 20038 methodology. TR-31 and ISO 20038 are methods to package keys (the key blocks) for conveyance or storage, but they use symmetric mechanisms for that and for key conveyance require a symmetric key exchange key that is pre-shared for use as the key block protection …
Q 40 November (update) 2022: HSMs are required to support key blocks using the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology and/or the ISO 20038 methodology. ANSI X9.143 and ISO 20038 are methods to package keys (the key blocks) for conveyance or storage, but they use symmetric mechanisms for that and for key conveyance require a symmetric key- exchange key that is pre-shared for use as the key block …
Modified
p. 23 → 15
• The Key Block Binding Method However, TR-34 uses asymmetric methods for the Key Block Binding Method, instead of the symmetric methods used in TR-31 or ISO 20038 which require that a symmetric key was previously exchanged between the POI device and the KDH.
• The Key Block Binding Method However, TR-34 uses asymmetric methods for the Key Block Binding Method, instead of the symmetric methods used in ANSI X9.143 or ISO 20038 which require that a symmetric key was previously exchanged between the POI device and the KDH.
Modified
p. 23 → 15
Q 20 December 2020: Devices must support the ANSI TR-31 key-derivation methodology for TDES keys, and for AES keys must support either the TR-31 methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and said review is publicly available for peer review. What constitutes publicly available? A “Publicly available" means posted in a forum or otherwise published such that it is available for peer review for the time …
Q 41 November (update) 2022: Devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and said review is publicly available for peer review. What constitutes publicly available? A “Publicly available" means posted in a forum or otherwise published such that it is available for peer review for …
Modified
p. 23 → 16
Q 1 September 2015: Is it acceptable for a PIN-encryption key to be used as a key-encrypting key, or for a key-encrypting key to be used as a PIN-encrypting key? A No. A key must be used for one purpose only as mandated by ANSI X9.24 and ISO 11568-3.
Q 46 September 2015: Is it acceptable for a PIN-encryption key to be used as a key-encrypting key, or for a key-encrypting key to be used as a PIN-encrypting key? A No. A key must be used for one purpose only as mandated by ANSI X9.24 and ISO 11568-3.
Removed
p. 24
Q 1 May 2019: ISO 9564-1 stipulates various criteria for translations between PIN block formats. The HSM Derived Test Requirements illustrates in TB15.3 restrictions on translations between PIN block formats that are applicable when the HSM does not enforce unique-key-per-transaction encryption for the resulting PIN block. Do any other restrictions apply? A Yes. The following restrictions on translations between PIN block formats must be enforced regardless of the key management methodology used:
• Only ISO formats 0, 3 and 4 shall be supported in calculating values used for PIN verification that are derived from the PIN and PAN, e.g. PIN offsets and PIN verification values (PVV).
• For ISO formats 0 and 3, when calculating values derived from the PIN and PAN, if the portion of the account number enciphered in the input encrypted PIN block does not agree with the input PAN, the calculated value shall not be returned except in …
• Only ISO formats 0, 3 and 4 shall be supported in calculating values used for PIN verification that are derived from the PIN and PAN, e.g. PIN offsets and PIN verification values (PVV).
• For ISO formats 0 and 3, when calculating values derived from the PIN and PAN, if the portion of the account number enciphered in the input encrypted PIN block does not agree with the input PAN, the calculated value shall not be returned except in …
Modified
p. 24 → 18
Q 1 September 2015: The operating system of the device must contain only necessary components and must be configured securely and run with least privilege. What is considered an “operating system” for PCI purposes? A In the scope of PCI PTS, any underlying software providing services for code running in the device is considered part of the operating system. Examples of such services include: system initialization and boot, hardware abstraction layers, memory management, multitasking, synchronization primitives, file systems, device drivers …
Q 50 September 2015: The operating system of the device must contain only necessary components and must be configured securely and run with least privilege. What is considered an “operating system” for PCI purposes? A In the scope of PCI PTS, any underlying software providing services for code running in the device is considered part of the operating system. Examples of such services include: system initialization and boot, hardware abstraction layers, memory management, multitasking, synchronization primitives, file systems, device drivers, …
Removed
p. 25
Q 1 ISO 9564 and requirement C1 require that the HSM’s security policy enforce the prohibition of the translation of PIN block formats from ISO format 0 to IS0 format 1. Are there any circumstances where it is permitted that HSMs allow the translation of PIN blocks from ISO format 0 to ISO format 1? A Yes, if a unique session key is used for every ISO format 1 PIN block, and the key uniqueness is guaranteed by the functionality of the HSM and is not reliant upon APIs exercised by the host application.
Modified
p. 25 → 18
Q 1 February 2020: Can an HSM operating in PCI-mode support known weak cryptographic algorithms/key sizes not otherwise allowable when used for EMV card personalization? Yes, when used for EMV card personalization an HSM when operating in PCI mode may support:
Q 51 February 2020: Can an HSM operating in PCI-mode support known weak cryptographic algorithms/key sizes not otherwise allowable when used for EMV card personalization? Yes. When used for EMV card personalization an HSM when operating in PCI mode may support:
Modified
p. 25 → 18
All other usage must meet the requirements for minimum key sizes and parameters for algorithm(s) that are stipulated in Appendix D of the PCI HSM Derived Test Requirements, the usage of SHA-2 or higher for a hashing algorithm and only recognized format-preserving Feistel- based Encryption Modes (FFX), if FPE is supported HSM Requirement C1
All other usage must meet the requirements for minimum key sizes and parameters for algorithm(s) that are stipulated in Appendix D of the PCI HSM Derived Test Requirements, the usage of SHA-2 or higher for a hashing algorithm and only recognized format-preserving Feistel- based Encryption Modes (FFX), if FPE is supported.
Modified
p. 25 → 19
Q 2 September (update) 2015: Are HSMs allowed to support non-ISO PIN block formats and non-ISO algorithms? A Yes, however, the HSM must provide functionality to enforce a policy that meets the following:
Q 53 September (update) 2015: Are HSMs allowed to support non-ISO PIN block formats and non-ISO algorithms? A Yes, however, the HSM must provide functionality to enforce a policy that meets B14:
• ISO formats 0, 1, 2, 3 and 4 cannot be translated into any non-ISO format.
• ISO formats 0, 1, 2, 3 and 4 cannot be translated into any non-ISO format.
Removed
p. 26
Q 4 September 2015: Is there any impact on the device’s approval if the laboratory evaluated security policy is changed by the vendor? A The content of the security policy is part of the evaluation of a device by the laboratory and is an integral input upon which the approval of a device is based. Deployers rely on the security policy in order to ensure that they do not breach the conditions of a device's approval. Any change to the security policy which impacts on the security requirements of the device must be evaluated in order for the device to remain approved. Additionally, any change to the functionality offered by the device impacting information required to be contained in the security policy must be reflected in an update to the listed security policy document. Depending on the nature of the changes, this may be reflected in updates (e.g., appendices) to …
Modified
p. 26 → 19
Q 3 May (update) 2018: Is the device allowed to share PCI relevant keys and passwords/authentication codes between PCI approved mode of operation and non-PCI approved mode of operation? A No. The device must either enforce separation of all PCI relevant keys and passwords/authentication codes between the two modes or the device must zeroize all PCI relevant keys and passwords/authentication codes when switching between modes except as follows. If the device includes an internally generated hardware key, for example inside …
Q 54 May (update) 2018: Is the device allowed to share PCI relevant keys and passwords/authentication codes between PCI approved mode of operation and non-PCI approved mode of operation? A No. The device must either enforce separation of all PCI relevant keys and passwords/authentication codes between the two modes or the device must zeroize all PCI relevant keys and passwords/authentication codes when switching between modes except as follows. If the device includes an internally generated hardware key, for example inside …
Modified
p. 26 → 20
Q 5 May 2018: The PCI PTS Lab Requirements prohibit a PTS lab from creating any vendor- documentation. Are there any scenarios where a PTS lab may assist a vendor in creating documentation? A In some cases, a PTS vendor may revise a Security Policy for grammar, formatting, or spelling edits for a device under evaluation. which requires grammar, formatting, or spelling edits. to be submitted to PCI to place on the portal. In this case, the PTS lab performing …
Q 56 May 2018: The PCI PTS Lab Requirements prohibit a PTS lab from creating any vendor documentation. Are there any scenarios where a PTS lab may assist a vendor in creating documentation? A In some cases. A PTS vendor may revise a Security Policy for grammar, formatting, or spelling edits for a device under evaluation which requires those edits to be submitted to PCI to place on the portal. In this case, the PTS lab performing the evaluation may …
Modified
p. 26 → 20
• A track-changed/redlined version of the edited Security Policy, showing the original text created by the vendor as well as the updated text
• A change-tracked/redlined version of the edited Security Policy, showing the original text created by the vendor as well as the updated text.