Document Diff - PCI Watch

Added p. 3

• The HSM components that were evaluated;

• The security level of the evaluation;

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.

• 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.

Added p. 12

• The device must have its own evaluation and product listing

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 as evidence in a manner similar to the inclusion of pictures of hardware components as evidence in meeting physical requirements.

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 …

Added p. 20

• Specific menu commands to zeroize stored keys

• Inducement of a tamper event to zeroize those keys

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 …

Added 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 …

Added p. 25

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:

• RSA keys less than 2048 This must result in a distinct firmware version and any other usage beyond card personalization invalidates the approval.

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

• ISO formats 0, 1, 2, 3 and 4 cannot be translated into any non-ISO format.

• Format 2 PIN blocks shall be constrained to offline PIN verification and PIN change operations in ICC environments …

Added p. 26

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 the evaluation This may be done to assist the vendor in by editing the Security Policy to creating a document sufficient to be submitted to PCI. In this case, the PTS lab will provide the following as part of the evaluation report submission:

• 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 clean copy of the …

Modified p. 1

Payment Card Industry (PCI) PTS HSM Security Requirements Technical FAQs for use with Version ~~2.0~~

Payment Card Industry (PCI) PTS HSM Security Requirements Technical FAQs for use with Version 3

Modified p. 3

~~ 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.

• That the existing FIPS certification covers the full HSM functionality for all the related requirements.

Modified p. 4

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 …

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 …

Modified p. 4

Q 7 ~~September 2015:~~ What is the definition of “Secret Information?” A “Secret information” is any cryptographic keys or ~~passwords~~ that the device relies on to maintain security characteristics governed by PCI requirements.

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.

Modified p. 4

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 ~~A7.~~ 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 do not need to be erased.

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 do not need to be erased.

Modified 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 …~~

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

Modified p. 9

 It cannot adversely affect the security features of the product that are relevant to the PCI HSM approval.

• It cannot adversely affect the security features of the product that are relevant to the PCI HSM approval.

Modified p. 9

 It cannot modify any of the cryptographic functionality of the HSM or introduce new primitive cryptographic functionality. However, new composite functionality that builds on existing primitives is permitted.

• It cannot modify any of the cryptographic functionality of the HSM or introduce new primitive cryptographic functionality. However, new composite functionality that builds on existing primitives is permitted.

Modified p. 9

 The application is strongly authenticated to the HSM secure controller by digital signature.

• The application is strongly authenticated to the HSM secure controller by digital signature.

Modified p. 9

 The application can only work on the keys it alone manages and cannot affect or see any other keys.

• The application can only work on the keys it alone manages and cannot affect or see any other keys.

Modified p. 11

 If firmware blocks have independent version numbers then the version number display should include the version number of each firmware block.

• If firmware blocks have independent version numbers then the version number display should include the version number of each firmware block.

Modified p. 11

 If a single version number is used, then a documented process must be used to ensure the single version number is updated whenever changes are made to any of the firmware blocks in the device.

• If a single version number is used, then a documented process must be used to ensure the single version number is updated whenever changes are made to any of the firmware blocks in the device.

Modified p. 12

 The device must be fully capable of performing its intended functionality for the approval class it is evaluated against and can be sold as is as a fully functional product. This does not preclude the device requiring additional software such as payment applications, but the firmware of the device must meet all applicable requirements.

• The device must be fully capable of performing its intended functionality for the approval class it is evaluated against and can be sold as is as a fully functional product. This does not preclude the device requiring additional software such as payment applications, but the firmware of the device must meet all applicable requirements.

Modified p. 12

~~ The device must have its own evaluation and product listing ~~ Each of the 2nd vendors that use the device design and/or manufacture the device must have their own full evaluation (NOT A DELTA) and separate listing.

• Each of the 2nd vendors that use the device design and/or manufacture the device must have their own full evaluation (NOT A DELTA) and separate listing.

Modified p. 12

Devices that require additional hardware and/or firmware to operate (such as individual components) would not be allowed to be assessed. Those components must be integrated into a device design that meets the required PTS (HSM or POI) requirements.

• Devices that require additional hardware and/or firmware to operate (such as individual components) would not be allowed to be assessed. Those components must be integrated into a device design that meets the required PTS (HSM or POI) requirements.

Modified p. 13

Q 38 ~~May 2017:~~ 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 Environment …

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 …

Modified p. 13 → 14

Q 39 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 are not zeroized, then other mechanisms must …

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 keys are not zeroized, then other mechanisms must …

Modified p. 13 → 14

 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, or are not used for authentication.

Modified p. 13 → 14

Q 40 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 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 …

Removed p. 15

 Source code reviews targeting specific relevant security•critical functionalities  Vulnerability analysis; that includes gathering and considering evidence necessary to perform practical testing  Penetration testing to validate the robustness of the device to protect against feasible attacks by addressing known attack methods. For example (but not restricted to) fuzzing; using appropriate tools and techniques  Audits of relevant existing test evidence, which may be utilized where appropriate, by giving justifications for validity of evidence and test methodologies overall.

Modified p. 15

The laboratory shall determine the veracity of the material provided to determine the degree of reliance that may be placed upon the evidence, and where necessary, the laboratory shall extend the testing ~~HSM Requirement B3~~

The laboratory shall determine the veracity of the material provided to determine the degree of reliance that may be placed upon the evidence, and where necessary, the laboratory shall extend the testing

Modified p. 16 → 17

 The new code is cryptographically authenticated prior to execution.

• The new code is cryptographically authenticated prior to execution.

Modified p. 16 → 17

 If the new code fails authentication, the backup copy of code is cryptographically authenticated, and if the backup copy is successfully authenticated, the device boots from the backup copy and the backup is then used to overwrite the new code that failed authentication.

• If the new code fails authentication, the backup copy of code is cryptographically authenticated, and if the backup copy is successfully authenticated, the device boots from the backup copy and the backup is then used to overwrite the new code that failed authentication.

Modified p. 16 → 17

 If both firmware versions fail authentication, the device fails in a secure manner.

• If both firmware versions fail authentication, the device fails in a secure manner.

Modified p. 16 → 17

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 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.

Modified p. 20

Q 15 ~~September 2015:~~ Can secret keys or their components be used for other purposes such as ~~passwords~~ 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 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.

Modified p. 20

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 …

Modified p. 20 → 21

~~ Specific menu commands to zeroize stored keys  Inducement of a tamper event to zeroize those keys ~~ 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. 21

“The tester shall examine the security policy and other relevant documentation submitted by the vendor to verify that the security policy can be implemented to support the following configuration and that implementation is easily identifiable in reviewing system settings.

 ISO formats 0, 1, 2, 3 and 4 cannot be translated into any non-ISO format.  Format 2 PIN blocks shall be constrained to offline PIN verification and PIN change operations in ICC environments only.  Translation of PIN block formats that include the PAN, to PIN block formats that do not include the PAN, shall not be supported. In particular, ISO PIN-block formats 0, 3, and 4 are not translated into any PIN-block formats other than 0, 3, or 4  PIN-block translations from ISO format 0, 3, or 4 to any of ISO format 0, 3, or 4 do not support a change in PAN. This translation restriction is …

Modified p. 21 → 25

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 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:

Modified p. 22 → 26

Q 3 Is the device allowed to share PCI relevant keys and ~~passwords~~ 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~~ between the two modes or the device must zeroize all PCI relevant keys and ~~passwords~~ when switching between modes except as follows. If the device includes an internally generated hardware key, for example inside a secure microcontroller that can’t be …

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 …

Document Comparison

Content Changes