Document Comparison
PCI_HSM_DTRs_v3_2016_TOC.pdf
→
PCI_HSM_DTRs_v4.pdf
53% similar
140 → 183
Pages
53462 → 69980
Words
638
Content Changes
Content Changes
638 content changes. 226 administrative changes (dates, page numbers) hidden.
Added
p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Hardware Security Module (HSM) Modular Derived Test Requirements Version 4.0
Added
p. 6
As outlined in the testing requirements in this document, an HSM is a solution that provides for the security of cryptographic key storage and operation through a combination of hardware and software security features. An HSM may also be considered a secure cryptographic device (SCD) or cryptographic module under the definitions of ISO13491-1 or FIPS140-2 / FIPS140-3, although a solution meeting the requirements of those standards is not necessarily guaranteed to meet all applicable requirements within this document.
For the purposes of the requirements outlined herein, it is considered that any HSM Solution must, at a minimum, provide for the following fundamental security tenets. An HSM Solution must:
1. Protect the confidentiality of secret and private cryptographic keys.
2. Protect the integrity of public cryptographic keys.
3. Permit and facilitate the use of unique secret and private keys per device.
4. Protect and enforce the properties⎯such as purpose, algorithm, and length⎯of cryptographic keys.
5. Provide for …
For the purposes of the requirements outlined herein, it is considered that any HSM Solution must, at a minimum, provide for the following fundamental security tenets. An HSM Solution must:
1. Protect the confidentiality of secret and private cryptographic keys.
2. Protect the integrity of public cryptographic keys.
3. Permit and facilitate the use of unique secret and private keys per device.
4. Protect and enforce the properties⎯such as purpose, algorithm, and length⎯of cryptographic keys.
5. Provide for …
Added
p. 7
Encryption of working key values alone is not sufficient to provide for all of the security tenets required by an HSM, metadata about the key such as the algorithm the key is to be used with, the purpose of the key, and the length of the key, must also be secured along with the key value itself. This is achieved through “key wrapping,” which takes the key and key metadata and “wraps” that into a bundle that protects the confidentiality of the key along with the integrity and authenticity of its metadata.
Within these requirements, key wrapping is mandated for all key-storage methods where the key may be exposed outside of the HSM boundary. Keys stored within the HSM that are protected by the physical and logical security properties of the HSM itself may not require direct encryption during storage but will always require that their metadata is securely maintained.
An example …
Within these requirements, key wrapping is mandated for all key-storage methods where the key may be exposed outside of the HSM boundary. Keys stored within the HSM that are protected by the physical and logical security properties of the HSM itself may not require direct encryption during storage but will always require that their metadata is securely maintained.
An example …
Added
p. 8
One way to implement multi-user operation in a Cloud-based HSM Solution is to provide for two or more “virtual” HSMs within a single physical HSM instance, with each virtual HSM having its own tamper key, controlled by the HSM Solution Consumer. An example of such an implementation is illustrated below.
Figure 2: Example of Cloud-Based HSM Solution Another possible implementation is to disconnect the tamper key from the user master key, so that the HSM Solution stores the master keys of the HSM Solution Consumers in an encrypted form, the same way the working keys are themselves stored encrypted under the HSM Solution Consumer master key. In either implementation, the requirements for protecting the ownership and security of the user keys remains, and it is expected that any HSM tamper key⎯regardless of whether it is directly managed by the user⎯is unique per HSM and does not facilitate the exposure or unauthorized …
Figure 2: Example of Cloud-Based HSM Solution Another possible implementation is to disconnect the tamper key from the user master key, so that the HSM Solution stores the master keys of the HSM Solution Consumers in an encrypted form, the same way the working keys are themselves stored encrypted under the HSM Solution Consumer master key. In either implementation, the requirements for protecting the ownership and security of the user keys remains, and it is expected that any HSM tamper key⎯regardless of whether it is directly managed by the user⎯is unique per HSM and does not facilitate the exposure or unauthorized …
Added
p. 9
Figure 3: Example of HSM Solution using Separate Storage and User Master Keys It is not the intent of these security requirements to dictate or favor any particular HSM design or implementation. However, it is important when reading this document to be aware that while traditional implementations are not prevented, new implementations where common usage methods are altered may also be possible.
• Provides complete and accurate device details;
• Clear definitions of which hardware and firmware features of the overall device solution are within or without the scope of evaluation.
In support of some test steps, as directed by the test laboratory, the vendor must support the laboratory in various tasks (such as, but not restricted to code review, fuzzing interfacing, DPA, etc.) to avoid prohibitively lengthy test activities.
• At the beginning of the report, a list of all documentation, including DTR sections and Technical FAQs version used during the evaluation
• Throughout …
• Provides complete and accurate device details;
• Clear definitions of which hardware and firmware features of the overall device solution are within or without the scope of evaluation.
In support of some test steps, as directed by the test laboratory, the vendor must support the laboratory in various tasks (such as, but not restricted to code review, fuzzing interfacing, DPA, etc.) to avoid prohibitively lengthy test activities.
• At the beginning of the report, a list of all documentation, including DTR sections and Technical FAQs version used during the evaluation
• Throughout …
Added
p. 12
Where test evidence from prior evaluations is being reused, the similarities and differences between the prior and current devices must be detailed. Evidence of how the similarities were confirmed must also be presented.
Clear indications to the reader must be provided in any DTR where results have been reproduced from a prior report.
Re-use of test results for PTS HSM v4.0 evaluations is only allowed where the evidence is no older than two years•other v4.0 evaluation work may supplement work done in the current review.
Asset Flow Analysis The purpose of the Asset Flow Analysis is to describe in block-diagram form how assets travel within the device (both logically and physically) and are protected as they are processed and manipulated by it. The Asset Flow Analysis does not have to be provided as a single flow diagram. It can be made up from several flow diagrams so long as it is clear how …
Clear indications to the reader must be provided in any DTR where results have been reproduced from a prior report.
Re-use of test results for PTS HSM v4.0 evaluations is only allowed where the evidence is no older than two years•other v4.0 evaluation work may supplement work done in the current review.
Asset Flow Analysis The purpose of the Asset Flow Analysis is to describe in block-diagram form how assets travel within the device (both logically and physically) and are protected as they are processed and manipulated by it. The Asset Flow Analysis does not have to be provided as a single flow diagram. It can be made up from several flow diagrams so long as it is clear how …
Added
p. 13
It is important that asset flows and domains are correct and complete for each asset. The lab will validate and notify the vendor if discrepancies are discovered in the asset flows for corrective action. The lab will also validate whether any asset containers correctly protect the asset and that all required cryptographic keys are listed in the asset flow analysis.
TA1.1 The tester shall examine the Asset Flow Analysis to verify that it is complete and accurate and that it allows to unambiguously map all hardware components⎯including PCB tracks, passive components, plastics, etc.⎯to a security domain.
TA1.4 The tester shall describe how the device responds to a tamper-detection event, including any mechanisms for how a tamper event is indicated.
TA1.5 Deriving from the previous descriptions, the tester shall explain how the immediate and complete erasure of all sensitive information from the device results from tamper-detection events.
TA1.1 The tester shall examine the Asset Flow Analysis to verify that it is complete and accurate and that it allows to unambiguously map all hardware components⎯including PCB tracks, passive components, plastics, etc.⎯to a security domain.
TA1.4 The tester shall describe how the device responds to a tamper-detection event, including any mechanisms for how a tamper event is indicated.
TA1.5 Deriving from the previous descriptions, the tester shall explain how the immediate and complete erasure of all sensitive information from the device results from tamper-detection events.
Added
p. 18
TA1.25 The tester shall explain how the device is protected against attacks from all sides of the device, including the front, rear, top, and bottom of the device, and any other device sides.
TA1.31 The tester shall verify that no attack was able to be determined, including those outlined above, which could be performed for less than 26 points in total, less than 13 points during initial exploitation.
TA1.31 The tester shall verify that no attack was able to be determined, including those outlined above, which could be performed for less than 26 points in total, less than 13 points during initial exploitation.
Added
p. 25
Secret or private cryptographic keys that are never used to encrypt or decrypt data (e.g., keys, accounts, PINs), or are not used for authentication, do not need to be considered secret data and therefore are not subject to this requirement.
All physical and logical protections shall be evaluated and reported. Only protections that can be demonstrated as both enabled and efficacious shall be used to determine attack potential.
e) Describe why invasive and/or glitch attacks intending to change flags
•e.g., flipping a bit value enabling a defense
•are effectively obstructed.
• The steps needed in any penetration.
• Attacks involving some or all of attacks modeled elsewhere. For example, DTRs A1, A3 and A4 (but not restricted thereto) must be considered and included in this attack, if relevant.
All physical and logical protections shall be evaluated and reported. Only protections that can be demonstrated as both enabled and efficacious shall be used to determine attack potential.
e) Describe why invasive and/or glitch attacks intending to change flags
•e.g., flipping a bit value enabling a defense
•are effectively obstructed.
• The steps needed in any penetration.
• Attacks involving some or all of attacks modeled elsewhere. For example, DTRs A1, A3 and A4 (but not restricted thereto) must be considered and included in this attack, if relevant.
Added
p. 27
“Keys resident in the device or its components” means clear-text secret or private keys. If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key- encipherment algorithm(s) used as stipulated in Appendix D, they do not need to be considered. For purposes of this requirement, this includes transaction or other security-relevant keys that are only temporarily in the device and are not stored in the device.
The vendor shall provide mechanisms to facilitate side-channel testing. These mechanisms shall include at least the following: an interface, the ability to vary data and keys, and the ability to set trigger points (for testing purposes only and not for production units), allowing the evaluator to perform analysis with direct access to security-relevant processor(s).
Secret or private cryptographic keys that are never used to encrypt or decrypt data⎯e.g., keys, accounts, PINs⎯or are not used for authentication, do not need …
The vendor shall provide mechanisms to facilitate side-channel testing. These mechanisms shall include at least the following: an interface, the ability to vary data and keys, and the ability to set trigger points (for testing purposes only and not for production units), allowing the evaluator to perform analysis with direct access to security-relevant processor(s).
Secret or private cryptographic keys that are never used to encrypt or decrypt data⎯e.g., keys, accounts, PINs⎯or are not used for authentication, do not need …
Added
p. 28
As an accelerator and concentration point for cryptographic operations, HSMs are considered especially attractive targets for timing attacks, which may be performed remotely across a network regardless of mitigations implemented through the physical security of the deployed environment. HSMs must implement protections against timing attacks through use of constant time operations, blinding of processed values, etc. Mitigations that rely solely on inherent timing uncertainties of the implementation, such as network jitter, are not considered sufficient.
TA5.1 The tester shall identify and show in a table:
• A list of all security-related cryptographic keys (secret and private) that may be directly or indirectly attacked by side-channel analysis approaches. This list shall indicate whether the most applicable approach is statistical analysis of static keys with variable inputs or outputs, or other approaches such as, but not restricted to, timing analysis.
• Any specific key-management techniques that either prevent or obstruct side-channel analysis, such as unique …
TA5.1 The tester shall identify and show in a table:
• A list of all security-related cryptographic keys (secret and private) that may be directly or indirectly attacked by side-channel analysis approaches. This list shall indicate whether the most applicable approach is statistical analysis of static keys with variable inputs or outputs, or other approaches such as, but not restricted to, timing analysis.
• Any specific key-management techniques that either prevent or obstruct side-channel analysis, such as unique …
Added
p. 29
The tester shall describe any assistance provided by the vendor to ensure efficient side-channel testing•for example, command scripts, event triggers or access to the processor, etc.
TA5.5 The tester shall justify the methodologies used and findings, in accordance with Appendix E and with regard to published attacks. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible on this device.
Justifications of these to be reported shall include, but are not restricted to:
• Equipment used, and a summary of test parameters such as collection elapsed time and analysis elapsed time,
• Whether the attack can be feasible at any distance away from the processor,
• The number of sample recordings acquired,
• Sampling frequencies,
• Signal analysis / filtering techniques,
• Correlation function(s) used,
• How optimum quality data collection was achieved, etc.,
• How adequate key selection function coverage was applied.
• SPA/SEMA characterization,
• Noise-removal test results,
• …
TA5.5 The tester shall justify the methodologies used and findings, in accordance with Appendix E and with regard to published attacks. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible on this device.
Justifications of these to be reported shall include, but are not restricted to:
• Equipment used, and a summary of test parameters such as collection elapsed time and analysis elapsed time,
• Whether the attack can be feasible at any distance away from the processor,
• The number of sample recordings acquired,
• Sampling frequencies,
• Signal analysis / filtering techniques,
• Correlation function(s) used,
• How optimum quality data collection was achieved, etc.,
• How adequate key selection function coverage was applied.
• SPA/SEMA characterization,
• Noise-removal test results,
• …
Added
p. 30
The evaluation may rely upon appropriate evidence available from existing side-channel evaluation testing to replace some of the testing workload described here. Such evidence must be no older than the last prior major version (i.e., v3.x or other v4.x reviews may supplement work done in the current review) of the PCI HSM Security Requirements prior to the current evaluation’s submission. If leveraging separate evidence, it is necessary to justify that this evidence is fully in scope of DTR A5 security requirements.
TA5.6 The tester shall confirm what mitigations exist with respect to the exploitation of timing attacks against asymmetric cryptography, and justify (with reference to best practice in protecting cryptographic operations from timing attacks) why such mitigations are sufficient. Where it is not possible to confirm mitigations or no mitigations exist, the tester shall validate through testing that the HSM is not vulnerable to timing-based attacks.
Failure in accordance with FIPS 140-2/140-3 …
TA5.6 The tester shall confirm what mitigations exist with respect to the exploitation of timing attacks against asymmetric cryptography, and justify (with reference to best practice in protecting cryptographic operations from timing attacks) why such mitigations are sufficient. Where it is not possible to confirm mitigations or no mitigations exist, the tester shall validate through testing that the HSM is not vulnerable to timing-based attacks.
Failure in accordance with FIPS 140-2/140-3 …
Added
p. 33
A cryptographic module may perform other pre-operational or conditional self-tests in addition to the tests specified below.
If a cryptographic module includes two independent implementations of the same cryptographic algorithm:
b) Software/firmware integrity test An authenticity validation mechanism using an approved digital signature, MAC, or protected HASH value shall be applied to all software and firmware components within the module’s defined cryptographic boundary. If the calculated result is not successfully verified, the test fails and the module shall enter the error state. The digital signature technique may consist of a single encompassing signature or multiple disjointed signatures; failure of any disjointed signature shall cause the module to enter the error state. The private signing key shall reside outside the module.
The pre-operational software/firmware integrity test is not required for any software or firmware for any executable code stored in non-reconfigurable memory.
If a hardware module does not contain either software or firmware⎯for example where …
If a cryptographic module includes two independent implementations of the same cryptographic algorithm:
b) Software/firmware integrity test An authenticity validation mechanism using an approved digital signature, MAC, or protected HASH value shall be applied to all software and firmware components within the module’s defined cryptographic boundary. If the calculated result is not successfully verified, the test fails and the module shall enter the error state. The digital signature technique may consist of a single encompassing signature or multiple disjointed signatures; failure of any disjointed signature shall cause the module to enter the error state. The private signing key shall reside outside the module.
The pre-operational software/firmware integrity test is not required for any software or firmware for any executable code stored in non-reconfigurable memory.
If a hardware module does not contain either software or firmware⎯for example where …
Added
p. 37
- The reference authentication key shall be loaded independently in the module prior to the software or firmware loading; and
- The applied approved authentication technique shall be successfully verified or the software/firmware load test shall fail. Loaded software or firmware shall not be used if the software/firmware load test fails.
- If a cryptographic module maintains internal information that governs the bypass capability, the module shall verify the integrity of the governing information through an approved integrity technique immediately preceding modification of the governing information. Immediately following the modification, a new integrity value using the approved integrity technique shall be generated.
g) Critical functions tests
TB1.17 For both pre-operational and continuous/periodic tests the tester shall:
a) Verify the vendor documentation provides, for each error state
- The condition name, description of the state,
- The events that can produce the state, and
- The actions necessary to clear the state and resume normal operation.
b) Cause each error …
- The applied approved authentication technique shall be successfully verified or the software/firmware load test shall fail. Loaded software or firmware shall not be used if the software/firmware load test fails.
- If a cryptographic module maintains internal information that governs the bypass capability, the module shall verify the integrity of the governing information through an approved integrity technique immediately preceding modification of the governing information. Immediately following the modification, a new integrity value using the approved integrity technique shall be generated.
g) Critical functions tests
TB1.17 For both pre-operational and continuous/periodic tests the tester shall:
a) Verify the vendor documentation provides, for each error state
- The condition name, description of the state,
- The events that can produce the state, and
- The actions necessary to clear the state and resume normal operation.
b) Cause each error …
Added
p. 42
The update mechanism ensures security⎯i.e., integrity, mutual authentication, and protection against replay⎯by using an appropriate and declared security protocol when using a network connection.
The displayed firmware version number(s) must represent all firmware in the device that is currently executable.
• If firmware blocks have independent version numbers, the version number display should include the version number of each firmware block.
• If a single version number is used, 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.
For HSMs that implement virtualized environments or allow for multiple copies of firmware to be resident at one time, users must be able to obtain the version number(s) of the firmware they are currently executing. If additional firmware blocks or images are resident and may be executed at any time without user interaction or permission, the firmware version(s) …
The displayed firmware version number(s) must represent all firmware in the device that is currently executable.
• If firmware blocks have independent version numbers, the version number display should include the version number of each firmware block.
• If a single version number is used, 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.
For HSMs that implement virtualized environments or allow for multiple copies of firmware to be resident at one time, users must be able to obtain the version number(s) of the firmware they are currently executing. If additional firmware blocks or images are resident and may be executed at any time without user interaction or permission, the firmware version(s) …
Added
p. 58
Symmetric key components shall be combined either XOR’ing of full-length key components or implementation of a recognized secret-sharing scheme•for example, Shamir. Private key components shall be combined using a recognized secret-sharing scheme. Devices must implement unique secret and private keys for any function directly or indirectly related to PIN or account-data protection. The basic rule is that any private or secret key resident in the device that is directly or indirectly used for PIN protection whose compromise would lead to the compromise of the same key in another device must be unique per device. For example, this means not only the PIN-encryption key(s), but keys that are used to protect other keys, firmware-update and authentication keys, and display-prompt control keys. As stated in the requirement, this does not apply to public keys resident in the device.
Devices must support the ASC X9 TR 31 or ANSI X9.143 key-derivation methodology for TDES …
Devices must support the ASC X9 TR 31 or ANSI X9.143 key-derivation methodology for TDES …
Added
p. 59
• Changing or replacing any bit(s) in the attributes or encrypted key
• Changing or replacing any bit(s) in the attributes or encrypted key
Equivalent methods must be subject to an independent expert review, and said review must be publicly available:
• 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:
• Interchanging any bits of the protected key block with bits from another part of the block
• The independent expert must be qualified via a combination of education, training, and experience in cryptology to provide objective technical evaluations that are independent of any ties to vendors and special interests. “Independent expert” is further defined below.
• The PTS …
• Changing or replacing any bit(s) in the attributes or encrypted key
Equivalent methods must be subject to an independent expert review, and said review must be publicly available:
• 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:
• Interchanging any bits of the protected key block with bits from another part of the block
• The independent expert must be qualified via a combination of education, training, and experience in cryptology to provide objective technical evaluations that are independent of any ties to vendors and special interests. “Independent expert” is further defined below.
• The PTS …
Added
p. 63
TB10.16 The tester shall note whether the device generates any keys using an internal random number generator. The tester shall confirm through source-code review that these keys are generated using the same process validated under Requirement B8. This evaluation activity should be focused on relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Added
p. 66
Account-data encryption keys shall only be used to encrypt account data. Account-data encryption keys shall never be used to encrypt keys.
Note: The use of variants is not allowed for AES keys.
• Encryption of a key or PIN under a key that might itself be disclosed, and
• The transfer of a key from a high-security component to a lower-security component.
Note: If supporting online PIN processing:
• It may also support Fixed Key
2. TDES as described in ANSI X9.24 and ISO/IEC 18033-3 may also be supported using the following key-management techniques:
• It may also support Fixed Key If supporting online PIN entry, the device must support ISO PIN-block format 4 and may support any of the following PIN-block formats:
Note: The HSM API must ensure that the restrictions cannot be circumvented by chaining multiple calls, such as first translating a PIN block from ISO format 1 to ISO format 0 and the invoking a …
Note: The use of variants is not allowed for AES keys.
• Encryption of a key or PIN under a key that might itself be disclosed, and
• The transfer of a key from a high-security component to a lower-security component.
Note: If supporting online PIN processing:
• It may also support Fixed Key
2. TDES as described in ANSI X9.24 and ISO/IEC 18033-3 may also be supported using the following key-management techniques:
• It may also support Fixed Key If supporting online PIN entry, the device must support ISO PIN-block format 4 and may support any of the following PIN-block formats:
Note: The HSM API must ensure that the restrictions cannot be circumvented by chaining multiple calls, such as first translating a PIN block from ISO format 1 to ISO format 0 and the invoking a …
Added
p. 71
• No integrity checks shall be performed on the PIN digits themselves. If integrity checks are performed on the deciphered PIN field, they shall only be performed on the first byte of that field (control field and PIN length field) and the fill digits.
e) The application can only work on the keys it alone manages and cannot affect or see any other keys. f) Applications must not share process spaces with each other or with the firmware.
See Appendix F, “Domain-Based Asset Flow Analysis.” A mechanism must exist to display or retrieve the application version upon request.
e) The application can only work on the keys it alone manages and cannot affect or see any other keys. f) Applications must not share process spaces with each other or with the firmware.
See Appendix F, “Domain-Based Asset Flow Analysis.” A mechanism must exist to display or retrieve the application version upon request.
Added
p. 76
The intended operation is considered as the functionality relevant to B2 and is representative of the functionality provided by the device. For multi-application devices, the intended operation furthermore includes the operation of applications without security impacts.
TB17.2 The tester shall verify that the security policy enforced by the device does not allow unauthorized or unnecessary functions.
TB17.2 The tester shall verify that the security policy enforced by the device does not allow unauthorized or unnecessary functions.
Added
p. 77
The tester shall compare this configuration with the supplied documentation and note whether they agree or have differences. If differences are detected, it is necessary to address why these occur with regard to compliance to this requirement.
Added
p. 80
TC1.1 The tester shall check that a security policy exists and is well-formatted, accurate, consistent, complete, and does not contain ambiguous or misleading information. Tester shall verify any URL in the security policy as being valid and usable.
TC1.14 The tester shall examine the security policy to verify that it identifies all self-tests that the module performs, procedures that an operator may need to initiate any self-tests, and the conditions under which each self-test is executed (e.g., power up, periodic, conditional, on operator demand). This includes the time period and any conditions that may result in the interruption of the module’s operations to perform the pre-operational or conditional self-tests. For example, if the module is performing mission-critical services that cannot be interrupted and the time period is passed for the initiation of the pre-conditional self-tests, the self-tests may be deferred to the next such time period. However, at all times the …
TC1.14 The tester shall examine the security policy to verify that it identifies all self-tests that the module performs, procedures that an operator may need to initiate any self-tests, and the conditions under which each self-test is executed (e.g., power up, periodic, conditional, on operator demand). This includes the time period and any conditions that may result in the interruption of the module’s operations to perform the pre-operational or conditional self-tests. For example, if the module is performing mission-critical services that cannot be interrupted and the time period is passed for the initiation of the pre-conditional self-tests, the self-tests may be deferred to the next such time period. However, at all times the …
Added
p. 90
TE2.1 The tester shall examine the supporting documentation submitted by the device vendor. The documents should be representative of a configuration control process that can be audited. These documents shall be referenced. The documentation could include firmware revision lists with updates documented, current operator manuals, and other materials that show clear evidence that the device is operated in a secure manner TE2.2 The tester shall examine details provided by the vendor that the documented process explicitly addresses how configuration settings are changed, including the changing of the device’s passwords or other authentication data.
Added
p. 94
TF3.1 The tester shall examine and cite any additional documentation (e.g., design documentation, key-management specification) submitted by the vendor that describes the MAC generation and verification.
Added
p. 100
TH1.1 The tester shall examine and cite any relevant documentation
•such as a user guide, operator manual, key-management guidance documents)
•submitted by the vendor .TH1.2 The tester shall verify whether the asymmetric private and public key pair is generated within the digital signature device.
•such as a user guide, operator manual, key-management guidance documents)
•submitted by the vendor .TH1.2 The tester shall verify whether the asymmetric private and public key pair is generated within the digital signature device.
Added
p. 102
TI1.1 The tester shall examine the Asset Flow Analysis of the HSM Solution, as provided by the HSM Solution Provider, and confirm that it details the flow, storage, and processing areas for all secret and private cryptographic keys used in the solution. If the HSM processing element is previously approved to PCI HSM requirements, the tester shall quote the approval number and confirm that the hardware and firmware versions remain the same.
TI1.2 The tester shall confirm the HSM processing element(s) are clearly defined within the solution, referencing the Asset Flow Analysis to show this is included correctly.
TI1.3 The tester shall confirm through their understanding of the HSM processing element(s) reviewed during testing that the Asset Flow Analysis is correct and complete, providing an accurate picture of how secret and private keys and key components are managed by the system.
TI1.4 The tester shall confirm that the HSM processing element definition includes …
TI1.2 The tester shall confirm the HSM processing element(s) are clearly defined within the solution, referencing the Asset Flow Analysis to show this is included correctly.
TI1.3 The tester shall confirm through their understanding of the HSM processing element(s) reviewed during testing that the Asset Flow Analysis is correct and complete, providing an accurate picture of how secret and private keys and key components are managed by the system.
TI1.4 The tester shall confirm that the HSM processing element definition includes …
Added
p. 103
• Be installed and operated in an environment meeting at least the security requirements of a controlled environment, or
• Protect the stored and processed sensitive data to an attack potential of at least 26 per HSM virtualization system for identification and initial exploitation, with a minimum of 13 for initial exploitation, as defined in Appendix A.
Sensitive data in the context of this requirement is considered to be any data, firmware, scripts, or other values (such as passwords) that may be relied upon to meet the requirements of this standard. Examples include the code/firmware of the virtualization system itself, cryptographic keys used to terminate or authenticate interaction with HSM Solution Providers, secure channels, etc.
TI2.1 The tester shall examine the Asset Flow Analysis of the HSM Solution, as provided by the HSM Solution Provider, and confirm that it details the flow, storage, and processing areas for all aspects of the solution required …
• Protect the stored and processed sensitive data to an attack potential of at least 26 per HSM virtualization system for identification and initial exploitation, with a minimum of 13 for initial exploitation, as defined in Appendix A.
Sensitive data in the context of this requirement is considered to be any data, firmware, scripts, or other values (such as passwords) that may be relied upon to meet the requirements of this standard. Examples include the code/firmware of the virtualization system itself, cryptographic keys used to terminate or authenticate interaction with HSM Solution Providers, secure channels, etc.
TI2.1 The tester shall examine the Asset Flow Analysis of the HSM Solution, as provided by the HSM Solution Provider, and confirm that it details the flow, storage, and processing areas for all aspects of the solution required …
Added
p. 104
A secure channel must exist to ensure the security of the use of cryptographic keys, commands, and other interactions with the HSM Solution. This secure channel may be implemented through physical means, such as within a tamper-responsive boundary, or by logical means such as a cryptographically secure connection using a protocol such as TLS. Requirement K1 covers the testing that must be performed to validate the secure channels implemented in the solution.
This requirement is for situations where the HSM virtualization system may act as a switch or broker of commands from the HSM Solution Consumer, routing these to HSM processing elements based on capacity or other factors. In such a case, the logical secure channel to the HSM Solution Consumer may terminate at the HSM virtualization system, and therefore the HSM virtualization system will be responsible for securing the onward authenticity of those connections (through the establishment or use of …
This requirement is for situations where the HSM virtualization system may act as a switch or broker of commands from the HSM Solution Consumer, routing these to HSM processing elements based on capacity or other factors. In such a case, the logical secure channel to the HSM Solution Consumer may terminate at the HSM virtualization system, and therefore the HSM virtualization system will be responsible for securing the onward authenticity of those connections (through the establishment or use of …
Added
p. 105
This requirement is designed for solutions where the HSM virtualization system and HSM processing element are contained on the physical execution environment, such as when a single processor is used to implement both systems. If the HSM virtualization system is contained within the same physical enclosure but not executed on the same processor, the majority of the testing in this requirement does not apply. However, in all cases a response is required detailing how the HSM virtualization system and HSM processing element are implemented such that they are kept physically separate.
TI4.1 The tester shall detail how the HSM virtualization system(s) and the HSM processing element(s) are implemented within the solution. This must clearly show where code is executed, memory locations where sensitive data is maintained, and the security boundaries of each system. Where the HSM virtualization system can be clearly shown to execute in a separate physical execution environment, such …
TI4.1 The tester shall detail how the HSM virtualization system(s) and the HSM processing element(s) are implemented within the solution. This must clearly show where code is executed, memory locations where sensitive data is maintained, and the security boundaries of each system. Where the HSM virtualization system can be clearly shown to execute in a separate physical execution environment, such …
Added
p. 106
Strong isolation between the cryptographic keys of different HSM Solution Consumers and non- firmware code is required to help mitigate cache and execution path side-channel attacks in HSM Solution environments. Such attacks may occur even if the HSM processing element is only able to execute signed firmware through exploitation of vulnerabilities that allow for local execution on those processing elements.
Any code, scripts, or customized functions not included in the scope of the PCI HSM evaluation must be implemented outside the scope of approval for the HSM processing element and must not directly manipulate or handle clear-text cryptographic keys. Only chaining or use of existing HSM commands is permitted. Commands that require custom cryptographic processing must be implemented through updates to the firmware of the HSM only. Chaining of existing HSM commands into a single atomic command must be performed externally to the HSM processing element or implemented in firmware approved …
Any code, scripts, or customized functions not included in the scope of the PCI HSM evaluation must be implemented outside the scope of approval for the HSM processing element and must not directly manipulate or handle clear-text cryptographic keys. Only chaining or use of existing HSM commands is permitted. Commands that require custom cryptographic processing must be implemented through updates to the firmware of the HSM only. Chaining of existing HSM commands into a single atomic command must be performed externally to the HSM processing element or implemented in firmware approved …
Added
p. 107
“Key export,” in the context of this requirement, refers to the output of clear-text secret and private keys, clear-text key components for such keys, or encrypted values under a key that is not in the direct control of the user and/or is not an operational key that is known only to the HSM, such as an HSM processing element storage key. Key export includes transmission of keys between HSM processing elements.
“Key import” refers to provisioning or loading new keys owned by the HSM Solution Consumer into the HSM Solution. This includes those transferred during provisioning processes.
“Keys of the HSM Solution Consumer” in the context of this requirement includes both working keys and HSM Solution Consumer master keys (which may be separate from the tamper keys for any individual HSM processing element).
This requirement covers all operations that may be used to import, export, or otherwise convey HSM Solution Consumer keys. This …
“Key import” refers to provisioning or loading new keys owned by the HSM Solution Consumer into the HSM Solution. This includes those transferred during provisioning processes.
“Keys of the HSM Solution Consumer” in the context of this requirement includes both working keys and HSM Solution Consumer master keys (which may be separate from the tamper keys for any individual HSM processing element).
This requirement covers all operations that may be used to import, export, or otherwise convey HSM Solution Consumer keys. This …
Added
p. 108
TJ2.1 The tester shall detail the provisioning process involved in assigning HSM Solution Consumer keys to a specific HSM processing element. This must include all provisioning methods supported, including both direct provisioning by the customer, as well as any automated provisioning processes implemented between individual HSM processing elements.
TJ2.2 The tester shall detail each secure channel that can be implemented as a connection to or from the HSM processing element. This must include both direct connections from HSM Solution Consumers, as well as any switched or re-routed secure channels passed through another part of the HSM Solution.
TJ2.3 The tester shall document how authentication is implemented for each of the provisioning and secure channel establishment methods listed above. In each case the tester shall confirm that it implements cryptographically sound methods resistant to man-in-the-middle, pre-play, and re- play attacks.
TJ2.4 The tester shall confirm that all cryptography relied upon for compliance to this …
TJ2.2 The tester shall detail each secure channel that can be implemented as a connection to or from the HSM processing element. This must include both direct connections from HSM Solution Consumers, as well as any switched or re-routed secure channels passed through another part of the HSM Solution.
TJ2.3 The tester shall document how authentication is implemented for each of the provisioning and secure channel establishment methods listed above. In each case the tester shall confirm that it implements cryptographically sound methods resistant to man-in-the-middle, pre-play, and re- play attacks.
TJ2.4 The tester shall confirm that all cryptography relied upon for compliance to this …
Added
p. 109
TJ3.1 The tester shall detail the commands exposed by the HSM processing element and note which of these allow for operations to be performed with cryptographic keys owned by the HSM Solution Consumer.
TJ3.2 For each of these commands, the tester shall confirm there are cryptographic methods implemented to authenticate the request from the key owner. The tester shall note how these methods authenticate the HSM Solution Consumer as the owner of the keys being operated upon.
TJ3.3 The tester shall verify that these methods are resistant to man-in-the-middle, pre-play, and re- play attacks.
TJ3.4 Where a secure channel is relied upon for some aspect of the authentication process, or otherwise some form of compliance to this requirement, the tester shall confirm that the secure channel implements mutual authentication.
TJ3.5 The tester shall confirm that all cryptography relied upon for compliance to this requirement is detailed in the HSM key table and enforces compliant …
TJ3.2 For each of these commands, the tester shall confirm there are cryptographic methods implemented to authenticate the request from the key owner. The tester shall note how these methods authenticate the HSM Solution Consumer as the owner of the keys being operated upon.
TJ3.3 The tester shall verify that these methods are resistant to man-in-the-middle, pre-play, and re- play attacks.
TJ3.4 Where a secure channel is relied upon for some aspect of the authentication process, or otherwise some form of compliance to this requirement, the tester shall confirm that the secure channel implements mutual authentication.
TJ3.5 The tester shall confirm that all cryptography relied upon for compliance to this requirement is detailed in the HSM key table and enforces compliant …
Added
p. 110
This requirement does not include keys that are used as part of a secure channel that does not terminate onto the HSM processing element itself.
Clear-text PAN data must be processed entirely within the HSM processing element, or the Cloud HSM environment in which the PAN data is exposed in clear text must meet the requirements of PCI DSS. If the HSM Solution is not intended to handle clear-text PAN data, this must be explicitly noted in the security policy, including informing the HSM Solution Consumer that any use of PANs in this system may impact their PCI DSS compliance.
The term “PAN” is used in this requirement to cover any situation where a PAN may be involved, including use of PANs in PIN blocks, within track or track-equivalent data, etc. Solutions aiming to remove the use of the PAN through PAN tokens or similar must make this clear in the security …
Clear-text PAN data must be processed entirely within the HSM processing element, or the Cloud HSM environment in which the PAN data is exposed in clear text must meet the requirements of PCI DSS. If the HSM Solution is not intended to handle clear-text PAN data, this must be explicitly noted in the security policy, including informing the HSM Solution Consumer that any use of PANs in this system may impact their PCI DSS compliance.
The term “PAN” is used in this requirement to cover any situation where a PAN may be involved, including use of PANs in PIN blocks, within track or track-equivalent data, etc. Solutions aiming to remove the use of the PAN through PAN tokens or similar must make this clear in the security …
Added
p. 111
There may be more commands exposed to the HSM Solution Consumer other than those that are actually implemented by the HSM processing element. All key-management operations must be implemented by and within the HSM processing element, not by any other part of the overall HSM Solution. Key-management operations may include use of public keys or defined operations on data within encrypted structures; therefore, this requirement remains distinct from the requirement that all secret/private keys are never exposed outside of an HSM processing element.
TJ5.1 The tester shall review the API provided to the customer and reference how commands are implemented and managed between the HSM virtualization system and HSM processing element.
TJ5.2 The tester shall confirm that all key-management operations are performed within the tamper- responsive boundary of the HSM processing element. This must include all operations using public keys, as well as defined operations manipulating encrypted content which may contain sensitive …
TJ5.1 The tester shall review the API provided to the customer and reference how commands are implemented and managed between the HSM virtualization system and HSM processing element.
TJ5.2 The tester shall confirm that all key-management operations are performed within the tamper- responsive boundary of the HSM processing element. This must include all operations using public keys, as well as defined operations manipulating encrypted content which may contain sensitive …
Added
p. 112
This requirement goes beyond what is normally required in HSM or POI systems, due to the expectation for shared environments where cryptographic keys for different HSM Solution Consumers may co-exist. It is expected that validation of this requirement will require a significant burden of evidence and testing for any system where the cryptographic keys of an HSM Solution Customer are exposed in clear text within a complex operating system or code where memory allocation and clearing is abstracted.
Examples of ways this requirement could be met are:
• The HSM processing element is an ASIC (or interfaces to such) that has RTL level functions to manage clear-text keys (decrypt with a tamper key, perform crypto, clear keys before loading other keys).
• The HSM processing element does “touch” clear-text keys with high-level code but memory areas are provably cleared⎯e.g., through a reset process on that system⎯before loading other customer keys.
TJ6.1 The tester shall …
Examples of ways this requirement could be met are:
• The HSM processing element is an ASIC (or interfaces to such) that has RTL level functions to manage clear-text keys (decrypt with a tamper key, perform crypto, clear keys before loading other keys).
• The HSM processing element does “touch” clear-text keys with high-level code but memory areas are provably cleared⎯e.g., through a reset process on that system⎯before loading other customer keys.
TJ6.1 The tester shall …
Added
p. 113
TJ6.6 The tester shall execute the buffer-clearing operation on the HSM processing element and confirm that it operates as expected.
Added
p. 114
Unique identification of the individual HSM processing elements is important in the case of a suspected compromise event, and to ensure correct revocation.
Firmware update logs must be authenticable by cryptographic methods using acceptable algorithms and key lengths. Best practice is to ensure that any firmware updates do not overwrite or update the HSM processing element or HSM virtualization system IDs⎯but in the cases where this does (or can) occur, the update log should ensure that there is a clear and verifiable chain of the ID values for any individual element or system. At no time should it be possible for an ID value to be lost or unable to be linked to an HSM element or system, nor for such an HSM element or system to have a period of time when its unique ID is not able to be determined.
TJ7.1 The tester shall review the API provided by the …
Firmware update logs must be authenticable by cryptographic methods using acceptable algorithms and key lengths. Best practice is to ensure that any firmware updates do not overwrite or update the HSM processing element or HSM virtualization system IDs⎯but in the cases where this does (or can) occur, the update log should ensure that there is a clear and verifiable chain of the ID values for any individual element or system. At no time should it be possible for an ID value to be lost or unable to be linked to an HSM element or system, nor for such an HSM element or system to have a period of time when its unique ID is not able to be determined.
TJ7.1 The tester shall review the API provided by the …
Added
p. 115
Due to the online and elastic nature of HSM Solutions, signing of firmware images must be tightly controlled, hence additional security controls are required beyond standard PCI HSM implementations.
Installation of older firmware is acceptable if the installation is confirmed to erase all cryptographic keys from the HSM processing element.
TJ8.1 The tester shall confirm that there is a documented process for signing firmware updates for HSM processing elements, and this process requires the approval of at least two authorized individuals.
TJ8.2 The tester shall confirm that the authorization of each individual includes a method that can uniquely identify the individual(s) signing the firmware, and that either passwords/authentication codes are at least ten characters or an equivalent strength; or cryptographic methods (such as using a cryptographic challenge/response token) are implemented for identification purposes.
TJ8.3 The tester shall detail the methods used to prevent “roll back” of a previous firmware image. Where it is noted …
Installation of older firmware is acceptable if the installation is confirmed to erase all cryptographic keys from the HSM processing element.
TJ8.1 The tester shall confirm that there is a documented process for signing firmware updates for HSM processing elements, and this process requires the approval of at least two authorized individuals.
TJ8.2 The tester shall confirm that the authorization of each individual includes a method that can uniquely identify the individual(s) signing the firmware, and that either passwords/authentication codes are at least ten characters or an equivalent strength; or cryptographic methods (such as using a cryptographic challenge/response token) are implemented for identification purposes.
TJ8.3 The tester shall detail the methods used to prevent “roll back” of a previous firmware image. Where it is noted …
Added
p. 116
A secure channel may be considered as provided through physical security by containment within the same tamper-responsive environment, use of a VPN-like cryptographic secure channel, or application/API level cryptographic controls that ensure the security of commands issued. Although independent secure channels are required for interface and routing of commands used by the HSM Solution Provider and HSM Solution Consumer, these may be provided by the same tamper- responsive functions, if two separate physical secure channels are used. Logical secure implementations must use different cryptographic keys for each channel.
It is not a requirement to have network connection to all components of the HSM Solution, but it is requiredthat the security of the connection from the HSM Solution Consumer or HSM Solution Provider can be validated across the whole path, including to the HSM processing element.
For any implementation, there must be either physical or logical separation of operational and administrative/management interfaces. Logical …
It is not a requirement to have network connection to all components of the HSM Solution, but it is requiredthat the security of the connection from the HSM Solution Consumer or HSM Solution Provider can be validated across the whole path, including to the HSM processing element.
For any implementation, there must be either physical or logical separation of operational and administrative/management interfaces. Logical …
Added
p. 117
HSM Solutions may have multiple levels of firmware, each with different access and administrative controls. The intent of this requirement is to ensure that configurations or alterations to the HSM Solution are approved by the HSM Solution Consumers prior to deployment. This includes ensuring that changes made by any one HSM Solution Consumer do not affect the operation of the solution by another HSM Solution Consumer.
If the HSM Solution Provider is able, by means such as a hardware or firmware change, to make changes to the solution that may affect its security or operation, those changes must be communicated to and accepted by the HSM Solution Consumer prior to being implemented.
TK2.1 The tester shall detail how firmware, configurations, and settings are managed on the HSM Solution for each HSM Solution Consumer instance. This may include multiple sets of firmware and settings for each aspect of the overall solution.
TK2.2 The tester …
If the HSM Solution Provider is able, by means such as a hardware or firmware change, to make changes to the solution that may affect its security or operation, those changes must be communicated to and accepted by the HSM Solution Consumer prior to being implemented.
TK2.1 The tester shall detail how firmware, configurations, and settings are managed on the HSM Solution for each HSM Solution Consumer instance. This may include multiple sets of firmware and settings for each aspect of the overall solution.
TK2.2 The tester …
Added
p. 118
Authentication for any changes that affect the compliance of the solution must be performed using cryptographic controls that are additional to any secure channels implemented.
The intent of this requirement is to prevent one HSM Solution Consumer from changing a configuration that then affects the configurations or compliance status of other HSM Solution Consumers. Changes made by the entity operating the HSM Solution may affect many or even all HSM Solution Consumers, and although such changes should be communicated to HSM Solution Consumers prior to any potential impacts, these solution-level administration changes are out of scope of this requirement.
This requirement does not mandate that any HSM Solution must implement a “PCI mode,” nor how that mode is to function if it is implemented. HSM Solutions may allow for the HSM Solution Consumer to force all processing to operate in a way that is compliant to the PCI HSM requirements, tag-specific commands …
The intent of this requirement is to prevent one HSM Solution Consumer from changing a configuration that then affects the configurations or compliance status of other HSM Solution Consumers. Changes made by the entity operating the HSM Solution may affect many or even all HSM Solution Consumers, and although such changes should be communicated to HSM Solution Consumers prior to any potential impacts, these solution-level administration changes are out of scope of this requirement.
This requirement does not mandate that any HSM Solution must implement a “PCI mode,” nor how that mode is to function if it is implemented. HSM Solutions may allow for the HSM Solution Consumer to force all processing to operate in a way that is compliant to the PCI HSM requirements, tag-specific commands …
Added
p. 119
This requirement is intended to be assessed for processes used to provision new high-level cryptographic keys for an HSM Solution Consumer to the HSM processing elements. It should not be assessed for any keys used in secure channels, nor for any working keys that are protected by the cryptographic keys of other HSM Solution Consumers.
TK4.1 The tester shall confirm, for each method of provisioning HSM Solution Consumer keys to an HSM processing element, that a transport key is established for the conveyance of the HSM Solution Consumer key.
TK4.2 The tester shall confirm that a unique transport key is established for each provisioning process, and that transport keys cannot be reused or shared between different HSM Solution Consumers or by the same HSM Solution Consumer between different provisioning processes.
TK4.3 The tester shall confirm that the process(es) used to establish the transport key implement the principles of perfect forward secrecy.
TK4.4 The tester …
TK4.1 The tester shall confirm, for each method of provisioning HSM Solution Consumer keys to an HSM processing element, that a transport key is established for the conveyance of the HSM Solution Consumer key.
TK4.2 The tester shall confirm that a unique transport key is established for each provisioning process, and that transport keys cannot be reused or shared between different HSM Solution Consumers or by the same HSM Solution Consumer between different provisioning processes.
TK4.3 The tester shall confirm that the process(es) used to establish the transport key implement the principles of perfect forward secrecy.
TK4.4 The tester …
Added
p. 120
This requirement is intended to be assessed for cryptographic keys used to extend the tamper- responsive boundary of the HSM processing element outside of the physical boundary of the HSM processing element itself⎯that is, tamper keys maintained within the HSM processing element that are erased on a tamper event. It should not be assessed for any keys used in secure channels, nor for any working keys that are protected by cryptographic keys of the HSM Solution Consumer.
Additionally, this requirement does not apply to master keys that may be distributed across a finite set of HSM processing elements, with the permission of the HSM Solution Consumer as per requirement J1, to achieve elastic processing during use. However, such master keys would be in scope of this requirement if used for storage of the cryptographic keys of more than one HSM Solution Consumer.
Cryptographic keys directly managed by the HSM Solution Consumer are …
Additionally, this requirement does not apply to master keys that may be distributed across a finite set of HSM processing elements, with the permission of the HSM Solution Consumer as per requirement J1, to achieve elastic processing during use. However, such master keys would be in scope of this requirement if used for storage of the cryptographic keys of more than one HSM Solution Consumer.
Cryptographic keys directly managed by the HSM Solution Consumer are …
Added
p. 121
TK5.5 The tester shall confirm that any tamper key not directly managed by an HSM Solution Consumer cannot be exported from the HSM processing element⎯this includes for purposes of backup, load balancing, or fault tolerance. HSM processing element keys that may be used to protect the keys of more than one HSM Solution Consumer must not be able to be exported from the HSM processing element in any form.
TK5.6 The tester shall review the source code of the HSM processing element to confirm that no export or other functions exist that would disclose the values of HSM keys used to manage the keys of more than one HSM Solution Consumer.
TK5.7 For solutions that implement tamper keys generated by the HSM processing element, the tester shall establish two HSM Solution Consumer instances on a single HSM processing element and load the same cryptographic key into each instance. The tester shall confirm …
TK5.6 The tester shall review the source code of the HSM processing element to confirm that no export or other functions exist that would disclose the values of HSM keys used to manage the keys of more than one HSM Solution Consumer.
TK5.7 For solutions that implement tamper keys generated by the HSM processing element, the tester shall establish two HSM Solution Consumer instances on a single HSM processing element and load the same cryptographic key into each instance. The tester shall confirm …
Added
p. 122
This requirement is designed to ensure that any specific HSM processing element can be revoked by an individual or group of HSM Solution Consumer(s)⎯for example, in the case it is considered compromised or suspect, or where a specific HSM Solution Consumer has needs that are not met by some subset of the HSM processing elements. The requirement does not enforce who is authorized to disable the HSM processing element⎯this may be an action of the HSM Solution Consumer or HSM Solution Provider, but actions by an HSM Solution Consumer to disable a specific HSM processing element must not disable that HSM processing element for any other HSM Solution Consumer.
For example, an HSM Solution Consumer may want to prevent a set of HSM processing elements from accessing their cryptographic keys due to the configuration, location, or status of those HSM processing elements⎯but those same HSM processing elements may be acceptable for …
For example, an HSM Solution Consumer may want to prevent a set of HSM processing elements from accessing their cryptographic keys due to the configuration, location, or status of those HSM processing elements⎯but those same HSM processing elements may be acceptable for …
Added
p. 123
HSM Solution Consumers should have access to this information in order to have some visibility into actions impacting their cryptographic materials.
This log may be implemented by either returning these details in each command or maintaining a log that can be queried by the HSM Solution Consumer at any time. If a queriable log is maintained, controls must be implemented so the HSM Solution Consumer is able to obtain only that data related to the associated instance of HSM processing element(s).
The intent of this requirement is not to log the full details of every HSM Solution Consumer command and HSM response, but to allow for an HSM Solution Consumer to know which commands and cryptographic keys were operated by which HSM processing elements. An acceptable method of meeting this requirement would be to provide a log allowing sufficient granularity for the HSM Solution Consumer to know which elements may have processed …
This log may be implemented by either returning these details in each command or maintaining a log that can be queried by the HSM Solution Consumer at any time. If a queriable log is maintained, controls must be implemented so the HSM Solution Consumer is able to obtain only that data related to the associated instance of HSM processing element(s).
The intent of this requirement is not to log the full details of every HSM Solution Consumer command and HSM response, but to allow for an HSM Solution Consumer to know which commands and cryptographic keys were operated by which HSM processing elements. An acceptable method of meeting this requirement would be to provide a log allowing sufficient granularity for the HSM Solution Consumer to know which elements may have processed …
Added
p. 124
Note: This requirement is designed to reduce the risk of key compromise as the cryptographic keys of HSM Solution Consumers are spread across multiple HSM processing elements for the purpose of elastic processing.
Although this requirement does not prohibit the use of more than one HSM processing element from operating on the cryptographic keys of the same HSM Solution Consumer, it should not be possible for two or more HSM processing elements without additional security to access the same key space at any one time. Additionally, each HSM processing element including multiple instances running on the same physical device must not have any knowledge of key values for separate instances.
As it is not possible to validate a limit beyond “only one” within this standard, once there is the ability for two or more processing elements to access the cryptographic keys of the same HSM Solution Consumer, there can be no clear …
Although this requirement does not prohibit the use of more than one HSM processing element from operating on the cryptographic keys of the same HSM Solution Consumer, it should not be possible for two or more HSM processing elements without additional security to access the same key space at any one time. Additionally, each HSM processing element including multiple instances running on the same physical device must not have any knowledge of key values for separate instances.
As it is not possible to validate a limit beyond “only one” within this standard, once there is the ability for two or more processing elements to access the cryptographic keys of the same HSM Solution Consumer, there can be no clear …
Added
p. 125
The information may be contained in the security policy that is created in conjunction with Requirement C1 or in a separate, publicly available security policy that is reviewed by the PCI PTS recognized evaluation laboratory. If in a separate document, it must be referenced in the security policy created as part of C1.
TK9.1 The tester shall confirm that there is a publicly available security policy for the HSM processing solution.
TK9.2 The tester shall confirm that this policy includes all items required for a PCI HSM compliance solution, including what cryptographic services are provided/supported by the solution.
TK9.3 The tester shall confirm that the policy includes details on how HSM Solution Consumers are authenticated to the solution.
TK9.4 The tester shall confirm that the policy includes details on how the cryptographic keys of HSM Solution Consumers are provisioned to the HSM Solution.
TK9.5 The tester shall confirm that the policy includes details on how …
TK9.1 The tester shall confirm that there is a publicly available security policy for the HSM processing solution.
TK9.2 The tester shall confirm that this policy includes all items required for a PCI HSM compliance solution, including what cryptographic services are provided/supported by the solution.
TK9.3 The tester shall confirm that the policy includes details on how HSM Solution Consumers are authenticated to the solution.
TK9.4 The tester shall confirm that the policy includes details on how the cryptographic keys of HSM Solution Consumers are provisioned to the HSM Solution.
TK9.5 The tester shall confirm that the policy includes details on how …
Added
p. 126
• Methods for the secure disclosure to the impacted user organization of any vulnerabilities as they are found,
• Ranking and addressing vulnerabilities in a timely manner, and
• Methods for any HSM Solution Consumers of the HSM Solution to be informed of vulnerabilities.
This is intended to describe general practices and not individual actual occurrences.
TK10.1 The tester shall confirm that if a vulnerability-reporting program exists for the system, there is evidence of accepting and remediating security vulnerabilities found through this program. The vendor must be able to demonstrate that any such vulnerabilities are processed through its risk and update process and patched accordingly.
TK10.2 The tester shall confirm that the vendor has a documented process that is demonstrably in use for the discovery and remediation of security vulnerabilities in its system.
TK10.3 The tester shall confirm that a penetration test has been performed on the system. The scope of the penetration test(s) must include …
• Ranking and addressing vulnerabilities in a timely manner, and
• Methods for any HSM Solution Consumers of the HSM Solution to be informed of vulnerabilities.
This is intended to describe general practices and not individual actual occurrences.
TK10.1 The tester shall confirm that if a vulnerability-reporting program exists for the system, there is evidence of accepting and remediating security vulnerabilities found through this program. The vendor must be able to demonstrate that any such vulnerabilities are processed through its risk and update process and patched accordingly.
TK10.2 The tester shall confirm that the vendor has a documented process that is demonstrably in use for the discovery and remediation of security vulnerabilities in its system.
TK10.3 The tester shall confirm that a penetration test has been performed on the system. The scope of the penetration test(s) must include …
Added
p. 127
• Evidence of existence
•i.e., that these procedures are implemented. Example: The lab has received procedures from the company that implements the requirement.
• When these procedures are in use, samples of the process in operation. For this purpose
•in a timeframe of 3, 6, or 12 months
•samples can be randomly collected and validated. Example: For L3, the lab can randomly select a few occasions and ask for the related log belonging to the dual- control or standardized cryptographic authentication procedure used.
DTR L1 Change Control Change-control procedures are in place so that any intended change to the physical or functional capabilities of the device causes a re-certification of the device under the impacted security requirements of this document. Immediate re-certification is not required for changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality.
Pure bug fixes, including …
•i.e., that these procedures are implemented. Example: The lab has received procedures from the company that implements the requirement.
• When these procedures are in use, samples of the process in operation. For this purpose
•in a timeframe of 3, 6, or 12 months
•samples can be randomly collected and validated. Example: For L3, the lab can randomly select a few occasions and ask for the related log belonging to the dual- control or standardized cryptographic authentication procedure used.
DTR L1 Change Control Change-control procedures are in place so that any intended change to the physical or functional capabilities of the device causes a re-certification of the device under the impacted security requirements of this document. Immediate re-certification is not required for changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality.
Pure bug fixes, including …
Added
p. 129
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. This is true regardless of how labelled⎯e.g., OS, EPROM code, DLL’s, parameter files, applications, kernel code. This includes any code that is not in the Vendor Domain as defined in Appendix F, “Domain-Based Asset Flow Analysis.” Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.
“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.
The vendor shall indicate the compiler settings used in order to maximize the mitigation of known vulnerabilities.
The vendor shall implement …
“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.
The vendor shall indicate the compiler settings used in order to maximize the mitigation of known vulnerabilities.
The vendor shall implement …
Added
p. 130
TL2.5 The tester shall confirm that
•and summarize how
•the documented software-development process provides specific guidance for programmers, reviewers, and testers, and does not rely on non-specific statements⎯for example, the guidance “does not create buffer overflows” would be insufficient as it does not provide information to the programmer on how to prevent these problems.
TL2.6 The tester shall confirm that
•and summarize how
•the certification process includes checking of all code that executes in all HSM processing elements as listed in DTR A3.
TL2.7 The tester shall confirm that
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the device firmware.
TL2.8 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing is performed by a person who was not involved in the authorship of the device code.
TL2.9 The tester shall …
•and summarize how
•the documented software-development process provides specific guidance for programmers, reviewers, and testers, and does not rely on non-specific statements⎯for example, the guidance “does not create buffer overflows” would be insufficient as it does not provide information to the programmer on how to prevent these problems.
TL2.6 The tester shall confirm that
•and summarize how
•the certification process includes checking of all code that executes in all HSM processing elements as listed in DTR A3.
TL2.7 The tester shall confirm that
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the device firmware.
TL2.8 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing is performed by a person who was not involved in the authorship of the device code.
TL2.9 The tester shall …
Added
p. 131
TL2.14 The tester shall outline the following information: If the firmware is based on a general-purpose operating system (like Linux), the steps described in TL2.13 hold for this operating system. The documentation provided by the developer shall show that state-of-the-art rules for "hardening" the operating system have been applied. For example, the developer should provide a table showing a list of all known issues⎯like patch levels; not including unused packages, etc.; not being able to log into the operating system without cryptographic authentication in operational mode of the device; not being able to use debug functions like "netdump" during operational use⎯with remarks indicating how each issue has been addressed for the firmware under evaluation. Similar steps need to be performed for other firmware parts that are taken from external sources. The evidence provided by the developer should also include acceptance procedures, showing how the developer ensures that external software can …
Added
p. 139
• Evidence of existence
•i.e., that these procedures are implemented. For example, the lab has received procedures from the company that implements the requirement.
• When these procedures are in use, samples of the process in operation. For this purpose
•in a timeframe of 3, 6, or 12 months
•samples can be randomly collected and validated. Example: For M3, the lab can randomly select a few occasions and ask for the related log belonging to the received shipments proving that the packaging is validated on tamper evidence.
•i.e., that these procedures are implemented. For example, the lab has received procedures from the company that implements the requirement.
• When these procedures are in use, samples of the process in operation. For this purpose
•in a timeframe of 3, 6, or 12 months
•samples can be randomly collected and validated. Example: For M3, the lab can randomly select a few occasions and ask for the related log belonging to the received shipments proving that the packaging is validated on tamper evidence.
Added
p. 141
TM2.2 The tester shall examine a sample of transfer documentation
•including inventory logs and shipping documentation
•to ensure procedures are followed Where required to validate via site inspection, the tester shall complete the following additional steps:
TM3.2 The tester shall examine a sample of documentation for tamper protection, inspection and transfer documentation
•including inventory logs, shipping documentation, and device- validation procedures
•to ensure procedures are followed.
TM3.5 The tester shall observe the shipping process to ensure that devices are shipped and stored containing a secret that is immediately and automatically erased if any physical or functional alteration to the device is attempted, that can be verified by the initial key-loading facility but that cannot feasibly be determined by unauthorized personnel.
The means to verify the authenticity of the device may include tools such as an SCD.
•including inventory logs and shipping documentation
•to ensure procedures are followed Where required to validate via site inspection, the tester shall complete the following additional steps:
TM3.2 The tester shall examine a sample of documentation for tamper protection, inspection and transfer documentation
•including inventory logs, shipping documentation, and device- validation procedures
•to ensure procedures are followed.
TM3.5 The tester shall observe the shipping process to ensure that devices are shipped and stored containing a secret that is immediately and automatically erased if any physical or functional alteration to the device is attempted, that can be verified by the initial key-loading facility but that cannot feasibly be determined by unauthorized personnel.
The means to verify the authenticity of the device may include tools such as an SCD.
Added
p. 146
TM7.2 The tester shall verify that the model name and hardware version are retrievable from the device by a query using secure, cryptographically protected methods.
Added
p. 151
Specialist expertise and equipment are concerned with there being an implicit relationship between an attacker’s expertise and the ability to effectively make use of equipment in an attack. The weaker the attacker’s expertise, the lower the potential to effectively use equipment. Likewise, the greater the expertise, the greater the potential for equipment to be used in the attack. Although implicit, this relationship between expertise and the use of equipment does not always apply•for instance, when environmental measures prevent an expert attacker’s use of equipment; or when, through the efforts of others, attack tools requiring little expertise for effective use are created and freely distributed (for example, via the Internet).
Mechanical sample 1 1 Functional samples without working keys 2 2 Functional sample with working keys and software 4 4 Equipment required for the attack None 0 0 Standard 1 1 Specialized 3 3 Bespoke 5 5 Chip-level attacks 7 7 Specific …
Mechanical sample 1 1 Functional samples without working keys 2 2 Functional sample with working keys and software 4 4 Equipment required for the attack None 0 0 Standard 1 1 Specialized 3 3 Bespoke 5 5 Chip-level attacks 7 7 Specific …
Added
p. 154
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Public None 1 functional 80 hours 2. A method of attack is devised to bypass the tamper meshes and extract cryptographic keys from the system. In this example, multiple layers of mesh cover the sensitive areas and signals of the HSM, leading to a multi-stage attack. High speed memory is used in the system, requiring use of specialized equipment to capture the signals. The attack retrieves the main tamper key of the HSM, which is accessed on power on in this example, and therefore a bug is not required to be developed for installation into the HSM. Costings for this example are: Expert, 80 hours’ work, specialized equipment, and reusing the same functional sample.
3. The attack is exercised on another functional device with test keys. Public knowledge of how to operate the HSM and load keys is assumed.
Expertise Equipment Knowledge Parts …
3. The attack is exercised on another functional device with test keys. Public knowledge of how to operate the HSM and load keys is assumed.
Expertise Equipment Knowledge Parts …
Added
p. 158
• Standard PC (either off the shelf or built from components) PC-based instruments such as protocol sniffers, USB-attached oscilloscope adapters, and graphical multimeters are considered standard equipment, especially if they do not require dedicated hardware or adapters.
• Glitching systems, for example EM fault injection
• Glitching systems, for example EM fault injection
Added
p. 162
• Hash functions: Only algorithms from the SHA2 and SHA3 family are allowed, with output size > 255.
Added
p. 162
• Symmetric-key algorithms used for encryption and decryption: AES must be used, with key size >= 128 bits or TDES with keys size >= 112 bits.
• Message authentication codes (MACs): CMAC or GMAC can be used with AES, as well as HMAC with an approved hash function and a key size >= 128. TDES MACs must use ISO 16609 MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4.
• Signature algorithms: DSA, RSA (with PKCS1-v1.5 or PSS) and ECDSA with key sizes specified below.
• Approved key-establishment schemes are described in NIST SP800-56A (ECC/FFC 2-based key agreement), NIST SP800-56B (IFC-based key agreement), and NIST SP800-38F (AES-based key encryption/wrapping).
The following are the minimum key sizes 3 and parameters for the algorithm(s) in question that must be used in connection with key transport, exchange, or establishment and for data protection in connection with these requirements. Other key sizes …
• Message authentication codes (MACs): CMAC or GMAC can be used with AES, as well as HMAC with an approved hash function and a key size >= 128. TDES MACs must use ISO 16609 MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4.
• Signature algorithms: DSA, RSA (with PKCS1-v1.5 or PSS) and ECDSA with key sizes specified below.
• Approved key-establishment schemes are described in NIST SP800-56A (ECC/FFC 2-based key agreement), NIST SP800-56B (IFC-based key agreement), and NIST SP800-38F (AES-based key encryption/wrapping).
The following are the minimum key sizes 3 and parameters for the algorithm(s) in question that must be used in connection with key transport, exchange, or establishment and for data protection in connection with these requirements. Other key sizes …
Added
p. 163
TLS implementations must prevent the use of cipher suites that do not enforce the use of cryptographic ciphers, hash functions, and key lengths as defined in the Technical FAQs.
• FFC implementations entities must securely generate and distribute the system-wide parameters: generator g, prime number p, and parameter q, the large prime factor of (p
• Entities must authenticate the FFC or ECC public keys using DSA, ECDSA, a certificate, or a MAC. (If using a MAC, see ISO 16609
• Requirements for message authentication using symmetric techniques. One of the following shall be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4.) IFC, FFC, and ECC are vulnerable to attacks from large-scale quantum computers. In 2017, NIST initiated a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms, planned to end with a selection of new algorithms by 2023-2025.
Because of rapid …
• FFC implementations entities must securely generate and distribute the system-wide parameters: generator g, prime number p, and parameter q, the large prime factor of (p
• Entities must authenticate the FFC or ECC public keys using DSA, ECDSA, a certificate, or a MAC. (If using a MAC, see ISO 16609
• Requirements for message authentication using symmetric techniques. One of the following shall be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4.) IFC, FFC, and ECC are vulnerable to attacks from large-scale quantum computers. In 2017, NIST initiated a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms, planned to end with a selection of new algorithms by 2023-2025.
Because of rapid …
Added
p. 166
SCA must not be hindered by lack of basic resources PCI SSC considers to be essential:
• Notwithstanding physical protections (such as those validated by DTR A1), approved devices must not contain cryptographic implementations which, under analysis, can be straightforwardly compromised through SCA.
• Devices provided for evaluations must be adequately prepared by the vendor for efficient lab testing.
Establishing definite correlation of non-sensitive I/O data is important to (1) validate that the collection setup and test methodology are not flawed; (2) localize sensitive cryptographic operations in developing attacks; and (3) demonstrate that cryptographic key data is more resistant to leakage than other data. The expectation is for most tests to be capable of establishing definite correlation of non-sensitive I/O data. Very strong justification for null correlation results is needed otherwise, in asserting device compliance.
• Notwithstanding physical protections (such as those validated by DTR A1), approved devices must not contain cryptographic implementations which, under analysis, can be straightforwardly compromised through SCA.
• Devices provided for evaluations must be adequately prepared by the vendor for efficient lab testing.
Establishing definite correlation of non-sensitive I/O data is important to (1) validate that the collection setup and test methodology are not flawed; (2) localize sensitive cryptographic operations in developing attacks; and (3) demonstrate that cryptographic key data is more resistant to leakage than other data. The expectation is for most tests to be capable of establishing definite correlation of non-sensitive I/O data. Very strong justification for null correlation results is needed otherwise, in asserting device compliance.
Added
p. 171
Testing from separate evaluations meeting these best practices criteria can be reused, provided that (1) testing is no longer than from the previous major version of the standard (e.g., v3.x work can be reused if appropriate as part of a v4.x review; and (2) a complete chain of trust is demonstrated validating why previous testing is wholly applicable to a newly evaluated device. For “System on Chip” (SoC) type cryptographic implementations, where expert-level work, multiple effective SCA countermeasures, and collection sizes in excess of 1 million traces, etc., are demonstrated, test reuse will generally be straightforward to apply.
Reusing results Tests identifying little or no correlation and/or algorithmic structure are generally insufficient for reuse. Since multiple devices commonly use same security processor or System on Chip for cryptographic operations, it can be useful to reuse results from other evaluations to decrease the efforts for side- channel analysis. Nevertheless, to ensure the …
Reusing results Tests identifying little or no correlation and/or algorithmic structure are generally insufficient for reuse. Since multiple devices commonly use same security processor or System on Chip for cryptographic operations, it can be useful to reuse results from other evaluations to decrease the efforts for side- channel analysis. Nevertheless, to ensure the …
Added
p. 174
The general idea is to determine when a certain asset is available at a certain location. Any hardware component or software module dealing with the asset will be virtually marked with the domain that the asset belongs to. We call this imaginary process “tagging.” If a component or module is already tagged, it will keep the domain with the higher attack potential associated. Once the entire Asset Flow Analysis is performed, the appropriate domain will be assigned for each software module, hardware component, and even PCB track. This allows the tester to apply the appropriate DTRs for the specific domain.
It is therefore expected that the developer of the PTS device will perform this Domain-Based Asset Flow Analysis and provide the results and a proper explanation to the testers. The test lab will verify the analysis and use the effective domain rating as input for the evaluation.
For the vulnerability analysis⎯e.g., performed …
It is therefore expected that the developer of the PTS device will perform this Domain-Based Asset Flow Analysis and provide the results and a proper explanation to the testers. The test lab will verify the analysis and use the effective domain rating as input for the evaluation.
For the vulnerability analysis⎯e.g., performed …
Added
p. 175
• Although account-data protection keys require a lesser attack potential⎯i.e., 26 points⎯this is still in excess of the related security, requiring 20 points or less. Therefore, keys constitute a separate asset class in this environment, too.
PIN
• The cardholder PIN is protected to resist an attack potential of 26 points in DTR A1. PINs must not be disclosed. Passwords meet the same category.
Protection Data
• This class covers all other transaction data⎯e.g., PAN⎯ The DTRs protect these assets at 20 points or less.
Vendor Any other data or functionality that is not related to the PCI HSM DTRs. Compromising these assets cannot compromise PCI HSM security. The corresponding security policy is largely at the discretion of the vendor.
It is vital that any lower domain cannot access any higher domain other than by dedicated, confined, and well-specified interfaces provided by the higher domain or any of its parents. Explicitly, the Vendor domain has no …
PIN
• The cardholder PIN is protected to resist an attack potential of 26 points in DTR A1. PINs must not be disclosed. Passwords meet the same category.
Protection Data
• This class covers all other transaction data⎯e.g., PAN⎯ The DTRs protect these assets at 20 points or less.
Vendor Any other data or functionality that is not related to the PCI HSM DTRs. Compromising these assets cannot compromise PCI HSM security. The corresponding security policy is largely at the discretion of the vendor.
It is vital that any lower domain cannot access any higher domain other than by dedicated, confined, and well-specified interfaces provided by the higher domain or any of its parents. Explicitly, the Vendor domain has no …
Added
p. 176
Any code that could potentially endanger any asset⎯e.g., in case of malfunction or even complete replacement⎯is considered “firmware” in the sense of the DTR. We define “code” as any instructions for a processing hardware, including microcode or netlists for programmable hardware, and any kind of data that may affect the processing by these instructions. Such data can be as simple as configuration bits, whether or not a certain security function is enforced. In PCI HSM such data often is interpreted code, from simple access control rules represented as data for an engine up to large amounts of code⎯e.g., Java byte code in Android-based systems. As soon as data has the potential to compromise any of the DTRs, this data is considered firmware⎯i.e., code.
We define a process space as a container for code. Within the same process space there is no mechanism to ensure that any deliberate code change in one …
We define a process space as a container for code. Within the same process space there is no mechanism to ensure that any deliberate code change in one …
Added
p. 177
1. Consider the software in operational state and perform all transactions⎯e.g., key loading, online PIN translation, key export, etc. Follow the incoming data from each external interface until messages are sent on external interfaces. Consider where assets or parts of them pass through the firmware. Tag each module with the corresponding asset domain.
2. For each module tagged, identify modules in the same process space and tag them with the highest asset domain found for the current module. The result is the domain structure in operational state.
3. Consider how the tagged modules are loaded during boot and updated during operation. Since modification of the module’s code might compromise the corresponding assets, consider the authentication token of that code as an asset and assign it the same domain as the module itself.
Since authentication tokens like digital signatures are self-protective, the relevant code of the loader might reduce to the code verifying that …
2. For each module tagged, identify modules in the same process space and tag them with the highest asset domain found for the current module. The result is the domain structure in operational state.
3. Consider how the tagged modules are loaded during boot and updated during operation. Since modification of the module’s code might compromise the corresponding assets, consider the authentication token of that code as an asset and assign it the same domain as the module itself.
Since authentication tokens like digital signatures are self-protective, the relevant code of the loader might reduce to the code verifying that …
Added
p. 178
Applications An application in the sense of a PCI HSM device is code that is for any reason not considered firmware. The developer produces guidance on how such code shall be developed and installs procedures to verify compliance with this guidance as a precondition for signing the code. Application code must be authentic to be installed.
PCI HSM may allow applications in the Data domain and the Vendor domain. Applications therefore can never handle clear-text PIN or keys of the Key domain. The installation and use of applications for Cloud HSM Processing elements is not permitted.
Applications shall be segregated from other firmware, including firmware of the same domain and other applications at least from different issuers. This requires applications to run in unique process spaces. The tester shall verify that the separation of process spaces is effective for application sandboxing, which obviously exceeds the requirements for domain separation.
Asset Tagging Guidance In …
PCI HSM may allow applications in the Data domain and the Vendor domain. Applications therefore can never handle clear-text PIN or keys of the Key domain. The installation and use of applications for Cloud HSM Processing elements is not permitted.
Applications shall be segregated from other firmware, including firmware of the same domain and other applications at least from different issuers. This requires applications to run in unique process spaces. The tester shall verify that the separation of process spaces is effective for application sandboxing, which obviously exceeds the requirements for domain separation.
Asset Tagging Guidance In …
Added
p. 179
Identification of Interfaces
• The vendor shall list all interfaces accessible without tampering the device through normal access⎯e.g., casing removal. This explicitly includes interfaces that are not visible on the PCB but are available after removing any covers that do not signal a tamper event.
• The tester shall visually inspect the device to verify that all accessible interfaces have been listed.
• If interfaces connect to hardware subsystems that support multiple process spaces, the vendor shall clearly state which process space handles the low-level communication with the respective interface. Note that in most cases this will pertain to some kind of operating system.
• The tester shall consider any relevant documentation to verify these claims.
• The vendor shall describe the purpose of each interface listed. The tester shall reference and provide complete documentation describing all protocol layers. The documentation shall contain all commands, parameters, signal levels and their potential responses including all error …
• The vendor shall list all interfaces accessible without tampering the device through normal access⎯e.g., casing removal. This explicitly includes interfaces that are not visible on the PCB but are available after removing any covers that do not signal a tamper event.
• The tester shall visually inspect the device to verify that all accessible interfaces have been listed.
• If interfaces connect to hardware subsystems that support multiple process spaces, the vendor shall clearly state which process space handles the low-level communication with the respective interface. Note that in most cases this will pertain to some kind of operating system.
• The tester shall consider any relevant documentation to verify these claims.
• The vendor shall describe the purpose of each interface listed. The tester shall reference and provide complete documentation describing all protocol layers. The documentation shall contain all commands, parameters, signal levels and their potential responses including all error …
Added
p. 180
• The tester shall verify that all possible transactions for the device type and the claimed key- management schemes are listed.
• The tester shall verify that there are key-loading communications for each component storing keys.
• The tester shall verify that there is at least one operation to load any loadable key from the key table.
• The tester shall verify that there are firmware-loading communications for each component capable of software updates.
• If the device supports loadable prompts, the tester shall verify that there are mechanisms for loading prompts.
• If the device supports applications, the tester shall verify that there are mechanisms for loading applications.
• For each operation, the vendor shall describe how any assets or asset containers enter or exit at the listed interfaces, and how they are conveyed between subsystems. The description shall clearly state where and when asset containers are unwrapped or assets are wrapped into containers. This …
• The tester shall verify that there are key-loading communications for each component storing keys.
• The tester shall verify that there is at least one operation to load any loadable key from the key table.
• The tester shall verify that there are firmware-loading communications for each component capable of software updates.
• If the device supports loadable prompts, the tester shall verify that there are mechanisms for loading prompts.
• If the device supports applications, the tester shall verify that there are mechanisms for loading applications.
• For each operation, the vendor shall describe how any assets or asset containers enter or exit at the listed interfaces, and how they are conveyed between subsystems. The description shall clearly state where and when asset containers are unwrapped or assets are wrapped into containers. This …
Added
p. 181
• All hardware and software tagged as Vendor domain may be taken out of scope. As such, the boundary of the device is clearly defined. It may also be used as guidance for the security officer of the vendor to decide which modifications may clearly be covered by wildcards.
• The domain assigned to any subsystem defines the appropriate attack potential to the subsystem.
• The Asset Flow Analysis shall describe all cryptographic operations performed with relevant keys. This shall be used as an input to scope which side-channel attacks are feasible. Furthermore, it defines which components should be investigated for side channels.
Asset Flow Analysis Example In this section we will provide a brief example of an asset flow analysis for an imaginary HSM. It should be noted that this is an example only and does not imply that this is the only possible configuration for an HSM, or even that this …
• The domain assigned to any subsystem defines the appropriate attack potential to the subsystem.
• The Asset Flow Analysis shall describe all cryptographic operations performed with relevant keys. This shall be used as an input to scope which side-channel attacks are feasible. Furthermore, it defines which components should be investigated for side channels.
Asset Flow Analysis Example In this section we will provide a brief example of an asset flow analysis for an imaginary HSM. It should be noted that this is an example only and does not imply that this is the only possible configuration for an HSM, or even that this …
Added
p. 182
The Cryptographic Accelerators store and process clear-text user cryptographic keys, as well as the HSM tamper keys used to secure the user keys. These keys are entered into the accelerators encrypted under another (already known) key or entered as key components through the serial or USB interfaces. Clear- text cryptographic keys and components can be output from the Cryptographic Accelerator(s) via the serial connection only (clear-text key output is provided on this system for key-loading purposes). A communications switch, under the control of the API/Virtualization controller, is able to route the USB or serial traffic to the Cryptographic Accelerators as required, with the USB interface also able to be switched to the API/Virtualization controller.
Sample data flows for key component entry and for cryptographic operations are provided below.
Figure F-2: Data Flow for Key-component Loading from Example HSM .
Sample data flows for key component entry and for cryptographic operations are provided below.
Figure F-2: Data Flow for Key-component Loading from Example HSM .
Removed
p. 6
• Core Derived Test Requirements
• Key Loading Devices Derived Test Requirements
• Remote Administration Derived Test Requirements
• Device Management Derived Test Requirements Each PCI requirement as stated in the PCI PTS Hardware Security Module (HSM) Modular Security Requirements is represented by a subsection. For example, Requirement A1.1 is represented in this document as:
DTR A1 Tamper-Detection Mechanisms Each PCI requirement has been divided into component parts. These parts are identified by the corresponding PCI requirement number and a number distinguishing it from other components of the same requirement. These components parts are DTRs.
These are identified by a “T,” followed by the component identification number For example, the first DTR under A1 is:
FIPS 140-2 Requirements Some requirements in this manual are derived from requirements in Federal Information Processing Standard 140-2 (FIPS 140-2). These requirements are footnoted in this document with an asterisk (*) beside the requirement number.
Because many FIPS 140-2 evaluations only cover …
• Key Loading Devices Derived Test Requirements
• Remote Administration Derived Test Requirements
• Device Management Derived Test Requirements Each PCI requirement as stated in the PCI PTS Hardware Security Module (HSM) Modular Security Requirements is represented by a subsection. For example, Requirement A1.1 is represented in this document as:
DTR A1 Tamper-Detection Mechanisms Each PCI requirement has been divided into component parts. These parts are identified by the corresponding PCI requirement number and a number distinguishing it from other components of the same requirement. These components parts are DTRs.
These are identified by a “T,” followed by the component identification number For example, the first DTR under A1 is:
FIPS 140-2 Requirements Some requirements in this manual are derived from requirements in Federal Information Processing Standard 140-2 (FIPS 140-2). These requirements are footnoted in this document with an asterisk (*) beside the requirement number.
Because many FIPS 140-2 evaluations only cover …
Modified
p. 7 → 10
• Accurately provides the information specified in this document, without any ambiguous or inconsistent information;
• Accurately provides information specified in this document, without ambiguous or inconsistent information;
Modified
p. 7 → 10
• Conforms to Laboratory General Requirements and any other related documentation in the PTS Program, such as (but not restricted to) Reporting Guidance and Report Template.
• Conforms to Laboratory General Requirements and any other related documentation in the PTS Program, such as (but not restricted to) Reporting Guidance and Template.
Modified
p. 7 → 10
• Security processor(s) and other processors and memory, operating system(s), boot-up sequences, firmware modules, software applications, crypto functions, data-loading mechanisms, etc.
• Security processor(s) and other processors and memory, operating system(s), boot-up sequences, firmware modules, software applications, crypto functions, data-loading mechanisms, hardware versions and software versions with explanations of versioning, features and functions associated with the device’s approval, etc.
Modified
p. 7 → 10
• This overview must present all security-relevant features necessary to derive the principal assets, threats, and attacks relevant to Security Requirements, as follows:
• This overview must present all security-relevant features necessary to derive assets, threats, and attacks relevant to the Security Requirements, as follows:
Modified
p. 7 → 10
• Photographs of the device from different perspectives, sufficient for all sides of the evaluated device to be clearly seen.
Modified
p. 7 → 10
• A list or table of the device’s features and functions.
Modified
p. 7 → 10
• A list or table of the device’s security-related assets relevant to applicable DTRs.
Modified
p. 7 → 10
• A list or table of the device’s principal physical components along with a photograph of the components, disassembled, indicating each of the components.
Modified
p. 7 → 10
• Illustrations/descriptions of the device’s logical architecture, interfaces, and key management, to indicate the hierarchy/relationships of firmware and other logical attributes of the device.
Modified
p. 7 → 10
• Block diagram(s) indicating the hardware evaluation boundary with regard to the device’s overall architecture and peripheral interfaces.
Modified
p. 7 → 10
• If applicable, a diagram or description the device’s integration into other architectures and/or integrating components.
Removed
p. 8
Note that a copy of the Vendor Questionnaire shall be submitted to the Report Portal along with the test report and any other supporting documents, such as the Security Policy.
• The text of the security requirements and guidance
• Validation of the completed Vendor Questionnaire and other vendor responses by stating:
a) Whether the evidence supports vendor assertions that the device is compliant with this requirement.
i. Where the evidence does support vendor assertions, assign a verdict of “Verified”;
ii. Where it does not, assign a verdict of “Not Verified.”
b) Whether the vendor’s responses appear to be consistent and comply with the relevant PCI Requirement(s).
i. If consistent and compliant, provide a brief written description of why the responses appear to be consistent and the device complies with the PCI requirement.
ii. If the responses do not appear to be consistent and do not comply with PCI requirements, provide a brief written description of why they …
• The text of the security requirements and guidance
• Validation of the completed Vendor Questionnaire and other vendor responses by stating:
a) Whether the evidence supports vendor assertions that the device is compliant with this requirement.
i. Where the evidence does support vendor assertions, assign a verdict of “Verified”;
ii. Where it does not, assign a verdict of “Not Verified.”
b) Whether the vendor’s responses appear to be consistent and comply with the relevant PCI Requirement(s).
i. If consistent and compliant, provide a brief written description of why the responses appear to be consistent and the device complies with the PCI requirement.
ii. If the responses do not appear to be consistent and do not comply with PCI requirements, provide a brief written description of why they …
Modified
p. 8 → 11
The vendor shall make source code available to the lab and provide assistance to make a systematic review of relevant security functions.
The vendor shall make all source code available to the lab and provide assistance to make a systematic review of relevant security functions.
Modified
p. 8 → 11
The evaluation report document shall demonstrate compliance to Security Requirements. For all DTRs, the tester shall present sufficient information on direct tests and theoretical claims to validate conclusions by demonstrating how any conclusions are derived. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid against PTS Program•i.e., considering DTRs, FAQs, Program Guide, and any other related documents. Every DTR should be supported by …
The evaluation report document shall demonstrate compliance to Security Requirements and shall present all test evidence as requested within individual DTRs. For all DTRs, the tester shall present sufficient information on direct tests and theoretical claims to validate conclusions by demonstrating how any conclusions are derived. The tester should use his or her own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid against PTS Program•i.e., considering DTRs, FAQs, Program Guide, …
Modified
p. 8 → 11
• Descriptions of the vendor’s attestations of compliance to security requirements;
• Descriptions of the vendor’s attestations of compliance to security requirements, with:
Modified
p. 8 → 11
• Explanations for the scope and focus of test activities and attack hypotheses, including explanations of white-box or black-box approaches used, and why;
• Detailed explanations of the scope and focus of test activities and attack hypotheses, including explanations of white-box or black-box approaches used, and why;
Modified
p. 8 → 11
• Details of decisions made for performing penetration testing, the methodologies used, and the results of penetration testing;
• Details of decisions made for performing penetration testing, the methodologies used, and the results of penetration testing.
Modified
p. 8 → 12
• Justifications for any reliance on test evidence not derived directly from the evaluation activities;
• Justifications for any reliance on test evidence derived from devices other than the device under test;
Modified
p. 9 → 12
The tester shall justify any deviation from the prescribed routines. The tester is not limited to only presenting information specified by DTR text and should in many cases expand upon that information as necessary to support a conclusion.
The tester shall justify any deviation from the prescribed routines. The tester is not limited to only presenting information specified by DTR text/guidance/FAQs/Program Guide. Where necessary to support a conclusion, the tester shall expand upon that information.
Modified
p. 9 → 12
All DTRs must include references to documents and any other relevant sources of information upon which the evaluation relies. References must indicate information sources sufficiently to enable PCI to identify and retrieve test evidence following device approval.
All DTRs must include references to documents and any other relevant sources of information upon which the evaluation relies. References must indicate information sources sufficiently to enable PCI to identify test evidence following device approval.
Modified
p. 10 → 14
Areas of the device that contain sensitive information persistently or during the normal operation of the device must be protected via tamper-detection mechanisms. Areas where sensitive information is only present when a human operator is present may be protected solely by tamper-evidence mechanisms if the vendor documentation describes an inspection process that must be performed prior to entering sensitive information.
Areas of the device that contain sensitive information persistently or during the normal operation of the device must be protected via tamper-detection mechanisms.
Modified
p. 10 → 14
For those devices that do not contain secret information, device disablement may be used in lieu of “immediate erasure of all secret information.” “Secret information” is any private or secret cryptographic keys or passwords that the device relies on to maintain security characteristics governed by PCI requirements. If any of this secret information is not zeroized, other mechanisms must exist to disable the device.
For those devices that do not contain secret information, device disablement may be used in lieu of “immediate erasure of all secret information.” “Secret information” is any private or secret cryptographic keys or passwords/authentication codes that the device relies on to maintain security characteristics governed by PCI requirements. If any of this secret information is not zeroized, other mechanisms must exist to disable the device.
Removed
p. 11
TA1.1 The tester shall visually inspect the tamper-detection mechanism to verify the assertions provided by the vendor in response to Section A1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement A1 of the PCI PTS HSM Modular Security Requirements for consistency relating to the tamper-detection mechanism. The vendor responses should clearly indicate how tamper-detection mechanisms are effective and robust. The tester shall summarize the responses.
Modified
p. 11 → 15
TA1.2 The tester shall provide an overview of the device and how it is constructed. The tester shall include an exploded diagram of the device showing how all sub-components are assembled and connected internally•for example, an explanation of processor (secure and unsecure) architectures and where these are located with regard to the internal areas of the device.
Modified
p. 11 → 15
TA1.3 The tester shall attempt to penetrate or open the device to activate the tamper-detection mechanisms and then perform tests to support evidence that the mechanisms cause the immediate and automatic erasure or non-recoverability of any secret data contained in the device. Tests that may be performed could include attempting a transaction to determine whether the transaction fails, using a special function of the device that allows a user to determine the status of secret data, or using special software …
Modified
p. 11 → 15
TA1.6 The tester shall verify that attempts to probe critical security circuitry through any means other than opening the case (such as through vents, fans, or holes) do not allow probing access without triggering the tamper-detection mechanisms.
Modified
p. 11 → 15
TA1.7 If a cover is part of the tamper-detection mechanism, the tester shall verify that attempts to remove the cover by removing fasteners, plates, connectors, etc., or by creating a gap between the covers or cover and housing do not allow access to probe critical security circuitry without triggering the tamper-detection mechanisms.
Modified
p. 11 → 16
TA1.11 The tester shall examine any relevant documentation submitted by the vendor, including vendor test results for inspections of internal buffers, to verify that it supports the vendor responses.
Removed
p. 12
TA1.10 The tester shall examine any relevant documentation submitted by the vendor, including vendor test results for inspections of internal buffers, to verify that it supports the vendor responses.
Modified
p. 12 → 16
If the device is restricted to deployment in controlled environments, the following applies: To remove the cover, the tester may open, pry, or disassemble the device at cover seams and remove other plates, connectors, etc., to gain access to the tamper-detection mechanisms. Removing shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure. The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover.
If the device is restricted to deployment in an environment meeting at least the security of a controlled environment, the following applies: To remove the cover, the tester may open, pry, or disassemble the device at cover seams and remove other plates, connectors, etc., to gain access to the tamper-detection mechanisms. Removing shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure. The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to …
Modified
p. 12 → 16
TA1.9 The tester shall examine vendor documentation relating to the response of the device to tamper detection for consistency with device functionality and documentation, including the key table in the vendor security policy. Any sensitive information that is not erased must be encrypted using accepted algorithms and key sizes according to the table presented in Appendix D.
Modified
p. 12 → 16
TA1.10 The tester shall examine vendor-supplied documentation to determine whether the device employs active or passive (i.e., removal of power) erasure. If the device employs passive erasure, the tester shall verify that erasure occurs rapidly enough to prevent an attacker from opening the device and stopping erasure before it is effective. The tester may create an attack scenario, which may be performed in its entirety or in part to verify the theory.
Modified
p. 12 → 16
TA1.12 The tester shall enumerate each of the circuit boards indicated in the device in the table below, providing, at a minimum:
Modified
p. 12 → 16
e) Note as to whether the PCB contains any sensitive signals (such as plaintext PINs or keying material•but not tamper signals); and, finally,
e) Note as to whether the PCB contains any sensitive signals (such as clear-text PINs or keying material•but not tamper signals); and, finally,
Modified
p. 12 → 16
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information (see Annex A of the Vendor Questionnaire).
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information.
Modified
p. 13 → 17
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information (see Annex A of the Vendor Questionnaire).
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information.
Modified
p. 13 → 17
TA1.14 If the HSM has a keypad, the tester shall describe whether any of the items on the path of the keypad signals are not protected by all tamper-detection mechanism. For example, the tester shall note whether a signal via terminates on the same layer as a tamper grid and if any passive components are located outside of the protected area or are connected to vias (including power vias) that terminate outside of the protected area(s).
Modified
p. 13 → 17
TA1.15 Using vendor documentation for each tamper grid that is implemented, the tester shall complete the details indicated in the table below, describing, at a minimum:
Modified
p. 13 → 17
Tamper Grid Physical Implementation Size of Traces and Distance between Traces, Signals, or Layers Tamper- detecting Signals Method of Connection Adjacent Signals? TA1.15 The tester shall describe what testing was performed to validate the protection provided by each of the tamper grids enumerated above.
Tamper Grid Physical Implementation Size of Traces and Distance between Traces, Signals, or Layers Tamper- detecting Signals Method of Connection Adjacent Signals? TA1.16 The tester shall describe what testing was performed to validate the protection provided by each of the tamper grids enumerated above.
Modified
p. 13 → 17
TA1.17 For each tamper switch used in the device, the tester shall complete the details indicated in the table below, at a minimum.
Modified
p. 13 → 17
The tester shall use the ”Additional Comments” column to note any unusual features the tamper switch may possess that make it easier or harder to attack•such as being covered by a flexible tamper grid or having a unique construction (see Annex A of the Vendor Questionnaire).
The tester shall use the ”Additional Comments” column to note any unusual features the tamper switch may possess that make it easier or harder to attack•such as being covered by a flexible tamper grid or having a unique construction.
Removed
p. 14
TA1.27 The tester shall describe how the device responds to a tamper-detection event.
TA1.28 Deriving from the previous descriptions, the tester shall explain how the immediate and complete erasure of all sensitive information from the device results from tamper-detection events.
TA1.28 Deriving from the previous descriptions, the tester shall explain how the immediate and complete erasure of all sensitive information from the device results from tamper-detection events.
Modified
p. 14 → 18
TA1.19 The tester shall note which tamper-detection mechanisms use active high, active low, dynamic, resistive, or other types of sensors. The tester shall confirm that any guard rings or interspersed traces in tamper grids are at opposing voltages that will activate tamper detection if electronically shorted. The tester shall note what testing has been performed to confirm this.
Modified
p. 14 → 18
TA1.20 The tester shall describe any volume-encapsulation methods used in the device•for example, epoxy filling•that are designed to make penetration or reverse engineering more difficult.
Modified
p. 14 → 18
TA1.21 The tester shall describe what testing was performed to validate any volume encapsulation.
Modified
p. 14 → 18
TA1.22 The tester shall describe any attachment or “forming” methods (such as soldering, elastomeric strips, or adhesive for attachment, and plastic/metal walls for forming the shape of flexible circuits) used as part of the security features of the device. For example, the tester shall detail the methods used to secure any flexible tamper grids or “cover PCBs” so they cannot be bent or lifted out of the way.
Modified
p. 14 → 18
TA1.23 The tester shall describe what testing was performed to validate any attachment and forming methods. Methods of testing must include use of localized heating, solvents, and abrasion. The tester shall justify why the testing performed was sufficient and why the security measures cannot be bent, melted, or otherwise bypassed, to gain access to sensitive signals.
Modified
p. 14 → 18
TA1.24 The tester shall provide details on the security processor used in the device, including how it drives tamper-detection features. The tester shall provide and reference picture(s) of the location(s) and area(s) surrounding processor(s) used by the device, specifying those that are security-relevant.
Modified
p. 14 → 18
TA1.26 The tester shall describe any device security features used to protect sensitive data that have not already been covered in the previous descriptions (for example, special processor packaging). The tester shall detail what testing has been performed to validate each of these features.
Modified
p. 14 → 18
TA1.27 The tester shall provide and make reference to a schematic diagram of the tamper circuits of the device, showing connections to all tamper-detection features including switches and tamper grids.
Modified
p. 14 → 18
TA1.28 The tester shall state how any passive components, connectors, or other items that carry tamper signals are protected against being accessed. The tester shall include any connections to power planes through hole vias that may be exposed outside of the tamper-detecting areas of the device.
Removed
p. 15
• Attack P1 Identification Stage
Removed
p. 15
3. Description of Step 3 4. Etc.
3. Description of Step 3 4. Etc.
Step Expertise Knowledge Equipment Parts Samples Time 1 Proficient Public Standard None 1 Mechanical 80 hours 2 Proficient Public Standard None 40 hours 3 Proficient Public Standard None 1 Functional without keys 80 hours
• Attack P1 Exploitation Stage
3. Description of Step 3 4. Etc.
Step Expertise Knowledge Equipment Parts Samples Time 1 Proficient Public Standard None 1 Mechanical 80 hours 2 Proficient Public Standard None 40 hours 3 Proficient Public Standard None 1 Functional without keys 80 hours
• Attack P1 Exploitation Stage
Modified
p. 15 → 19
If the device is restricted to deployment in controlled environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
If the device is restricted to deployment in and environment meeting at least the security of a controlled environment, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
Removed
p. 16
• Attack P1 Cost Breakdown Phase Value Description Identification Phase Attack Time 7.5 Beyond 160 hours Expertise 3 Proficient Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 1 Standard (reused in exploitation) Specific Parts 0 None Identification Total 14.5 Exploitation Phase Attack time 3 ≤ Eight hours (FAIL) Expertise 0 Layman Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 1 Standard (reused equipment from identification) Specific Parts 1 Standard Exploitation Total 9 (FAIL) Grand Total 23.0 (FAIL) Attack “P2”
• Attack P2 Identification Stage
• Attack P2 Identification Stage
Removed
p. 17
• Attack P2 Exploitation Stage
3. Description of Step 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Proficient Public Standard None 1 Mechanical 25 hours 2 Proficient Public Standard Standard 1 hour 3 Proficient Public Standard None Functional sample with working keys and software 0.5 hours
• Attack P2 Cost Breakdown Phase Value Description Identification Phase Attack Time 7 ≤ 160 hours Expertise 4 Expert Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 3 Specialized (reused in exploitation) Specific Parts 0 None Identification Total 17.0 Exploitation Phase Attack time 5.5 ≤ 40 hours Expertise 3 Proficient Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 1 Standard (subset of identification equipment, reused) Specific Parts 1 Standard Exploitation Total 14.5 Grand Total 31.5 TA1.34 The tester shall verify that no attack was able to be determined, including those …
3. Description of Step 3 Step Expertise Knowledge Equipment Parts Samples Time 1 Proficient Public Standard None 1 Mechanical 25 hours 2 Proficient Public Standard Standard 1 hour 3 Proficient Public Standard None Functional sample with working keys and software 0.5 hours
• Attack P2 Cost Breakdown Phase Value Description Identification Phase Attack Time 7 ≤ 160 hours Expertise 4 Expert Knowledge 0 Public Access Costs 3 One mechanical and one functional sample without keys Equipment required 3 Specialized (reused in exploitation) Specific Parts 0 None Identification Total 17.0 Exploitation Phase Attack time 5.5 ≤ 40 hours Expertise 3 Proficient Knowledge 0 Public Access Costs 4 Functional sample with working keys and software Equipment required 1 Standard (subset of identification equipment, reused) Specific Parts 1 Standard Exploitation Total 14.5 Grand Total 31.5 TA1.34 The tester shall verify that no attack was able to be determined, including those …
Modified
p. 18 → 20
The vendor must either provide substantive data to support the security of the product outside normal operating conditions (if test results and/or testing on subsections/components are used to verify the security), or show that the product uses sensors that will trigger a tamper response.
The vendor must either provide substantive data to support the security of the product outside normal operating conditions (if test results and/or testing on subsections/components are used to verify the security) or show that the product uses sensors that will trigger a tamper response.
Modified
p. 18 → 20
TA2.1 The tester shall provide the operational temperature and voltage range for the device as detailed in vendor documentation.
Modified
p. 18 → 20
TA2.2 Using the schematics and descriptions from TA1.2, TA1.12, TA1.15 and TA1.17, the tester shall list the temperature ranges for all components included in the tamper-detection circuit. This shall include mechanical switches and active elements (but not passive elements such as resistors and capacitors).
Modified
p. 19 → 20
Maximum Value Minimum Value Detecting Circuitry Response Voltage (Specify type) Configured Value Configured Value Tested Value Tested Value Temperature Configured Value Configured Value Tested Value Tested Value TA2.6 In the maximum/minimum values for each item, the tester shall note what the vendor attests the value is set to in the “Configured Value” cells of the above table.
Maximum Value Minimum Value Detecting Circuitry Response Voltage (Specify type) Configured Value Configured Value Tested Value Tested Value Temperature Configured Value Configured Value Tested Value Tested Value TA2.4 In the maximum/minimum values for each item, the tester shall note what the vendor attests the value is set to in the “Configured Value” cells of the above table.
Modified
p. 19 → 20
•using special test code from the vendor, which shall be removed from production units
•to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table.
TA2.5 Using a device that has been configured
•using special test code from the vendor, which shall be removed from production units
•to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table.
•using special test code from the vendor, which shall be removed from production units
•to operate self-tests such that the correct operation of the device can be confirmed, the tester shall test each of the environmental features listed above and enter the value at which the detection circuitry activates into the “Tested Value” cells of the above table.
Modified
p. 19 → 21
TA2.7 Given the details and results above, the tester shall justify why the tamper-detection mechanisms will remain functional and the device secure at all extremes within the range of environmental monitoring.
Modified
p. 19 → 21
TA2.8 The tester shall develop attack scenarios to compromise the device by altering operational conditions and consider whether altering environmental conditions may be used to develop attacks.
Modified
p. 19 → 21
TA2.9 The tester may perform any test needed to validate the attack scenario. The tester shall present sufficient evidence and/or references for the above, for demonstrating compliance to this DTR.
Removed
p. 20
TA3.1 The tester shall examine the response to Section A3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement A3 of the PCI PTS HSM Modular Security Requirements manual for consistency relevant to Requirement A3. The vendor responses should clearly indicate what sensitive information and functions exists; that sensitive functions or information are only used in the protected area(s) of the device; and that sensitive information and functions dealing with sensitive information are protected from unauthorized modification. The tester shall summarize the responses.
TA3.2 The tester shall examine and cite any additional relevant documentation, such as assembly drawings and functional specifications submitted by the vendor, to verify that it supports the vendor responses. The tester shall reference this information and indicate how it supports the assessment.
TA3.2 The tester shall examine and cite any additional relevant documentation, such as assembly drawings and functional specifications submitted by the vendor, to verify that it supports the vendor responses. The tester shall reference this information and indicate how it supports the assessment.
Modified
p. 20 → 22
TA3.1 The tester shall verify the completeness of the information regarding sensitive information and functions presented by the vendor.
Modified
p. 20 → 22
TA3.2 In the following table, the tester shall outline the locations of all types of sensitive information and functions, adding to those provided where other types of sensitive information exist within the device. This shall include both long-term and temporary storage locations, as well as information on any programmable logic used in the device as part of the PIN processing circuit. The Storage Area column shall outline where and what type of storage is used for this information (such as …
Modified
p. 21 → 22
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information (See Annex A of the Vendor Questionnaire).
The tester shall adapt the table (for example, by adding columns or additional notes) as necessary, to present any additional information. The tester shall reference the relevant aspects of the asset flow.
Modified
p. 21 → 23
•that are used to store, process, or secure sensitive information.
•that are used to store, process, or secure sensitive information. The tester shall reference the relevant aspects of the asset flow.
Modified
p. 21 → 23
TA3.4 For each of the integrated circuit elements (described above) that may be programmed or configured in some way, the tester shall enumerate the following:
Modified
p. 21 → 23
TA3.5 The tester shall detail what methods have been implemented to disable all of the programming/testing features outlined above. The tester shall detail the testing performed to validate that these features are indeed disabled. The tester shall justify why these measures are sufficient and confirm that these features cannot be re-enabled.
Modified
p. 21 → 23
TA3.6 If additional memory is implemented and is not included in the sensitive-information storage areas above, the tester shall detail what processes have been used to validate that this is the case. The tester shall detail all memory in the device and detail where sensitive data is stored and how it is protected.
Modified
p. 21 → 23
TA3.7 If the device allows for the execution of applications and firmware on the same processor that stores or operates on clear-text passwords/authentication codes, PINs, or public keys, the tester shall note what mechanisms are implemented to prevent these applications from modifying this information. The tester shall detail how this has been validated as sufficient. The tester shall reference the relevant aspects of the asset flow.
Modified
p. 21 → 23
TA3.8 Where signatures are used as a method of protection, the tester shall:
Modified
p. 21 → 23
b) Detail what padding scheme is used for the signatures, and justify how this prevents attacks such as padding oracle attacks.
b) Detail what padding scheme is used for the signatures and justify how this prevents attacks such as padding oracle attacks.
Modified
p. 22 → 23
TA3.10 Where encryption is used as a method of protection of sensitive information, the tester shall:
Modified
p. 22 → 24
TA3.12 The tester shall describe and produce a costing for the most feasible attack to recover sensitive information from the device. The tester shall detail for each step whether the information is based on testing or assumptions and provide justification for any use of assumptions rather than actual testing.
Modified
p. 22 → 24
If an attack scenario can be developed that yields an attack potential of less than 26 per device for identification and initial exploitation or less than 13 per device for exploitation only, as defined in Appendix A, the vendor assertion cannot be verified. If attack scenarios can only be developed yielding attack potentials above these thresholds, the tester shall present these to demonstrate how the device is compliant to this DTR. At least one attack scenario shall be presented, in …
If an attack scenario can be developed that yields an attack potential of less than 26 per device for identification and initial exploitation or less than 13 per device for initial exploitation only, as defined in Appendix A, the vendor assertion cannot be verified. If attack scenarios can only be developed yielding attack potentials above these thresholds, the tester shall present these to demonstrate how the device is compliant to this DTR. At least one attack scenario shall be presented, …
Modified
p. 22 → 24
If the device is restricted to deployment in controlled environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, or press-fittings) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However, removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
If the device is restricted to deployment in an environment meeting at least the security of a controlled environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, or press-fittings) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However, removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
Removed
p. 23
Internal access may include physical attack methods to insert a probe to monitor emanations. The probe must be outside the protected areas of the device’s components•i.e., tamper-protected components may reside inside a non-tamper protected housing TA4.1 The tester shall examine the vendor’s response to Section A4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement A4 of the PCI PTS HSM Modular Security Requirements for consistency relevant to A4. The vendor responses should clearly indicate how the device is protected from monitoring. The tester shall summarize the responses.
TA4.2 The tester shall examine and cite any relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses to the PCI PTS HSM Modular Evaluation Vendor Questionnaire.
TA4.3 The tester shall visually inspect the device to verify the assertions provided by the vendor in the PCI PTS HSM Modular …
TA4.2 The tester shall examine and cite any relevant documentation, such as schematics and assembly drawings, submitted by the vendor to verify that it supports the vendor responses to the PCI PTS HSM Modular Evaluation Vendor Questionnaire.
TA4.3 The tester shall visually inspect the device to verify the assertions provided by the vendor in the PCI PTS HSM Modular …
Removed
p. 24
The tester shall present evidence allowing test methodologies and results to be validated.
Removed
p. 25
The vendor shall provide mechanisms to facilitate side-channel testing. These mechanisms shall include at least the following: an interface, the ability to vary data and keys, and the ability to set trigger points (for testing purposes only and not for production units).
SCA tests shall be performed in accordance with Appendix E.
TA5.1 The tester shall examine the vendor’s response to Section A5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement A5 of the PCI PTS HSM Modular Security Requirements for consistency relevant to A5. The vendor responses should clearly indicate how the device is protected from analysis attempting to determine any PCI- security-related cryptographic key resident in the device. The tester shall summarize the responses.
TA5.2 The tester shall examine and cite any relevant documentation, such as assembly drawings or test data, submitted by the vendor to verify that it supports the vendor responses.
TA5.6 The tester …
SCA tests shall be performed in accordance with Appendix E.
TA5.1 The tester shall examine the vendor’s response to Section A5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement A5 of the PCI PTS HSM Modular Security Requirements for consistency relevant to A5. The vendor responses should clearly indicate how the device is protected from analysis attempting to determine any PCI- security-related cryptographic key resident in the device. The tester shall summarize the responses.
TA5.2 The tester shall examine and cite any relevant documentation, such as assembly drawings or test data, submitted by the vendor to verify that it supports the vendor responses.
TA5.6 The tester …
Modified
p. 25
“Keys resident in the device or its components” means clear-text secret or private keys. If the encrypted keys are protected in accordance with the minimum key sizes and parameters for the key- encipherment algorithm(s) used as stipulated in Appendix D, they do not need to be considered. For purposes of this requirement, this includes transaction or other security-relevant keys that are only temporarily in the device and are not stored in the device.
Modified
p. 25
TA4.1 The tester shall provide details on the type, location, and accessibility, of the security processor(s) used by the device, and any other elements of the device that have relevance to possible attacks. This shall include a list of all barriers obstructing access to keys, beginning with the device exterior case and ending with inner-most barriers, clearly indicating whether or not each barrier is tamper-responsive. The tester shall reference information previously supplied in DTRs A1 and A3 where applicable. The …
Modified
p. 25
TA4.2 The tester shall provide details on how cryptographic keys are stored and managed within the device. The tester shall reference this information to the table provided in DTR A3, allowing the location of all applicable keys to be defined. The tester shall detail the testing performed to confirm the storage locations listed are correct. The tester shall reference the relevant aspects of the asset flow.
Modified
p. 25
TA4.3 The tester shall provide details on any specific protections provided by the security processor (or other processors if applicable) that are designed to obstruct obtaining or determining the values of cryptographic keys. If specific protections are unknown, the tester shall provide details on protections strongly inferred through testing.
Removed
p. 26
TA5.8 The tester shall perform preliminary side-channel analysis on the device to characterize the cryptographic algorithms used to process sensitive data and/or operate with secret keys. Utilizing characterization results and knowledge of the device physical design and software, the tester shall decide which side-channel attack paths provide the best opportunities for an attacker to compromise high-value assets. The tester shall develop side-channel analysis to explore methodologies most likely to achieve retrieval of sensitive data The tester shall develop these investigations to derive a demonstrable level of assurance consistent with any reported attack cost rating(s).
The tester shall describe any assistance provided by the vendor to ensure efficient side-channel testing•for example, command scripts or event triggers.
TA5.9 The tester shall justify the methodologies used and findings, in accordance with Appendix E. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible …
The tester shall describe any assistance provided by the vendor to ensure efficient side-channel testing•for example, command scripts or event triggers.
TA5.9 The tester shall justify the methodologies used and findings, in accordance with Appendix E. The tester shall outline why analysis parameters provide a high level of confidence that key recovery through side-channel analysis is not feasible …
Modified
p. 26 → 25
TA4.4 The tester shall:
Modified
p. 27 → 26
TA4.6 Referring to the information provided in DTR A3, the tester shall perform a review of available literature and vulnerability disclosures to confirm that the programming or in-circuit testing features of the processing elements of the device cannot be re-enabled (either temporarily or permanently). The tester shall validate all documentation provided by the vendor.
Modified
p. 27 → 26
TA4.7 If the device stores clear-text cryptographic keys within external memory, the tester shall detail the physical security methods implemented to protect this memory. Note that PCB-based tamper grids are not considered sufficient to protect clear-text cryptographic keys.
Modified
p. 27 → 26
TA4.8 The tester shall describe and cost the most feasible attack to recover cryptographic keys from the device, using the above information. The tester shall detail whether steps are based on actual testing or on assumptions and provide justification for any use of assumptions rather than actual testing. This information should include, at minimum:
Modified
p. 27 → 26
The tester is not required to perform the attack entirely but may perform all or part of the attack to verify its validity. The calculation shall be based on the methodology depicted in Appendix A. If an attack scenario can be developed that yields an attack potential of less than 35 per device for identification and initial exploitation or less than 15 per device for exploitation only, as defined in Appendix A, the vendor assertion cannot be verified. At least …
The tester is not required to perform the attack entirely but may perform all or part of the attack to verify its validity. The calculation shall be based on the methodology depicted in Appendix A. If an attack scenario can be developed that yields an attack potential of less than 35 per device for identification and initial exploitation or less than 15 per device for initial exploitation only, as defined in Appendix A, the vendor assertion cannot be verified. At …
Modified
p. 27 → 26
If the device is restricted to deployment in controlled environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, or press-fittings) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
If the device is restricted to deployment in an environment meeting at least the security of a controlled environment, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, or press-fittings) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However, removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.
Modified
p. 27 → 26
TA4.9 If the attack costing for DTR A3 was found to be less than the minimum points required for this DTR, the tester shall justify why the attack for DTR A3 cannot be used to recover cryptographic keys.
Modified
p. 28 → 31
Firmware is considered to be any code within the device that provides security protections needed to comply with these requirements. In certain instances, the test houses may request copies of source code for review of specific functions.
Firmware is considered to be any code within the device that provides security protections needed to comply with these requirements. The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions. See Appendix F, “Domain-Based Asset Flow Analysis.” HSMs used in the payments industry frequently operate in non-PCI mode, and self-tests are required to ensure the integrity of those operations.
Modified
p. 28 → 31
• Execution of periodic self-tests with a frequency of at least once each 24 hours in addition to execution after power on and after a hardware reset.
• Execution of periodic self-tests with a frequency of at least once each 24 hours in addition to pre-operational execution and after a hardware reset.
Modified
p. 28 → 31
Firmware integrity tests may include techniques such as SHA-2 or equivalent. The hash must either be cryptographically protected using a key (e.g., HMAC-SHA-2) or physically protected equivalent to a secret key. Authenticity testing must use cryptographic methods (MACs, digital signatures, or encryption). LRC, CRC, and other non-cryptographic methods and weak cryptographic methods (e.g., SHA-1, MD5) are not allowed as the primary mechanism for either authentication or integrity checking.
Firmware integrity tests may include techniques such as SHA-2 or equivalent. The hash must be cryptographically protected using a key (e.g., HMAC-SHA-2). Authenticity testing must use cryptographic methods ((H)MACs, digital signatures, or encryption). LRC, CRC, and other non- cryptographic methods and weak cryptographic methods (e.g., SHA-1, MD5) are not allowed as the primary mechanism for either authentication or integrity checking.
Modified
p. 28 → 31
Internal generation of a cryptographic signature is valid right after firmware update, assuming it complies with Requirement B4; it is also valid for devices that do not allow for software updates outside of the factory.
Internal generation of a cryptographic signature is valid right after firmware update, assuming it complies with Requirement B3; it is also valid for devices that do not allow for software updates outside of the factory.
Removed
p. 29
Power-up self-tests shall be performed when the cryptographic module is powered up. Conditional self-tests shall be performed when an applicable security function or operation is invoked (i.e., security functions for which self-tests are required). A cryptographic module may perform other power-up or conditional self-tests in addition to the tests specified below.
TB1.1 The tester shall examine the vendor’s response to Section B1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B1 of the PCI PTS HSM Modular Security Requirements for consistency to verify that the device performs a self-test upon startup and at least once per day to check the firmware of the device, the software of the device controller, the security mechanisms for signs of tampering, and whether the device is in a compromised state; and that in the event of a failure, the relevant component’s functionality fails in a secure manner. The tester …
TB1.1 The tester shall examine the vendor’s response to Section B1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B1 of the PCI PTS HSM Modular Security Requirements for consistency to verify that the device performs a self-test upon startup and at least once per day to check the firmware of the device, the software of the device controller, the security mechanisms for signs of tampering, and whether the device is in a compromised state; and that in the event of a failure, the relevant component’s functionality fails in a secure manner. The tester …
Modified
p. 29 → 32
• The authenticity checking of firmware
•either internally and according toB4 or externally using appropriate procedures within a secured environment under the vendor’s control•is performed whenever the firmware is established in that secure area; and
•either internally and according to
• The authenticity checking of firmware
•either internally and according to B3 or externally using appropriate procedures within a secured environment under the vendor’s control•is performed whenever the firmware is established in that secure area; and
•either internally and according to B3 or externally using appropriate procedures within a secured environment under the vendor’s control•is performed whenever the firmware is established in that secure area; and
Modified
p. 29 → 32
• The effort to deliberately modify or replace the firmware or parts of it in order to get access to sensitive information (access to the memory device) must be addressed as an attack scenario under Requirements A1, A3, and A5 and meet the respective attack potentials; and
• The effort to deliberately modify or replace the firmware or parts of it in order to get access to sensitive information (access to the memory device) must be addressed as an attack scenario under Requirements A1, A3, and A4 and meet the respective attack potentials; and
Modified
p. 29 → 32
When firmware is externally authenticated, the level of security shall be of the same level as for key- injection facilities.
When firmware is externally authenticated, the level of security shall be of the same level as for key-injection facilities.
Modified
p. 29 → 32
Periodic self-tests may be automatically or externally triggered, but the device must assure that the tests occur within a 24-hour cycle. Resetting, rebooting, and power cycling are acceptable means for the on-demand initiation of power-up tests.
Periodic self-tests shall be performed automatically and repeatedly within a defined time period, without external input or control. The device must assure that the tests occur within a 24-hour cycle. Resetting, rebooting, and power cycling are acceptable means for the on-demand initiation of pre-operational or conditional tests.
Modified
p. 29 → 33
TB1.1 The tester shall describe the boot chain of the device. The tester shall Include how initial machine code is loaded and executed by the processing elements, and how any subsequent firmware modules are sequenced, loaded, and executed, up to and including software modules used for processing sensitive data. The tester shall reference the relevant aspects of the asset flow.
Modified
p. 29 → 33
TB1.2 The tester shall verify that the device performs self-tests upon startup and on a periodic basis at least once per day to check firmware and security mechanisms for signs of tampering, and whether the device is in a compromised state. The tester shall activate the self-test(s) and look for the result of the self-test(s) as shown by the device.
Modified
p. 29 → 33
TB1.3 The tester shall verify that the device self-tests are able to detect failures and in doing so, fail in a secure manner. The vendor shall provide evidence of testing that confirms the relevant component fails securely in the event of self-test failure.
Modified
p. 30 → 33
TB1.5 The tester shall review the source code of the device to confirm what algorithms and keys are used to perform the self-test functions that are implemented by the firmware of the device. The tester shall confirm that any register settings required to activate hardware-based self-test functions are correctly assigned.
Modified
p. 30 → 33
TB1.6 The tester shall review the source code of the device to confirm how it is ensured that the self- test process(es) are repeated every 24 hours, or through an automatic continuous error- checking built into the hardware.
Modified
p. 30 → 33
TB1.7 The tester shall note what methods are implemented to authenticate the cryptographic keys of the device, to ensure that they have not been modified after loading.
Modified
p. 30 → 33
TB1.8 The tester shall detail the processes performed by the device if one or more of the self-tests fail. The tester shall confirm this through source-code review.
Modified
p. 30 → 33
•for example, by adding columns or additional notes
•to present any additional
TB1.9 From the previous descriptions, the tester shall complete the following table indicating the process used to authenticate the firmware images during each stage of the booting process. The tester shall include all self-tests for all processing elements within the device (as detailed in DTR A3). The tester shall adapt the table as necessary
•for example, by adding columns or additional notes
•to present any additional information.
•for example, by adding columns or additional notes
•to present any additional information.
Modified
p. 30 → 34
TB1.11 The tester shall verify that the device performs the following pre-operational self-tests:
Modified
p. 30 → 34
a) Cryptographic algorithm known-answer tests A cryptographic algorithm test using a known answer shall be conducted for all cryptographic functions (e.g., encryption, decryption, authentication, and random number generation) of each approved cryptographic algorithm implemented by a cryptographic module. A known-answer test involves operating the cryptographic algorithm on data for which the correct output is already known and comparing the calculated output with the previously generated output (the known answer). If the calculated output does not equal the known answer, the …
a) Cryptographic algorithm test A test using a known answer shall be conducted for all cryptographic functions (e.g., encryption, decryption, authentication, and random number generation) of each approved cryptographic algorithm implemented by a cryptographic module. A known-answer test involves operating the cryptographic algorithm on data for which the correct output is already known and comparing the calculated output with the previously generated output (the known answer). If the calculated output does not equal the known answer, the known-answer test shall …
Modified
p. 30 → 34
Cryptographic algorithms whose outputs vary for a given set of inputs (e.g., the Digital Signature Algorithm) shall be tested using a known-answer test or shall be tested using a pair-wise consistency test (specified below). Message digest algorithms shall have an independent known-answer test or the known-answer test shall be included with the associated cryptographic algorithm test (e.g., the Digital Signature Standard).
Cryptographic algorithms whose outputs vary for a given set of inputs (e.g., the Digital Signature Algorithm) shall be tested using a known-answer test or shall be tested using a pair-wise consistency test (specified below). Message digest algorithms shall have an independent known-answer test, or the known-answer test shall be included with the associated cryptographic algorithm test (e.g., the Digital Signature Standard).
Removed
p. 31
b) Software/firmware authenticity and integrity test A software/firmware integrity test using an error detection code (EDC) or approved authentication technique (e.g., an approved message authentication code or digital signature algorithm) shall be applied to all validated software and firmware components within a cryptographic module when the module is powered up.
If the calculated result does not equal the previously generated result, the software/firmware test shall fail.
If the calculated result does not equal the previously generated result, the software/firmware test shall fail.
Modified
p. 31 → 34
• The known-answer test may be omitted,
• The known-answer test may be omitted;
Modified
p. 31 → 34
• The outputs of two implementations shall be continuously compared, and
• The outputs of two implementations shall be continuously compared; and
Modified
p. 31 → 35
d) Critical functions tests (e.g., RAM test) Other security functions critical to the secure operation of a cryptographic module shall be tested as part of the pre-operational tests.
Modified
p. 31 → 35
Documentation shall specify all security functions critical to the secure operation of a cryptographic module and shall identify the applicable power-up tests performed by the module.
Documentation shall specify all security functions critical to the secure operation of a cryptographic module and shall identify the applicable pre-operational tests performed by the module.
Modified
p. 31 → 35
TB1.12 The tester shall induce the pre-operational self-tests and, if applicable, view any status provided by the device to verify that the self-tests executed successfully.
Modified
p. 31 → 35
TB1.13 The tester shall verify that the device automatically performs the following continuous or periodic self-tests:
Modified
p. 31 → 35
a) Cryptographic algorithm known-answer tests
a) Cryptographic algorithm tests
Modified
p. 31 → 35
b) Software/firmware authenticity and integrity test
b) Software/firmware integrity test
Modified
p. 31 → 35
e) Other self-tests that are performed at power-up and on demand TB1.16 If applicable, the tester shall induce the periodic self-tests and, if applicable, view any status.
e) Other self-tests that are performed pre-operation and on demand TB1.14 If applicable, the tester shall induce the periodic self-tests and, if applicable, view any status.
Modified
p. 31 → 35
TB1.15 The tester shall verify that the device performs the following conditional self-tests where applicable, when the conditions specified exists:
Modified
p. 31 → 36
b) Pairwise consistency tests If a cryptographic module generates public or private keys, the following pair-wise consistency tests for every pair of generated public and private keys shall be performed:
Modified
p. 31 → 36
• If the keys are used to perform key transport, the public key shall encrypt a plaintext value. The resulting ciphertext value shall be compared to the original plaintext value. If the two values are equal, the test shall fail. If the two values differ, the private key shall be used to decrypt the ciphertext and the resulting value shall be compared to the original plaintext value. If the two values are not equal, the test shall fail.
• If the keys are used to perform key transport, the public key shall encrypt a clear- text value. The resulting ciphertext value shall be compared to the original clear-text value. If the two values are equal, the test shall fail. If the two values differ, the private key shall be used to decrypt the ciphertext and the resulting value shall be compared to the original clear-text value. If the two values are not equal, the test shall fail.
Removed
p. 32
b) Manual key-entry test If cryptographic keys or key components are manually entered into a cryptographic module, or if error on the part of the human operator could result in the incorrect entry of the intended key, the following manual key entry tests shall be performed:
• An approved authentication technique (e.g., an approved message authentication code, digital signature algorithm, or HMAC) shall be applied to all validated software and firmware components when the components are externally loaded into a cryptographic module.
• The calculated result shall be compared with a previously generated result. If the calculated result does not equal the previously generated result, the software/firmware load test shall fail.
• An approved authentication technique (e.g., an approved message authentication code, digital signature algorithm, or HMAC) shall be applied to all validated software and firmware components when the components are externally loaded into a cryptographic module.
• The calculated result shall be compared with a previously generated result. If the calculated result does not equal the previously generated result, the software/firmware load test shall fail.
Modified
p. 32 → 36
• If the keys are used to perform key agreement, the arithmetic validity of the keys shall be tested by verifying the correct mathematical relationship between the public key and private key values.
• If the keys are used to perform SSP agreement, the arithmetic validity of the keys shall be tested by verifying the correct mathematical relationship between the public key and private key values.
Modified
p. 32 → 36
- The SSPs or key components shall have an error-detection code (EDC) applied or shall be entered using duplicate entries.
Modified
p. 32 → 36
- If an EDC is used, the EDC shall be at least 16 bits in length.
Modified
p. 32 → 36
- If the EDC cannot be verified, or the duplicate entries do not match, the test shall fail.
Modified
p. 32 → 36
d) Software/firmware load test If software or firmware components can be externally loaded into a cryptographic module, the following software/firmware load tests shall be performed:
Modified
p. 32 → 37
e) Continuous random number generator test If a cryptographic module employs RNGs in an approved mode of operation, the module shall perform the following continuous random number generator test on each RNG that tests for failure to a constant value.
Modified
p. 32 → 37
- If each call to an RNG produces blocks of n bits (where n > 15), the first n-bit block generated after power-up, initialization, or reset shall not be used, but shall be saved for comparison with the next n-bit block to be generated. Each subsequent generation of an n-bit block shall be compared with the previously generated block. The test shall fail if any two compared n-bit blocks are equal.
Modified
p. 32 → 37
- If each call to an RNG produces fewer than 16 bits, the first n bits generated after power-up, initialization, or reset (for some n > 15) shall not be used but shall be saved for comparison with the next n generated bits. Each subsequent generation of n bits shall be compared with the previously generated n bits. The test fails if any two compared n-bit sequences are equal.
Modified
p. 33 → 37
f) Bypass test If a cryptographic module implements a bypass capability where the services may be provided without cryptographic processing (e.g., transferring clear text through the module), the following bypass tests shall be performed to ensure that a single point of failure of module components will not result in the unintentional output of clear text:
Modified
p. 33 → 37
- A cryptographic module shall test for the correct operation of the services providing cryptographic processing when a switch takes place between an exclusive bypass service and an exclusive cryptographic service.
Modified
p. 33 → 37
- If a cryptographic module can automatically alternate between a bypass service and a cryptographic service, providing some services with cryptographic processing and some services without cryptographic processing, the module shall test for the correct operation of the services providing cryptographic processing when the mechanism governing the switching procedure is modified (e.g., an IP address source/destination table).
Modified
p. 33 → 37
- Documentation shall specify the mechanism or logic governing the switching procedure.
Modified
p. 33 → 38
- Other security functions critical to the secure operation of a cryptographic module performed under specific conditions shall be tested as conditional tests.
Modified
p. 33 → 38
Documentation shall specify all security functions critical to the secure operation of a cryptographic module and shall identify the applicable conditional tests performed by the module.
- Documentation shall specify all security functions critical to the secure operation of a cryptographic module and shall identify the applicable conditional tests performed by the module.
Modified
p. 33 → 38
TB1.16 The tester shall induce the conditional self-tests and, if applicable, view any status provided by the device to verify that self-tests executed successfully.
Modified
p. 33 → 38
TB1.20 The tester shall present sufficient evidence and/or references for the above, for compliance to this DTR.
Removed
p. 34
TB2.1 The tester shall examine the vendor’s response to Section B2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B2 of the PCI PTS HSM Modular Security Requirements for consistency to verify that the relevant component’s functionality shall not be influenced by logical anomalies such as (but not restricted to): unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying invalid parameters or data that could result in the relevant component’s outputting clear-text sensitive information. The tester shall summarize the responses.
TB2.2 The tester shall examine and cite any relevant documentation
•such as a user guide, the specification of the relevant device component’s logical structure, the interface specification, the software-design rules and specifications, API documentation, or the software implementation submitted by the vendor
•to verify that it supports the vendor responses.
TB2.2 The tester shall examine and cite any relevant documentation
•such as a user guide, the specification of the relevant device component’s logical structure, the interface specification, the software-design rules and specifications, API documentation, or the software implementation submitted by the vendor
•to verify that it supports the vendor responses.
Modified
p. 34 → 39
All interfaces and associated communication methods of the device must be assessed. The interfaces must be documented and assessed regardless of whether they are used for or have access to card data. Sufficient evidence must be provided to demonstrate the validity of laboratory assessments.
All interfaces and associated communication methods of the device must be assessed without exception to ensure that no interface can be abused or used as an attack vector. Specifically, this includes any physical, logical, or application interface that is executed within the device with sufficient privilege to allow for direct interface to sensitive assets within the device (should that protocol be compromised in some way). The interfaces must be documented and assessed regardless of whether they are used for or …
Modified
p. 34 → 39
TB2.1 The tester shall describe the vendor’s measures that ensure that the device’s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.
Modified
p. 34 → 39
TB2.2 The tester shall note the programming languages in which the device's firmware source code is written for each of the security processing elements (as detailed in DTR A3).
Modified
p. 34 → 39
TB2.3 The tester shall detail the type, version, capabilities, and configuration of the operating system(s) used on each of the device’s security-processing elements (as detailed in DTR A3).
Modified
p. 34 → 40
TB2.5 If the device includes command-execution interfaces or parsers: The tester shall detail how each of the above interfaces is configured to accept commands•for example, whether a command executive is used, or other methods are used to parse input commands. The tester shall define which common functionalities exist between interfaces to determine which test approaches may be applied in common to more than one interface.
Modified
p. 34 → 40
TB2.6 The tester shall detail in an appendix to the evaluation report a complete list of all APIs as defined by the vendor that are provided on each of the logical interfaces of the device.
Modified
p. 35 → 40
TB2.8 For systems that are designed to execute non-firmware applications, the vendor shall provide a test application containing a buffer-overflow vulnerability to be run into the device, together with the application’s source code. The tester shall run the application and determine whether the device fails securely.
Modified
p. 35 → 40
TB2.10 The tester shall execute a vulnerability assessment, public vulnerability check, and/or testing, to identify vulnerabilities associated with the interfaces and associated communication methods of the device.
Modified
p. 35 → 40
TB2.11 The tester shall perform fuzzing of the device’s security-relevant interfaces in order to uncover logical anomalies.
Modified
p. 35 → 41
TB2.12 The tester shall identify all command interpreters within the firmware, including all command interpreters within the HSM software which implement commands that can be invoked from the host system. If command interpreters are called, the tester shall describe and justify why a command or environment cannot be manipulated to perform unauthorized functions.
Modified
p. 35 → 41
TB2.13 The tester may perform any additional tests necessary to validate the device’s property. The vendor shall provide any necessary test support to access and use the interfaces under test.
Removed
p. 36
Firmware is considered to be any code within the device that provides security protections needed to comply with PCI requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under PCI requirements.
TB3.1 The tester shall examine the response to Section B3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B3 of the PCI PTS HSM Modular Security Requirements for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how firmware certification is robust. The tester shall summarize the responses.
TB3.2 The tester shall examine the support documentation submitted by the device vendor. The documents should be representative of configuration control process that can be audited. These documents shall be referenced. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; …
TB3.1 The tester shall examine the response to Section B3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B3 of the PCI PTS HSM Modular Security Requirements for consistency relating to the firmware documentation and certification process. The vendor responses should clearly indicate how firmware certification is robust. The tester shall summarize the responses.
TB3.2 The tester shall examine the support documentation submitted by the device vendor. The documents should be representative of configuration control process that can be audited. These documents shall be referenced. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; …
Removed
p. 37
TB3.9 The tester shall confirm that
•and summarize how
•the certification process includes checking of all code that executes in all processing elements as listed in DTR A3.
TB3.10 The tester shall confirm that
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the device firmware.
TB3.11 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing is performed by a person who was not involved in the authorship of the device code.
TB3.12 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing be performed after every security-relevant change, and before the firmware is released to production.
TB3.13 The tester shall confirm and describe, via documentation review, that the certification process is designed to result in an auditable …
•and summarize how
•the certification process includes checking of all code that executes in all processing elements as listed in DTR A3.
TB3.10 The tester shall confirm that
•and summarize how
•the process described above includes checking sources of vulnerability disclosure (such as the national vulnerability database) for public vulnerabilities that may apply to the device firmware.
TB3.11 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing is performed by a person who was not involved in the authorship of the device code.
TB3.12 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing be performed after every security-relevant change, and before the firmware is released to production.
TB3.13 The tester shall confirm and describe, via documentation review, that the certification process is designed to result in an auditable …
Removed
p. 39
TB4.1 The tester shall examine the response to Section B4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B4 of the PCI PTS HSM Modular Security Requirements for consistency relating to the authentication procedures for firmware updates. The vendor responses should clearly indicate how firmware updates are securely implemented. The tester shall summarize the responses.
TB4.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to firmware updates to determine whether it supports the assertions made by the vendor.
TB4.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to firmware updates to determine whether it supports the assertions made by the vendor.
Modified
p. 39 → 42
The firmware and application version numbers must be available via display and/or printing during startup or on request. This shall be illustrated by photographic evidence provided in the evaluation report.
The firmware and application version numbers must be available via display, API command, and/or printing during startup or on request. This shall be illustrated by photographic or screen-capture- based evidence provided in the evaluation report.
Modified
p. 39 → 43
TB3.6 For each of the processing elements listed in DTR A3, the tester shall complete the following table. Where different parts of the code can be updated independently (for example, boot code, main firmware, etc.), or if one part of the firmware cannot be updated, the tester shall ensure that this is detailed in the table as well. The tester shall reference the relevant aspects of the asset flow.
Modified
p. 40 → 43
TB3.7 The tester shall review the source code of the device to confirm that the firmware-authentication methods are implemented correctly as noted above, and that the authentication is performed within the secure firmware of the device. This evaluation activity should be focused on relevant security-critical sections of the source code, to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 40 → 43
TB3.8 If the device allows for loading of multiple types of code (for example, firmware for security processor and application code), the tester shall detail how the various types of update images are differentiated from one another to prevent one type of image being incorrectly loaded into the wrong processing element/location. The tester shall ensure all authentication methods and image types are contained in the table above.
Modified
p. 40 → 43
TB3.9 If (H)MAC method(s) are used for firmware authentication, the tester shall confirm through source-code review that the method used to compare the firmware-authentication block does not leak timing information•for example, the “C” memcmp() function is not used. This evaluation activity should be focused on relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 40 → 43
TB3.10 If a CBC MAC is used for firmware authentication, the tester shall detail what methods are used to mitigate vulnerabilities when authenticating variable-length data.
Modified
p. 40 → 44
b) Change a single bit in the authentication block of the image, and confirm that this modified image is rejected when loaded into the device.
b) Change a single bit in the authentication block of the image and confirm that this modified image is rejected when loaded into the device.
Modified
p. 40 → 44
c) Change a single bit in the firmware block of the image, and confirm that this modified image is rejected when loaded into the device.
c) Change a single bit in the firmware block of the image and confirm that this modified image is rejected when loaded into the device.
Modified
p. 40 → 44
TB3.12 The tester shall confirm how any public or private/secret keys are loaded into the device during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the device) and how it is ensured that these must be changed in deployed devices.
Removed
p. 41
TB4.1.1 The tester shall examine the vendor’s response to Section B4.1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B4.1 of the PCI PTS HSM Modular Security Requirements for consistency to verify that the device enforces that only authenticated applications and application/configuration updates can be loaded onto the device. The vendor responses should clearly indicate how software authenticity is assured. The tester shall summarize the responses TB4.1.2 The tester shall examine and cite any additional documentation (i.e., specifications, schematics, block diagrams, etc.) containing information that relates to application loading and application/configuration updates, including remote access, to determine whether it supports the assertions made by the vendor.
Examples of acceptable hashing algorithms include SHA-256, SHA-384 and SHA-512. MD5 and SHA-1 are not allowed for use.
Examples of acceptable hashing algorithms include SHA-256, SHA-384 and SHA-512. MD5 and SHA-1 are not allowed for use.
Modified
p. 41 → 45
Applications are considered to be any code that can be loaded onto the device that is not firmware. Other code that exists within the device that does not provide security, and cannot impact security, is not considered.
Applications are considered to be any code or scripts that can be loaded onto the device that is not firmware. Other code that exists within the device that does not provide security, and cannot impact security, is not considered. See Appendix F, “Domain-Based Asset Flow Analysis.” The authentication must not be performed by a component of lesser protection strength than the one for which the access is intended, OR the authentication must be performed by the target component.
Modified
p. 41 → 45
TB3.1.1 The tester shall determine by which component the authentication is performed.
Modified
p. 41 → 45
•and if applicable, software and/or configuration updates
•and that the authentication is performed by an appropriate component
TB3.1.2 The tester shall determine the rank of protection strength for the component involved in application loads
•and if applicable, software and/or configuration updates
•and that the authentication is performed by an appropriate component TB3.1.3 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes, along with examples of acceptable hashing algorithms, are stated in Appendix D.
•and if applicable, software and/or configuration updates
•and that the authentication is performed by an appropriate component TB3.1.3 The tester shall examine the vendor-supplied documentation to verify that the controls provide for unique accountability and utilize key sizes appropriate for the algorithm(s) in question. Examples of appropriate algorithms and minimum key sizes, along with examples of acceptable hashing algorithms, are stated in Appendix D.
Modified
p. 42 → 46
b) Change a single bit in the authentication block of the image, and confirm that this modified image is rejected when loaded into the device.
b) Change a single bit in the authentication block of the image and confirm that this modified image is rejected when loaded into the device.
Modified
p. 42 → 46
TB3.1.6 If (H)MAC method(s) are used for application authentication, the tester shall confirm through source-code review that the method used to compare the application-authentication block does not leak timing information•for example, the “C” memcmp() function is not used. This evaluation activity should be focused on relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 42 → 46
TB3.1.7 If a CBC MAC is used for application authentication, the tester shall detail what methods are used to mitigate vulnerabilities in this method when used to authenticate variable-length data.
Modified
p. 42 → 46
TB3.1.9 For each of the methods of authentication the tester shall obtain a correctly authenticated application image and:
Modified
p. 42 → 46
c) Change a single bit in the application block of the image, and confirm that this modified image is rejected when loaded into the device.
c) Change a single bit in the application block of the image and confirm that this modified image is rejected when loaded into the device.
Modified
p. 42 → 46
TB3.1.10 The tester shall confirm how any public or private/secret keys are loaded into the device during manufacturing. The tester shall specifically note whether any default values are installed (for example, default public certificates hard-coded into the firmware of the device) and how it is ensured that these must be changed in deployed devices.
Removed
p. 43
TB5.1 The tester shall examine the vendor’s response to Section B5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B5 of the PCI PTS HSM Modular Security Requirements for consistency to verify that the device provides secure interfaces that are kept logically separate. The tester shall summarize the responses TB5.2 The tester shall examine and cite any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the logical interfaces to verify that it supports the assertions made by the vendor. Documentation should indicate that the device is designed to distinguish between commands and data input, and status and data output.
Modified
p. 43 → 47
• All data (except control data entered via the control input interface) that is input to and processed by a cryptographic module (including plaintext data, ciphertext data, cryptographic keys and CSPs, authentication data, and status information from another module) shall enter via the "data input" interface.
• All data (except control data entered via the control input interface) that is input to and processed by a cryptographic module (including clear-text data, ciphertext data, cryptographic keys and CSPs, authentication data, and status information from another module) shall enter via the "data input" interface.
Modified
p. 43 → 47
• All data (except status data output via the status output interface) that is output from a cryptographic module (including plaintext data, ciphertext data, cryptographic keys and CSPs, authentication data, and control information for another module) shall exit via the "data output" interface. All data output via the data output interface shall be inhibited when an error state exists and during self-tests.
• All data (except status data output via the status output interface) that is output from a cryptographic module (including clear-text data, ciphertext data, cryptographic keys and CSPs, authentication data, and control information for another module) shall exit via the "data output" interface. All data output via the data output interface shall be inhibited when an error state exists and during self-tests.
Modified
p. 43 → 47
TB4.2 The tester shall review vendor documentation to verify that the device distinguishes between data and control for inputs and also between data and status for outputs. To provide evidence that the device distinguishes between commands and data inputs, the tester shall verify that the device responds with error messages or ignores inputs when erroneous commands and data are input.
Removed
p. 44
TB6.1 The tester shall examine the vendor’s response to Section B6 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B6 of the PCI PTS HSM Modular Security Requirements to verify:
• That sensitive information shall not be present any longer or used more often than strictly necessary; and
• That the device automatically clears its internal buffers when the transaction is completed, the device has timed out, or the device recovers from an error state. The vendor must specify the states “completion of transaction” and “timeout” and “error state” define the appropriate actions.
The tester shall summarize the responses.
TB6.2 The tester shall examine and cite any relevant documentation submitted by the vendor, including vendor test results for inspections of internal buffers, the user guide, the software specification, or the software implementation, to verify that it supports the vendor responses.
TB6.3 The tester will verify that and summarize how …
• That sensitive information shall not be present any longer or used more often than strictly necessary; and
• That the device automatically clears its internal buffers when the transaction is completed, the device has timed out, or the device recovers from an error state. The vendor must specify the states “completion of transaction” and “timeout” and “error state” define the appropriate actions.
The tester shall summarize the responses.
TB6.2 The tester shall examine and cite any relevant documentation submitted by the vendor, including vendor test results for inspections of internal buffers, the user guide, the software specification, or the software implementation, to verify that it supports the vendor responses.
TB6.3 The tester will verify that and summarize how …
Modified
p. 44 → 48
This applies to sensitive data, such as passwords, plaintext cryptographic keys outside of the crypto- processor, and clear PIN values.
This applies to sensitive data, such as passwords/authentication codes, clear-text cryptographic keys outside of the crypto-processor, and clear-text PIN values.
Modified
p. 44 → 48
•and summarize how
TB5.2 The tester shall review the source code of the device and confirm that
•and summarize how
•and summarize how
Modified
p. 44 → 48
TB5.3 The tester shall detail the method used by the vendor to ensure that this buffer-clearing code/function cannot be removed by compiler optimizations or other means of code optimization, if employed by the vendor.
Modified
p. 44 → 48
TB5.4 The tester shall detail the testing performed to verify that buffer-clearing code/function is robust. This requires assistance from the vendor and may involve, for example:
Modified
p. 45 → 48
TB5.6 The tester shall perform any additional tests necessary to verify that all data is automatically cleared including when the transaction is completed, the device has timed out, or the device recovers from an error state for instance, by performing a partial simulated transaction to verify the behavior at time-out, or in general by entering the states that have been defined by the vendor under TB5.1.
Modified
p. 46 → 49
Authentication shall use dual-control techniques when manually entering unprotected sensitive information into the device through a secure user interface, or cryptographic techniques when electronically transferring protected data into the device. The use of other techniques to access sensitive services results in the device being unable to use previously existing keying material. The device requires the cooperation of at least two separately authenticated operators for administration services not normally available, such as plaintext or split knowledge of manual CSP loading or …
Authentication shall require dual-control techniques when manually entering unprotected sensitive information into the device through a secure user interface, or cryptographic techniques when electronically transferring protected data into the device. The use of other techniques to access sensitive services results in the device being unable to use previously existing keying material. The device requires the cooperation of at least two separately authenticated operators for administration services not normally available, such as clear text or split knowledge of manual CSP loading …
Modified
p. 46 → 49
“CSPs” are critical security parameters, such as cryptographic keys and passwords.
“CSPs” are critical security parameters, such as cryptographic keys and passwords/authentication codes.
Modified
p. 46 → 49
• Any function used to input or output key components does not operate until at least two different passwords have been entered.
• Any function used to input or output key components does not operate until at least two different passwords/authentication codes have been entered.
Modified
p. 46 → 49
The functionality implemented within the device is such that there is no feasible way in which plaintext secret information (e.g., cryptographic keys), or secret information enciphered under other than the legitimate key, can be obtained from the device, except in an authorized manner PINs or passwords used for authentication are at least seven characters in length.
The functionality implemented within the device is such that there is no feasible way in which clear- text secret information (e.g., cryptographic keys), or secret information enciphered under other than the legitimate key, can be obtained from the device, except in an authorized manner Passwords/authentication codes used for authentication are at least seven characters or an equivalent strength.
Removed
p. 47
TB7.1 The tester shall examine the vendor’s response to Section B7 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B7 of the PCI PTS HSM Modular Security Requirements for consistency relevant to B7. The vendor responses should clearly indicate how sensitive services are protected. The tester shall summarize the responses.
TB7.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) submitted by the vendor to verify that it supports the vendor assertions with regard to the control of sensitive services TB7.3 The tester shall verify from vendor documentation and summarize that the vendor has identified all sensitive services, data, and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode …
TB7.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) submitted by the vendor to verify that it supports the vendor assertions with regard to the control of sensitive services TB7.3 The tester shall verify from vendor documentation and summarize that the vendor has identified all sensitive services, data, and secure modes. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords. The tester shall verify from vendor documentation that sensitive services are authenticated and are entered, used, and exited securely and that mode …
Modified
p. 47 → 50
• Changing of passwords or data that enable the device to enter a sensitive state;
• Changing of passwords/authentication codes or data that enable the device to enter a sensitive state;
Modified
p. 47 → 50
• Configuring or modifying the Security Policy examined in C1 and B11.
• Configuring or modifying the security policy examined in C1 and B10.
Modified
p. 47 → 50
TB6.2 The tester shall verify from vendor documentation and from functional testing that sensitive services require authentication.
Modified
p. 47 → 50
TB6.3 The tester shall verify from vendor documentation and from functional testing that entering and exiting sensitive services does not reveal or otherwise affect sensitive information.
Modified
p. 47 → 50
TB6.4 The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions (for example, from operational to maintenance) do not reveal or otherwise affect sensitive information.
Modified
p. 47 → 50
TB6.5 The tester shall determine that for each authentication attempt, the probability is less than one in one million that random attempts for authenticating both operators will succeed. For multiple consecutive attempts in a one-minute period, the probability is less than one in one hundred thousand that a random attempt will succeed.
Modified
p. 47 → 50
TB6.6 The tester shall attempt to perform any other services listed in this section and verify that each service requires the cooperation of at least two separately authenticated operators for administration services not normally available, such as clear text or split knowledge of manual CSP loading or CSP output, enabling or disabling device security functions, or the modification of authentication data.
Modified
p. 47 → 50
TB6.7 The tester shall verify that placing the device into a diagnostic or special test mode does not allow the determination of a secret key or other secret information.
Modified
p. 47 → 50
TB6.8 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes authentication procedures for the manual entry or output of enciphered CSPs to determine whether it supports the assertions made by the vendor.
Modified
p. 47 → 50
TB6.9 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes sensitive service limits to determine whether it supports the assertions made by the vendor.
Modified
p. 48 → 50
TB6.11 The tester shall verify that the vendor documentation is consistent and provides sound rationale for the service limits set by the vendor.
Modified
p. 48 → 51
TB6.13 If mode transitions require input by a separate interface device, such as a key loader or other vendor-supplied interface device, document the mechanism(s) and methodology used.
Modified
p. 48 → 51
TB6.14 The tester shall detail in the table below all methods that can be used to load cryptographic keys into the device. This shall include situations in which there is more than one loading method for any particular key, and in which different cryptographic keys may have different methods of loading. The tester shall include any APIs provided by the firmware that allow for the loading of cryptographic keys (reference the API list provided as part of DTR B2).
Modified
p. 48 → 51
Cryptographic key Method of loading per TB7.7 Authentication MFK Components through external device Two seven-character passwords through key loader Encrypted under Public Key Provided by encryption Internally generated Operator authentication provided via chip cards Authentication Key Embedded in firmware Two eight-character passwords required to operate firmware loading TB7.17 The tester shall justify why each of the methods that can be used to load cryptographic keys enforces both dual control and split knowledge.
Cryptographic Method of loading per Authentication MFK Components through external device Two seven-character passwords through key loader Encrypted under Public Key Provided by encryption Internally generated Operator authentication provided via chip cards Authentication Key Embedded in firmware Two eight-character passwords required to operate firmware loading TB6.15 The tester shall justify why each of the methods that can be used to load cryptographic keys enforces both dual control and split knowledge.
Modified
p. 48 → 51
TB6.17 Where public keys are loaded into the device in a non-secure environment•for example, during firmware loading•the tester shall justify why dual control is maintained and alteration or manipulation of the public key value(s) is not possible.
Modified
p. 48 → 51
TB6.18 The tester shall detail any other sensitive services offered by the device and detail the authentication provided for these services. The tester shall justify how this ensures dual control is provided for all sensitive services.
Modified
p. 49 → 52
TB6.20 The tester shall attempt to load cryptographic keys or components into the device without changing the default values of the passwords/authentication codes. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
Modified
p. 49 → 52
TB6.21 The tester shall attempt to set the passwords/authentication codes of the device to a value that is less than seven characters or an equivalent strength. The tester shall detail the results. The requirements of this DTR are not met if this can be done.
Removed
p. 50
TB8.1 The tester shall examine the vendor’s response to Section B8 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B8 of the PCI PTS HSM Modular Security Requirements for consistency relevant to B8. The vendor responses should clearly indicate how key entry is performed using accepted techniques. The tester shall summarize the responses.
TB8.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) submitted by the vendor that describes the entry of keying material to verify that it supports the assertions made by the vendor.
TB8.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) submitted by the vendor that describes the entry of keying material to verify that it supports the assertions made by the vendor.
Modified
p. 50 → 53
Key Form Manual Direct Network Plaintext keys No Yes No Plaintext key components Yes Yes No Enciphered keys/components Yes Yes Yes
Key Form Manual Direct Network Clear-text keys No Yes No Clear-text key components Yes Yes No Enciphered keys/components Yes Yes Yes Key entry may be implemented in the following ways:
Modified
p. 50 → 53
a) Manual (e.g., key-component entry via a key pad);
a) Manual (e.g., key-component entry via a keypad);
Modified
p. 50 → 53
External SCDs (secure key loaders or other interface devices) used for loading plaintext secret or private keys or their components must either be approved against the PCI PTS HSM Modular Security Requirements or be compliant to the requirements for devices with key-transfer and loading functionality as described in ISO 13491-2. The vendor must either provide or describe a specific, existing device that can be used for this functionality.
External SCDs (secure key loaders or other interface devices) used for loading clear-text secret or private keys or their components must either be approved against the PCI PTS HSM Modular Security Requirements or be compliant to the requirements for devices with key-transfer and loading functionality as described in ISO 13491-2. The vendor must either provide or describe a specific, existing device that can be used for this functionality.
Removed
p. 51
TB8.8 The tester shall verify that an audit log is kept by the device, the device used to perform electronic key loading, or procedurally specified in the vendor security policy. The audit log must be able to be used to track the individuals who perform plaintext key component entry.
Modified
p. 51 → 53
TB7.1 The tester shall verify the following:
Modified
p. 51 → 53
• Any plaintext keys entered uses direct techniques.
• Any clear-text keys entered uses direct techniques.
Modified
p. 51 → 53
• Any plaintext keys are directly entered without traveling through any enclosing or intervening systems.
• Any clear-text keys are directly entered without traveling through any enclosing or intervening systems.
Modified
p. 51 → 53
Clear-text key entry requires dual authentication prior to loading of the new key.
Modified
p. 51 → 53
TB7.2 The tester shall verify that the device does not allow entry of clear-text keys using manual or network techniques.
Modified
p. 51 → 54
Clear-text Key Components Entry:
Modified
p. 51 → 54
TB7.4 For clear-text key components, the tester shall verify the following:
Modified
p. 51 → 54
• Plaintext key-component entry requires the use of dual-control techniques, such that the key is entered as separate key components by the assigned key custodians. Each component requires the use of a separate PIN/password to authenticate the individual entering that specific component OR the zeroization of pre-existing secret keys within the associated key hierarchy prior to the loading of the new key•i.e., the invoking of the key- loading function/command causes the zeroization prior to the actual loading of the new …
• Clear-text key-component entry requires the use of dual-control techniques, such that the key is entered as separate key components by the assigned key custodians. Each component requires the use of a separate passwords/authentication codes to authenticate the individual entering that specific component OR the zeroization of pre-existing secret keys within the associated key hierarchy prior to the loading of the new key•i.e., the invoking of the key-loading function/command causes the zeroization prior to the actual loading of the new …
Modified
p. 51 → 54
TB7.5 The tester shall verify that the device does not allow entry of clear-text key components using network techniques.
Removed
p. 52
TB8.10 The tester shall verify that an audit log is kept by the device, the device used to perform electronic key loading, or procedurally specified in the vendor security policy. Enforce the keeping of an audit log that can be used to track the individuals who perform enciphered key entry.
Modified
p. 52 → 54
TB7.7 The tester shall verify that any enciphered key or key component input or output from the device is enciphered using an acceptable cryptographic algorithm and key size. KEKs must be at least as strong as the keys they protect.
Modified
p. 52 → 54
The tester shall verify that if asymmetric keys are used for entry or output, they are used in accordance with Annex A of the PCI PIN Security Requirements and Requirement B11.
The tester shall verify that if asymmetric keys are used for entry or output, they are used in accordance with Annex A of the PCI PIN Security Requirements and Requirement B10.
Removed
p. 53
TB9.1 The tester shall examine the vendor’s response to Section B9 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B9 of the PCI PTS HSM Modular Security Requirements for consistency relevant to B9. The vendor responses should clearly indicate why random number generation is robust. The tester shall summarize the responses.
TB9.2 The tester shall compare the vendor-supplied documentation, such as the specification of the random number generator and test documentation, submitted by the vendor to verify that it supports vendor responses.
TB9.2 The tester shall compare the vendor-supplied documentation, such as the specification of the random number generator and test documentation, submitted by the vendor to verify that it supports vendor responses.
Modified
p. 53 → 55
TB8.1 The tester shall detail the method used by the device to generate random numbers, including any seed values used, hardware systems, and software-based deterministic pseudo random number generators (DPRNG).
Modified
p. 54 → 55
TB8.3 The tester shall list all security services implemented within the device that require or rely upon the use of random data. This may include generation of padding data•for example, for use in certificates or key bundles, generation of cryptographic keys, etc.
Modified
p. 54 → 56
TB8.5 The tester shall obtain at least 128MB of random data from the device under test. This data may be supplied directly by the vendor. The tester shall detail the method used to generate this data and justify why this sufficiently replicates the way in which the RNG will be used by the device. The tester shall pass the 128MB of data through the NIST STS test program and detail the results, indicating pass and fail results and how these …
Removed
p. 55
TB10.1 The tester shall examine the vendor’s response to Section B10 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B10 of the PCI PTS HSM Modular Security Requirements for consistency relevant to B10. The vendor responses should clearly indicate the use of accepted cryptographic algorithms, modes, and key sizes. The tester shall summarize the responses.
TB10.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the implemented cryptographic algorithms to determine whether it supports the assertions made by the vendor.
TB10.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the implemented cryptographic algorithms to determine whether it supports the assertions made by the vendor.
Modified
p. 55 → 57
TB9.1 The tester shall verify that accepted algorithms are used for the following (as applicable):
Modified
p. 56 → 57
TB9.3 The tester shall verify that the mechanism used has been implemented following all guidelines of any security evaluation and independent expert review including any recommendations for associated key management and configuration of the mode of operation.
Modified
p. 56 → 57
TB9.4 For each of the accepted cryptographic algorithms implemented within the device, the tester shall verify the correct implementation of the algorithms through any of the following means:
Removed
p. 57
TDES key components shall be combined via either XOR’ing of full-length key components or via implementation of a recognized secret sharing scheme, e.g., Shamir. Private key components shall be combined using a recognized secret sharing scheme.
The device must support use of the TR-31 Key Derivation Binding Method or an equivalent key- bundling methodology. The device may optionally support, in addition, the TR-31 Key Variant Binding Method or an equivalent.
Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual-control techniques.
Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods, including the use of …
The device must support use of the TR-31 Key Derivation Binding Method or an equivalent key- bundling methodology. The device may optionally support, in addition, the TR-31 Key Variant Binding Method or an equivalent.
Devices must support TR-31 or an equivalent methodology for key loading whenever a symmetric key is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a key-injection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual-control techniques.
Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods, including the use of …
Modified
p. 57 → 58
The device must provide support for Master File Keys, whether loaded from components or internally generated, that are equivalent to or greater in strength than triple-length TDES keys. The device may optionally provide support for backwards compatibility for double-length TDES Master File Keys.
The device must provide support for AES Master File Keys (MFKs), whether loaded from components or internally generated. It may also provide support for MFKs that are equivalent to or greater in strength than triple-length TDES keys. The device may optionally provide support for backwards compatibility for double-length TDES Master File Keys.
Modified
p. 57 → 58
A device may include other key-management schemes not specified below, such as country-specific techniques when operating in PCI mode, as long as their use cannot in any way compromise the security of the PCI-compliant methods. Performing simulated transactions is not required for these key-management techniques.
A device may include other key-management schemes not specified below, such as country- specific techniques when operating in PCI mode, as long as their use cannot in any way compromise the security of the PCI-compliant methods. Performing simulated transactions is not required for these key-management techniques.
Removed
p. 58
• Be generated randomly or pseudo-randomly;
• Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source;
• Be used in the appropriate order as specified by the particular mode;
• Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and
• Cannot be unbundled for any purpose.
TB11.1 The tester shall examine the response to Section B11 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B11 of the PCI PTS HSM Modular Security Requirements for consistency relating to the method of key management in use in the device. The tester shall summarize the responses.
TB11.2 The tester shall examine and cite any relevant documentation such as a user guide or the API programmer’s guide, submitted by the vendor to …
• Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source;
• Be used in the appropriate order as specified by the particular mode;
• Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and
• Cannot be unbundled for any purpose.
TB11.1 The tester shall examine the response to Section B11 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B11 of the PCI PTS HSM Modular Security Requirements for consistency relating to the method of key management in use in the device. The tester shall summarize the responses.
TB11.2 The tester shall examine and cite any relevant documentation such as a user guide or the API programmer’s guide, submitted by the vendor to …
Modified
p. 58 → 59
Documentation must be provided demonstrating how the methodology meets these criteria.
• Interchanging any bits of the protected key block with bits from another part of the block Documentation must be provided demonstrating how the methodology meets these criteria.
Modified
p. 58 → 60
Any key calculated as a variant of another key, or derived from another key, shall be protected in a manner equivalent to or greater than the security of the original key.
Any key calculated as a variant of another key, or derived from another key, shall be protected in a manner equivalent to or greater than the security of the original key. The use of variants is not allowed for AES keys.
Modified
p. 58 → 60
• Internally generated using a random number generator compliant with B9.
• Internally generated using a random number generator compliant with B8.
Modified
p. 58 → 60
Devices are allowed to have keys that are not unique per device if these keys are used for load- balancing purposes.
Devices are allowed to have keys that are not unique per device if these keys are used for load- balancing purposes. This does not preclude cryptographic-keying relationships with POI devices or other organizations⎯for example, symmetric keys that exist both in the HSM and within another system that communicates to the HSM using that key, such as a POI device.
Modified
p. 58 → 60
TB10.2 The tester shall examine any additional documentation (e.g., user guide, API reference, design documentation, key-management specification) that describes the implemented key exchange and storage techniques to determine whether it supports the assertions made by the vendor.
Modified
p. 58 → 60
TB10.3 The tester shall verify that the loading of private and secret keys uses one or more of the following methods:
Modified
p. 59 → 61
b) For injecting plaintext secret or private keys from a key loader (which has to be some type of secure cryptographic device), either the key loader or the device or both must require two or more PINs/passwords before injecting the plaintext key into the device. (Note: This may be the entire key•if components, each component requires a separate password). These passwords are entered directly through the secure interface of the applicable device or are conveyed encrypted into the device and …
b) For injecting clear-text secret or private keys from a key loader (which has to be some type of secure cryptographic device), either the key loader or the device or both must require two or more passwords/authentication codes before injecting the clear-text key into the device. (Note: This may be the entire key•if components, each component requires a separate password/authentication code). These passwords/authentication codes are entered directly through the secure interface of the applicable device or are conveyed encrypted into …
Modified
p. 59 → 61
TB10.4 The minimum key sizes and parameters for the algorithm(s) in question that must be used for key transport, exchange or establishment are stated in Appendix D:
Modified
p. 59 → 61
If a public key technique for the remote distribution of symmetric secret keys is used, it must:
If a public-key technique for the remote distribution of symmetric secret keys related to PIN or account-data encryption is used, it must:
Modified
p. 59 → 61
a) Use public and private key lengths that are deemed acceptable for the algorithm in question (e.g., 2048-bits minimum for RSA, see also DTR B4).
a) Use public and private key lengths that are deemed acceptable for the algorithm in question (e.g., 2048-bits minimum for RSA).
Modified
p. 59 → 61
TB10.5 If used for online PIN translation, the tester shall verify that the device supports TDES and AES for online PIN translation. The tester shall perform simulated transactions for each accepted combination of key-management technique and cryptographic algorithm (TDES, AES) supported by the device (e.g., DUKPT; MK/SK and Fixed Key).
Modified
p. 59 → 61
TB10.6 The tester shall determine from vendor documentation all storage and usage locations for each key (e.g., ROM, external RAM, EPROM, processor chip, etc.) that is stored within the device and list the details in a key summary table. The tester shall reference the relevant aspects of the asset flow.
Modified
p. 59 → 61
TB10.7 The tester shall determine from vendor documentation how each key is destroyed•e.g., active or passive erasure•for all device states (power-on, power-off, sleep mode) and list the details in a key summary table.
Modified
p. 60 → 62
TB10.9 The tester shall review the API guide and operations manual of the device and confirm that this does not detail any other key-management schemes or methods that the device may use. If the device supports extensible key management for use with non-PIN transactions, the tester shall justify what prevents this from being used with PCI-based PINs, using extracts from the vendor documentation to support this claim. The tester shall provide references to all extracts used.
Modified
p. 60 → 62
TB10.10 The tester shall detail any other types of key management or cryptographic keys used by the device. This should include any keys used for firmware or application authentication, self- testing, boot strapping, remote key injection, local key injection, dual control, etc.
Modified
p. 60 → 62
TB10.11 The tester shall provide a key table for the device, accurately including all of the keys and key- management methods outlined above. This does not include keys temporarily present in the device as part of transaction processing. An example of key types in such a table is:
Modified
p. 60 → 62
Key Name Purpose/ Size (Bits) Form Factor Available Key Slots (Registers) Unique per device/ acquirer/ vendor- specific/ other (describe) How the key is identified by the device so that it is used only as Master Key Encryption of working keys (PEK, MAC) for local storage TDES 128 Acquirer 2 or 3 plaintext components One Device Designated Key Register Manufacturer Authentication Root Public Key Authentication of firmware updates RSA 2048 Manufacturer Self-signed Public Key Certificate One Vendor- Designated Key Register Manufacturer …
Key Name Purpose/ Size (Bits) Form Factor Available Key Slots (Registers) Unique per device/ acquirer/ vendor- specific/ other (describe) How the key is identified by the device so that it is used only as Master Key Encryption of working keys (PEK, MAC) for local storage TDES 128 Acquirer 2 or 3 clear-text components One Device Designated Key Register Manufacturer Authentication Root Public Key Authentication of firmware updates RSA 2048 Manufacturer Self-signed Public Key Certificate One Vendor- Designated Key Register Manufacturer …
Modified
p. 60 → 62
TB10.12 Using the key table as a reference, the tester shall note which keys are actively erased by the device during a tamper event, and which keys are not erased but instead rely upon the erasure of a KEK to prevent their subsequent misuse.
Modified
p. 60 → 62
TB10.13 Using the key table and API guide as a reference, the tester shall note which keys can be loaded by applications in clear text.
Removed
p. 61
TB11.18 The tester shall note whether the device generates any keys using an internal random number generator. The tester shall confirm through source-code review that these keys are generated using the same process validated under Requirement B9. This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 61 → 63
b) Plaintext cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used to encrypt external memory).
b) Clear-text cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used to encrypt external memory).
Modified
p. 61 → 63
TB10.15 The tester shall detail any ways in which the device generates keys from other keys, specifically:
Modified
p. 61 → 63
a) Variants are not used across different levels of the hierarchy•for example, variants of KEKs are not used to produce working keys. The only allowable exception to this requirement is the use of TR-31 2005 key bundling (for backwards compatibility).
a) Variants are not used across different levels of the hierarchy•for example, variants of KEKs are not used to produce working keys. The only allowable exception to this requirement is the use of TR 31 variant method(for backwards compatibility).
Modified
p. 61 → 63
b) The tester shall detail any key-generation methods used, and justify why these are valid key-generation functions as required by ISO11568 and ANSI X9.24.
b) The tester shall detail any key-generation methods used and justify why these are valid key-generation functions as required by ISO 11568 and ANSI X9.24.
Modified
p. 61 → 63
TB10.17 The tester shall detail the method used by the device to confirm that no one key can take the same value as any other key within the device. Through source-code review confirm the following:
Modified
p. 61 → 63
b) If key check values (KCVs) are used for this purpose, the KCVs stored are limited to six hexadecimal digits or less or they are never output from the device.
b) If key check values (KCVs) are used for this purpose, the KCVs stored are limited to values as defined in TB10.18 or they are never output from the device.
Modified
p. 61 → 63
This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
This evaluation activity should be focused on relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 61 → 63
TB10.18 Referencing the device API, user guides, and other documentation, the tester shall confirm that it is not possible to output a KCV value except as noted below.
Modified
p. 61 → 63
Note: Check values are computed by encrypting an all-zero block using the key or component as the encryption key using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). This method may be used for TDES. TDES may optionally use, and AES shall use a technique where the KCV is calculated by MACing an all-zero block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The check …
Note: Check values may be computed by two methods. TDEA may use either method. AES must only use the CMAC method. In the first method, check values are computed by encrypting an all-binary zeros block using the key or component as the encryption key, using the leftmost n-bits of the result, where n is at most 24 bits (6 hexadecimal digits/3 bytes). In the second method the KCV is calculated by MACing an all-binary zeros block using the CMAC algorithm …
Modified
p. 61 → 63
TB10.19 The tester shall note what methods are implemented to authenticate the cryptographic keys of the device to ensure that they have not been modified after loading.
Modified
p. 62 → 64
• Key length If TR-31 2005 key bundling is used, the tester shall confirm that at least one other method of key bundling is used and that this other method does not have the KEK and MAC keys related as variants.
• Key length If TR 31 and/or X9.143 key-block variant method is used, the tester shall confirm that at least one other method of key blocks is used and that this other method does not have the KEK and MAC keys related as variants.
Modified
p. 62 → 64
TB10.21 The tester shall confirm that any key-block key can only be used for that purpose and cannot be used as a “generic” master or working key, as part of a non-bundled key-management scheme.
Modified
p. 62 → 64
TB10.22 For any methods that rely on the use of TDES full-length key components for enforcing split knowledge, the tester shall attempt to load all but one of the components as an all-zero value. If this does not succeed, the tester shall attempt to load a zero-value component where the parity bits have been modified so that the actual value of the component entered is not composed entirely of zeros. For key shares, the tester shall use the same value …
Removed
p. 63
TB12.1 The tester shall examine the vendor’s response to Section B12 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B12 of the PCI PTS HSM Modular Security Requirements for consistency relating to ensuring the device will fail in a secure manner whenever cryptographic keys are rendered invalid. The tester shall summarize the responses.
TB12.2 The tester shall examine and cite any relevant documentation (e.g., API reference, design documentation, key-management specification) that describes the device’s behavior when cryptographic keys are lost to determine whether it supports the assertions made by the vendor.
TB12.2 The tester shall examine and cite any relevant documentation (e.g., API reference, design documentation, key-management specification) that describes the device’s behavior when cryptographic keys are lost to determine whether it supports the assertions made by the vendor.
Modified
p. 63 → 65
TB11.1 The tester shall force the device to erase its cryptographic keys (e.g., via a command, removal of power, tamper event). The tester shall verify that the device fails in a secure manner (e.g., reverts to an un-initialized state and not a normal operational state).
Removed
p. 64
TB13.1 The tester shall examine the response to Section B13 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B13 of the PCI PTS HSM Modular Security Requirements for consistency relating to encryption and decryption of arbitrary data. The tester shall summarize the responses.
TB13.2 The tester shall and cite examine any additional documentation (e.g., API reference, design documentation, key-management specification) submitted by the vendor that describes the use of cryptographic keys to determine whether it supports the assertions made by the vendor.
TB13.2 The tester shall and cite examine any additional documentation (e.g., API reference, design documentation, key-management specification) submitted by the vendor that describes the use of cryptographic keys to determine whether it supports the assertions made by the vendor.
Modified
p. 64 → 66
TB12.1 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the use of cryptographic keys and relating to encryption and decryption of arbitrary data to determine whether it supports the assertions made by the vendor. For example: A public key shall not be used by the device for both signature authentication and encryption. Examples of a key’s “cryptographic purpose” are: Data encryption, key encryption, and MAC.
Modified
p. 65 → 67
This evaluation activity should be focused at relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
This evaluation activity should be focused on relevant security-critical sections of the source code to provide an optimum balance between use of evaluation resources against evaluation goals overall.
Modified
p. 65 → 67
c) Key-encrypting keys are only used to encrypt keys.
Modified
p. 65 → 67
d) Data keys shall never be used to encrypt other keys or PIN or account data.
Modified
p. 65 → 67
b) Account-data encryption keys are only used to encrypt account data.
Removed
p. 66
TB14.1 The tester shall examine the response to Section B14 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B14 of the PCI PTS HSM Modular Security Requirements for consistency relating to the output of clear-text keys and the protection of PINs. The tester shall summarize the responses.
TB14.2 The tester shall examine the response to Section B14 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire relating to encryption of a key or PIN under a key that might itself be disclosed, for consistency.
TB14.3 The tester shall examine the response to Section B14 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire relating to the transfer of a key from a high-security component to a lower-security component, for consistency.
TB14.2 The tester shall examine the response to Section B14 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire relating to encryption of a key or PIN under a key that might itself be disclosed, for consistency.
TB14.3 The tester shall examine the response to Section B14 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire relating to the transfer of a key from a high-security component to a lower-security component, for consistency.
Modified
p. 66 → 68
Clear-text PINs may be output in issuer environments. Clear-text PINs are not allowed to be output under the security policy (see C1 and B15) for devices used for PIN processing by an acquirer or its agent.
Clear-text PINs may be output in issuer environments. Clear-text PINs are not allowed to be output under the security policy (see C1 and B14) for devices used for PIN processing by an acquirer or its agent.
Modified
p. 66 → 68
TB13.1 The tester shall examine any documentation•i.e., the Asset Flow Analysis, API programmer’s guide, specifications, block diagrams, etc.•containing information relating to:
Modified
p. 66 → 68
TB13.2 Referencing the table of sensitive-information storage provided in Requirement A3, the tester shall note whether cryptographic keys, customer PINs, or other sensitive data are exported outside the security processor to other components (including memory components) within the device. The tester shall justify why any such transfer of keys ensures that they remain secure.
Removed
p. 67
TB15.1 The tester shall examine the response to Section B15 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B15 of the PCI PTS HSM Modular Security Requirements for consistency relating to PIN Management. The tester shall summarize the responses.
TB15.2 The tester shall examine and cite any additional documentation (e.g., API reference, design documentation, key-management specification) that describes PIN management to determine whether it supports the assertions made by the vendor.
• Master/Session The device must also support at least one of the following PIN block formats if supporting online PIN processing:
TB15.2 The tester shall examine and cite any additional documentation (e.g., API reference, design documentation, key-management specification) that describes PIN management to determine whether it supports the assertions made by the vendor.
• Master/Session The device must also support at least one of the following PIN block formats if supporting online PIN processing:
Modified
p. 67 → 69
PIN block formats intended for use by Issuers in connection with PIN unblock or PIN change on chip cards may also be supported, but are still subject to the PIN translation restrictions enumerated below.
PIN block formats intended for use by Issuers in connection with PIN unblock or PIN change on chip cards may also be supported but are still subject to the PIN translation restrictions enumerated below.
Modified
p. 67 → 69
1. The device must support at least one of the following key-management techniques using AES as described in ANSI X9.24 and ISO/IEC 18033-3:
Removed
p. 68
Translation to Translation from Format 0 Format 1 Format 2 Format 3, 4
Removed
p. 68
• Change of PAN token to real PAN only permitted with cryptographic binding of PAN token to real PAN Not permitted Permitted for submissions to an IC card Permitted TB15.4 The tester shall verify the following (as applicable):
• The device supports the standard PIN block formats.
• The device supports the standard PIN block formats.
Modified
p. 68 → 70
- Permitted anywhere without change of PAN - Change of PAN only permitted in sensitive state for card issuance - Change of PAN token to real PAN only permitted with cryptographic binding of PAN token to real PAN Not permitted Permitted for submission to an IC card ISO Format 1 Permitted Permitted Permitted for submission to an IC card ISO Format 2 Not permitted Not permitted Permitted for submission to an IC card TB14.2 From the above list of PIN-block …
Removed
p. 69
TB16.1 The tester shall examine the vendor’s response to Section B16 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B16 of the PCI PTS HSM Modular Security Requirements for consistency relating to secure logging. The tester shall summarize the responses.
TB16.2 The tester shall examine and cite any additional documentation (e.g., API reference, design documentation, key-management specification) that describes secure logging to determine whether it supports the assertions made by the vendor.
TB16.2 The tester shall examine and cite any additional documentation (e.g., API reference, design documentation, key-management specification) that describes secure logging to determine whether it supports the assertions made by the vendor.
Modified
p. 69 → 72
TB15.1 The tester shall verify that the device provides mechanisms that allow log data stored within the device to be protected•e.g., using cryptographic mechanisms that allow log data stored within the device to be protected from unauthorized modification and deletion or from modification if output for storage. The vendor security policy must address administrative actions regarding periodic management and archiving of log data.
Modified
p. 69 → 72
TB15.2 The tester shall verify that the device supports secure logging, including time stamps, of security sensitive commands such as:
Modified
p. 69 → 72
d) Enabling and disabling device security functions TB16.5 The tester shall verify that the device requires dual control to delete secure logs stored internally.
d) Enabling and disabling device security functions TB15.3 The tester shall verify that the device requires dual control to delete secure logs stored internally.
Modified
p. 69 → 72
TB15.4 The tester shall verify that the device never exports logs that contain clear-text sensitive data.
Removed
p. 70
OS is considered all code, which is responsible to enforce, manage, or change such access rights. Therefore, OS code is necessarily part of the firmware as defined within B1.
Modified
p. 70 → 73
The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS HSM Modular Security Requirements and listed as such in the approval listings. Specifically, those applications must be validated to ensure that devices may allow customers or integrators to install additional applications where the vendor can show that by permitting this:
The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS HSM Modular Security Requirements and listed as such in the approval listings.
Modified
p. 70 → 73
b) It cannot modify any of the cryptographic functionality of the device or introduce new primitive cryptographic functionality.
b) It cannot modify any of the cryptographic functionality of the device or introduce new primitive cryptographic functionality. However, new composite functionality that builds on existing primitives is permitted.
Modified
p. 70 → 73
The vendor must provide clear security guidance in the user available security policy referenced in C1 for the development and implementation of the aforementioned additional applications. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested, and authorized.
Removed
p. 71
TB17.2 The tester shall examine and cite any relevant documentation, such as the user guide, specification of the device’s logical structure, configuration lists, description of separation mechanisms, interface specifications, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
Modified
p. 71 → 74
TB16.2 The tester shall analyze the vendor’s measures that ensure that the device enforces the separation between applications with security impact from those without security impacts. The tester will verify that it is not possible that one application interferes with or tampers another application or the OS/firmware of the device, especially to access, use or modify data objects belonging to another application, even if they are distributed over separate components of the device.
Modified
p. 71 → 74
TB16.3 The tester shall note whether the device is designed to allow for non-firmware applications to be executed, and what firmware functions are provided by the processor on which such non- firmware applications would execute (for example, PIN processing, cryptographic-key operations, etc.).
Modified
p. 71 → 74
TB16.4 If the OS/firmware and/or any application with security impact are distributed over separate components (i.e., sets of hardware, software, firmware, or some combination thereof that implement cryptographic functions or processes that are contained within independent defined cryptographic boundaries) of the device, the tester will verify that the communication in between separated parts is consistent with the separation mechanisms as described by the vendor. The vendor shall provide evidence concerning the communication between the separated parts and how the communication …
Modified
p. 71 → 74
TB16.5 If the device allows customers or integrators to install additional applications, the tester will verify that the device’s design prevents the embedded application from:
Removed
p. 72
TB17.13 If the device allows customers or integrators to install additional applications, the tester shall verify that the device’s design prevents the embedded application from:
• Having access to the top-level master keys that protect the working keys
•i.e., the application cannot extract or modify the top-level master key.
• Having access to operator or security-officer functions, and therefore cannot change security configurations or change privileges.
• Introducing new primitive cryptographic functions (although it can use these to implement new composite functionality).
Additionally, the embedded application is separated from the approved device’s functionality by an internal security boundary that prevents embedded applications from obtaining any elevated privilege or access to any data belonging to other embedded or host-side applications.
• Having access to the top-level master keys that protect the working keys
•i.e., the application cannot extract or modify the top-level master key.
• Having access to operator or security-officer functions, and therefore cannot change security configurations or change privileges.
• Introducing new primitive cryptographic functions (although it can use these to implement new composite functionality).
Additionally, the embedded application is separated from the approved device’s functionality by an internal security boundary that prevents embedded applications from obtaining any elevated privilege or access to any data belonging to other embedded or host-side applications.
Modified
p. 72 → 74
TB16.7 If the device relies upon the use of different processors to provide for the separation between the firmware and any applications, the tester shall review and briefly describe the method of communications provided between these processors, including any physical interface and API(s).
Modified
p. 72 → 74
TB16.8 If the device allows for different applications to be executed on the same processor, or for the execution of one or more applications on the same processor that is used to execute firmware, the tester shall detail the mechanisms provided to ensure that code and data objects of different applications/firmware are kept separate.
Modified
p. 72 → 74
TB16.9 The tester shall review the configuration of the mechanisms described above and confirm that it maintains application separation.
Modified
p. 72 → 75
TB16.11 The tester shall verify that clear security guidance for the development and implementation of the aforementioned additional applications is included in the security policy cited in C1. This guidance at a minimum must define procedural controls to ensure that the applications are properly reviewed, tested, and authorized.
Removed
p. 73
The intended operation is considered as the functionality relevant to B2, and is representative of the functionality provided by the device. For multi-application devices, the intended operation furthermore includes the operation of applications without security impacts.
TB18.1 The tester shall examine the vendor’s response to Section B18 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B18 of the PCI PTS HSM Modular Security Requirements to verify that the operating system and the related software of the device contain only the components and the services necessary for the intended operation. The tester shall summarize the responses.
TB18.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the device’s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TB18.5 The tester shall verify that the operating system/firmware is …
TB18.1 The tester shall examine the vendor’s response to Section B18 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B18 of the PCI PTS HSM Modular Security Requirements to verify that the operating system and the related software of the device contain only the components and the services necessary for the intended operation. The tester shall summarize the responses.
TB18.2 The tester shall examine and cite any relevant documentation, such as a user guide, the specification of the device’s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.
TB18.5 The tester shall verify that the operating system/firmware is …
Modified
p. 73 → 76
Firmware and software running on the device shall be designed to run with minimal privilege and ensure that no process requires root (or equivalent) privilege following startup. Additionally, only software necessary for the intended purpose of the device shall be present.
Firmware and software running on the device shall be designed to run with minimal privilege and ensure that no process requires root (or equivalent) privilege following startup. Additionally, only software necessary for the intended purpose of the device shall be present. Least privilege requires that only those components and services that are required to have access to sensitive information, functions, and/or peripherals be permitted to have such access.
Modified
p. 73 → 76
For the purposes of this requirement, sensitive information, functions, and peripherals, include any method that may provide access to plaintext cryptographic keys and components, customer PINs, passwords used for entry into sensitive states, or other items of information or configuration that is required to meet the core logical and physical requirements.
For the purposes of this requirement, sensitive information, functions, and peripherals, include any method that may provide access to clear-text cryptographic keys and components, customer PINs, passwords/authentication codes used for entry into sensitive states, or other items of information or configuration that is required to meet the core logical and physical requirements.
Modified
p. 73 → 76
TB17.1 The tester shall verify that all components and services indicated in the configuration list are necessary for the intended operation. For that purpose, the vendor shall provide a configuration list, which shows all OS/firmware components and other software with an explanation of the purpose and a rationale for its presence.
Modified
p. 73 → 76
TB17.3 The tester shall verify that API functionality and commands that are not required to support specific functionality are removable whenever possible or disabled if removal is not feasible.
Modified
p. 73 → 76
TB17.4 The tester will examine the methods and tools provided by the vendor, which ensure that the intended software configuration of the device is maintained and that updates and release changes do not affect the secure configuration of the OS.
Removed
p. 74
TB18.10 The tester shall obtain the configuration information for the operating system used in the device.
The tester shall compare this configuration with the supplied documentation, and note whether they agree or have differences. If differences are detected, it is necessary to address why these occur with regard to compliance to this requirement.
The tester shall compare this configuration with the supplied documentation, and note whether they agree or have differences. If differences are detected, it is necessary to address why these occur with regard to compliance to this requirement.
Modified
p. 74 → 76
TB17.6 If the device uses a commercial operating system, the tester shall review publicly available sources of vulnerability information and note whether any vulnerabilities exist for this system. The tester shall note the sources reviewed and any potential vulnerabilities found and justify why any such vulnerabilities are mitigated by the vendor configuration(s).
Modified
p. 74 → 77
TB17.8 The tester shall describe the testing and methodology used by the vendor to determine the functions necessary for the device’s execution environment. The tester shall justify that this description sufficiently details the steps necessary to reduce the functionality of the device to only those components and services necessary for the intended operation of the device.
Removed
p. 75
TB19.1 The tester shall examine the vendor’s response to Section B19 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement B19 of the PCI PTS HSM Modular Security Requirements for consistency relating to the ability of the device to return its unique device ID.
Modified
p. 75 → 78
Devices must be uniquely identified through acceptable cryptographic methods. Examples of appropriate algorithms and minimum key sizes are stated in Appendix D.
Devices must each be uniquely identified through acceptable cryptographic methods for their authentication. Examples of appropriate algorithms and minimum key sizes are stated in Appendix D.
Modified
p. 75 → 78
TB18.1 The tester shall examine and cite any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the unique device ID.
Modified
p. 75 → 78
TB18.2 The tester shall obtain the unique device ID from the device using the methods described in vendor documentation.
Removed
p. 76
TB20.1 The tester shall examine the response to Section 20 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement 20 of the PCI PTS HSM Modular Security Requirements for consistency relating to separation of PCI and non-PCI modes.
TB20.2 The tester shall and cite examine any additional relevant documentation submitted by the vendor, such as user guides or an API, to verify that it supports vendor responses.
TB20.2 The tester shall and cite examine any additional relevant documentation submitted by the vendor, such as user guides or an API, to verify that it supports vendor responses.
Modified
p. 76 → 79
Authentication data must include at least seven characters.
Authentication data must include at least seven characters or an equivalent strength.
Modified
p. 76 → 79
TB19.1 The tester shall review source code to verify that the device zeroizes keys or prevents keys from being shared between the two modes.
Modified
p. 76 → 79
TB19.2 The tester shall verify that all conditions, as described above in the guidance, are met if the device implements a PCI mode and a non-PCI mode.
Removed
p. 77
The security policy may reference a previously defined document (e.g., a FIPS security policy) rather than embedding existing documentation into the security policy itself. When this is done, the security policy must indicate the specific version of the referenced document, and the referenced document must be provided to the evaluator.
TC1.1 The tester shall examine the vendor’s response to Section C1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement C1 of the PCI PTS HSM Modular Security Requirements for consistency.
TC1.2 The tester shall examine the security policy to verify that the device is properly identified. Product name, hardware version, and software version information should be included in the identification of the approved device. The tester shall validate that the security policy includes pictures of the device, and how to validate the hardware, firmware, and application versions.
TC1.1 The tester shall examine the vendor’s response to Section C1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement C1 of the PCI PTS HSM Modular Security Requirements for consistency.
TC1.2 The tester shall examine the security policy to verify that the device is properly identified. Product name, hardware version, and software version information should be included in the identification of the approved device. The tester shall validate that the security policy includes pictures of the device, and how to validate the hardware, firmware, and application versions.
Modified
p. 77 → 80
Devices evaluated in Section A
• Physical Derived Security Requirements where the device will be restricted to deployment in controlledenvironments as defined in ISO 13491-2 must stipulate those deployment restrictions in the device’s security policy.
• Physical Derived Security Requirements where the device will be restricted to deployment in controlled
Devices evaluated in Section A
• Physical Derived Security Requirements where the device will be restricted to deployment in environments meeting at least the security of a controlled environment as defined in ISO 13491-2 must stipulate those deployment restrictions in the device’s security policy.
• Physical Derived Security Requirements where the device will be restricted to deployment in environments meeting at least the security of a controlled environment as defined in ISO 13491-2 must stipulate those deployment restrictions in the device’s security policy.
Modified
p. 77 → 80
Devices may include unapproved functionality. When such functions are in use, the device is considered to be operating in an unapproved mode and must provide a mode indication as described in B20.
Devices may include unapproved functionality. When such functions are in use, the device is considered to be operating in an unapproved mode and must provide a mode indication as described in B19.
Modified
p. 77 → 80
Also see B15 for validation of allowed PIN translations.
Also see B14 for validation of allowed PIN translations.
Modified
p. 77 → 80
TC1.2 The tester shall review the device security policy and note whether this clearly states the environments in which the device is restricted to use in environments meeting at least the security of controlled environments.
Modified
p. 77 → 80
TC1.3 The tester shall confirm that the security policy includes all configuration settings necessary to meet the security requirements defined in this document.
Removed
p. 78
TC1.16 The tester shall examine the security policy to verify that it identifies all roles supported by the device and indicates the services and permissions available for each role.
Modified
p. 78 → 81
TC1.6 The tester shall examine the security policy to verify that it states that keys should be replaced with new keys whenever the compromise of the original key is known or suspected, and whenever the time deemed feasible to determine the key by exhaustive attack elapses, as defined in NIST SP 800-57-1.
Modified
p. 78 → 81
TC1.7 The tester shall examine the security policy to verify that it provides guidance on secure key archival storage to protect keys against unauthorized disclosure and substitution and to provide key separation.
Modified
p. 78 → 81
The tester shall examine the security policy to verify that it describes how to verify security relevant settings such as PIN block formats enabled and the commands in place, such as the ability to output clear-text PINs.
The tester shall examine the security policy to verify that it describes how to verify security- relevant settings such as PIN block formats enabled and the commands in place, such as the ability to output clear-text PINs.
Modified
p. 78 → 81
TC1.8 The tester shall examine the security policy to verify that instructions are provided with regard to tamper evidence, inspection frequency and procedures.
Modified
p. 78 → 81
TC1.9 The tester shall examine the security policy to verify that instructions are provided with regard to auditing/log inspection frequency and procedures. The security policy shall include events that are logged as defined in B15, any restrictions on operator access to logs, and procedures for accessing and deleting logs.
Modified
p. 78 → 81
TC1.10 The tester shall examine the security policy and relevant vendor documentation to verify that any periodic maintenance procedures required for the secure operation of the device are included in the security policy.
Modified
p. 78 → 81
TC1.11 The tester shall examine the security policy and relevant vendor documentation to verify that documentation includes procedures for authentication of the device when received via shipping. Note that this may include visual or cryptographic methods.
Modified
p. 78 → 81
TC1.12 The tester shall examine the security policy to verify that all physical interfaces are identified, along with the functionality and type of data that is carried over each interface.
Modified
p. 78 → 81
TC1.13 If the device permits access to internal areas, the tester shall examine the security policy to verify that it specifies the internal components and operating procedures requiring access to these internal areas.
Modified
p. 78 → 81
TC1.15 The tester shall examine the security policy to verify that it identifies all self-tests that the module performs, procedures that an operator may need to initiate any self-tests, and the conditions under which each self-test is executed (e.g., power up, periodic, conditional, on operator demand).
TC1.15 The tester shall examine the security policy to verify that it identifies all roles supported by the device and indicates the services and permissions available for each role.
Removed
p. 79
Translation to Translation from Format 0 Format 1 Format 2 Format 3, 4
Modified
p. 79 → 82
TC1.17 The tester shall examine the security policy to verify that it identifies all conditions (e.g., voltage, humidity, temperature) that will cause environmental failure-protection (EFP) mechanisms to trigger.
Modified
p. 79 → 82
TC1.18 The tester shall examine the security policy and other relevant documentation submitted by the vendor to verify that the security policy identifies any other operational-environment restrictions that must be met for the device to be operated in a secure manner (e.g., ambient-temperature range, support hardware, support software, power conditioning, environmental protections assumed for proper operation).
Modified
p. 79 → 82
TC1.19 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 the implementation is easily identifiable in reviewing system settings.
Modified
p. 79 → 82
- Permitted anywhere without change of PAN - Change of PAN only permitted in sensitive state for card issuance - Change of PAN token to real PAN only permitted with cryptographic binding of PAN token to real PAN Not permitted Permitted for submission to an IC ISO Format 1 Permitted Permitted Permitted for submission to an IC ISO Format 2 Not permitted Not permitted Permitted for submission to an IC TC1.20 The tester shall configure the device according to the …
Modified
p. 80 → 82
TC1.21 The tester shall confirm that the security policy includes procedures for the decommissioning of devices that are removed from service, including the removal of all keying material that could be used to decrypt any sensitive data processed by the device. The procedures may differentiate between temporary and permanent removal.
Modified
p. 80 → 82
•i.e., simply using the term “MK/SK” is not sufficient
•and specifies that use of the device with different key- management systems will invalidate any
TC1.22 The tester shall confirm the security policy of the device and confirm that it clearly outlines the exact details of the key-management systems supported by the device
•i.e., simply using the term “MK/SK” is not sufficient
•and specifies that use of the device with different key- management systems will invalidate any PCI-approval of this device.
•i.e., simply using the term “MK/SK” is not sufficient
•and specifies that use of the device with different key- management systems will invalidate any PCI-approval of this device.
Modified
p. 80 → 83
TC1.24 The tester shall confirm that the security policy contains specific details on how to change any default values, including passwords/authentication codes and certificates.
Modified
p. 80 → 83
TC1.25 The tester shall confirm that the security policy contains information on how the device will indicate a tamper-response event, and any requirements for the return of this device to the vendor for examination following such an event (as required for compliance to DTR A1).
Modified
p. 80 → 83
TC1.26 The tester shall examine the security policy and relevant vendor documentation to verify that the device has update and patch procedures required for the secure operation of the device and that the procedures are included in the security policy. The policy will include both local and remote update and patch downloading procedures for software, firmware, and configuration parameters.
Modified
p. 80 → 83
TC1.27 The tester shall confirm that the security policy includes any communication methods and protocols, including wireless, used by the device. Use of any method not listed in the policy invalidates the device approval.
Removed
p. 81
For devices that are capable of generating secret or private keys, the secret or private keys or their precursors cannot be visible in clear text at any time during the generation process. The lab must verify that they cannot view the keys at any time during the generation process.
TD1.1 The tester shall examine the vendor’s response to Section D1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D1 of the PCI PTS HSM Modular Security Requirements to verify that the secret or private key or its precursors are not visible in clear text at any time during the generation process.
TD1.1 The tester shall examine the vendor’s response to Section D1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D1 of the PCI PTS HSM Modular Security Requirements to verify that the secret or private key or its precursors are not visible in clear text at any time during the generation process.
Modified
p. 81 → 84
TD1.1 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that it supports the vendor response that the secret and private key or its precursors, are not be visible in clear-text form at any time during the generation process.
Modified
p. 81 → 84
TD1.2 The tester shall analyze the device to determine whether the secret or private keys or their precursors are visible in clear-text form at any time.
Modified
p. 81 → 84
TD1.3 The tester shall generate secret and/or asymmetric key pairs to determine whether the secret and private key or its precursor is visible in clear-text form at any time during the generation process.
Removed
p. 82
TD2.1 The tester shall examine the vendor’s response to Section D2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D2 of the PCI PTS HSM Modular Security Requirements to verify that the key or key pairs and all related secret and private seed elements are deleted immediately after the transfer process for those keys not used by the device.
TD2.3 The tester shall analyze the device to determine that for key pairs that are not used by the device, the key or key pair and all related secret and private seed elements are deleted immediately after the transfer process TD2.4 The tester shall generate secret and/or asymmetric key pairs and verify that the key or key pair and all related secret and private seed elements are deleted immediately after the transfer process.
TD2.3 The tester shall analyze the device to determine that for key pairs that are not used by the device, the key or key pair and all related secret and private seed elements are deleted immediately after the transfer process TD2.4 The tester shall generate secret and/or asymmetric key pairs and verify that the key or key pair and all related secret and private seed elements are deleted immediately after the transfer process.
Modified
p. 82 → 85
The device cannot store unused keys, key pairs, or seed elements subsequent to completion of the transfer process. Once the transfer process is completed, the device deletes all related secret information, keys, key pairs and seed elements.
The device cannot store unused keys, key pairs, or seed elements subsequent to completion of the transfer process. Once the transfer process is completed, the device deletes all related secret information, keys, key pairs, and seed elements.
Modified
p. 82 → 85
TD2.1 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that the key or key pair and all related secret and private seed elements are deleted immediately after the transfer process for those keys not used by the device.
Removed
p. 83
TD3.1 The tester shall examine the vendor’s response to Section D3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D3 of the PCI PTS HSM Modular Security Requirements to verify that after key transfer, there is no information retained by the device that could be used to disclose a key.
TD3.3 The tester shall analyze the device to determine that device retains no information that could disclose any key previously transferred.
TD3.3 The tester shall analyze the device to determine that device retains no information that could disclose any key previously transferred.
Modified
p. 83 → 86
TD3.1 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that the device clears all information that could disclose any key previously transferred.
Removed
p. 84
TD4.1 The tester shall examine the vendor’s response to Section D4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D4 of the PCI PTS HSM Modular Security Requirements to verify that the vendor has detailed the transfer process of keys, for devices composed of several components.
TD4.2 The tester shall examine the vendor’s response to Section D4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D4 of the PCI PTS HSM Modular Security Requirements to verify that the vendor has detailed the protections of each of the components of the solution. The tester shall justify why any such transfer of keys ensures that they remain secure.
TD4.2 The tester shall examine the vendor’s response to Section D4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D4 of the PCI PTS HSM Modular Security Requirements to verify that the vendor has detailed the protections of each of the components of the solution. The tester shall justify why any such transfer of keys ensures that they remain secure.
Modified
p. 84 → 87
TD4.1 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that the vendor has detailed the transfer process of keys for devices composed of several components and that it is not possible to move a cryptographic key within the device from a component of higher security to a component providing lower security.
Modified
p. 84 → 87
TD4.2 The tester shall attempt transfer a cryptographic key to a component providing lower security.
Removed
p. 85
TD5.1 The tester shall examine the vendor’s response to Section D5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement D5 of the PCI PTS HSM Modular Security Requirements to verify that modification of the device’s functional capabilities either results in the erasure of cryptographic keys stored within the device or is otherwise detected before the device is next used to load a key.
Modified
p. 85 → 88
TD5.1 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the device’s logical structure, or any other relevant documentation, to verify that it is not possible to modify the device’s functional capabilities without either causing the erasure of cryptographic keys stored within the device or otherwise being detected before the device is next used to load a key.
Modified
p. 85 → 88
TD5.2 The tester shall attempt to modify the device’s functional capabilities and document how the device responds.
Removed
p. 86
TE1.1 The tester shall examine the response to Section E1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement E1 of PCI PTS HSM Modular Security Requirements for consistency.
TE1.2 The tester shall examine any relevant documentation submitted by the vendor, such as assembly drawings, to verify that it supports the vendor responses.
TE1.2 The tester shall examine any relevant documentation submitted by the vendor, such as assembly drawings, to verify that it supports the vendor responses.
Modified
p. 86 → 89
TE1.1 The tester shall verify that all operational services cease during the initialization processes.
Modified
p. 86 → 89
TE1.2 The tester shall verify that no operational services are started until the initialization is complete.
Modified
p. 86 → 89
TE1.3 The tester shall verify that remote admin connectivity is terminated during the initialization process and cannot be established until the initialization sequence is complete.
Removed
p. 87
TE2.1 The tester shall examine the response to Section E2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement E2 of the PCI PTS HSM Modular Security Requirements for consistency relating to operator functions to ensure that enabling or disabling functions and changing passwords happen only when the device is in a sensitive state, and that the device cannot be left in a sensitive state. The tester shall summarize the responses.
TE2.2 The tester shall examine the supporting documentation submitted by the device vendor. The documents should be representative of a configuration control process that can be audited. These documents shall be referenced. The documentation could include firmware revision lists with updates documented, current operator manuals, and other materials that show clear evidence that the device is operated in a secure manner TE2.3 The tester shall examine details provided by the vendor that the documented process …
TE2.2 The tester shall examine the supporting documentation submitted by the device vendor. The documents should be representative of a configuration control process that can be audited. These documents shall be referenced. The documentation could include firmware revision lists with updates documented, current operator manuals, and other materials that show clear evidence that the device is operated in a secure manner TE2.3 The tester shall examine details provided by the vendor that the documented process …
Modified
p. 87 → 90
• Change of passwords or other authentication data that enable the device to enter the sensitive state.
• Change of passwords/authentication codes or data that enable the device to enter the sensitive state.
Modified
p. 87 → 90
The secure operator interface is so designed that entry of more than one password (or some equivalent mechanism for dual or multiple control) is required in order to enter this sensitive state and that it is highly unlikely that the device can inadvertently be left in the sensitive state.
The secure operator interface is so designed that entry of more than one password/authentication code (or some equivalent mechanism for dual or multiple control) is required in order to enter this sensitive state and that it is highly unlikely that the device can inadvertently be left in the sensitive state.
Modified
p. 87 → 90
Operator functions need to be controlled and defined. Certain operator functions can only be done when the device is in a sensitive state. A sensitive state is defined as to when the device is under dual or multiple control and that more than one password is required to enter a sensitive state. To activate the secure operator interface, more than one password or equivalent mechanism for dual or multiple control is required.
Operator functions need to be controlled and defined. Certain operator functions can only be done when the device is in a sensitive state. A sensitive state is defined as to when the device is under dual or multiple control and that more than one password/authentication code is required to enter a sensitive state. To activate the secure operator interface, more than one password/authentication code or equivalent mechanism for dual or multiple control is required.
Modified
p. 87 → 90
Passwords/authentication codes used for authentication are at least seven characters in length or an equivalent strength.
Modified
p. 87 → 90
Sensitive state limits are consistent with B7.
Sensitive state limits are consistent with B6.
Modified
p. 87 → 90
TE2.3 The tester shall verify and demonstrate that the device configuration settings can only be done when the device is in the sensitive state.
Modified
p. 87 → 90
TE2.4 The tester shall verify that any change to device passwords or other authentication data that allows a device to enter a sensitive state happens under a sensitive state.
Modified
p. 87 → 90
TE2.5 The tester shall attempt to initiate a configuration change and password or other authentication data change while the device is in other than a sensitive state.
Modified
p. 87 → 90
TE2.6 The tester shall validate that the operator interface requires more than one password/authentication code or equivalent mechanism for dual or multiple control to enter the sensitive state.
Removed
p. 89
TF1.1 The tester shall examine the response to Section F1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F1 of the PCI PTS HSM Modular Security Requirements for consistency relating to manual activation and outputs of the message authentication device. The tester shall summarize the responses.
TF1.2 The tester shall examine and cite any relevant documentation such as a user guide or operations manual, submitted by the vendor to verify that it supports vendor responses.
TF1.2 The tester shall examine and cite any relevant documentation such as a user guide or operations manual, submitted by the vendor to verify that it supports vendor responses.
Modified
p. 89 → 92
Clear-text-computed MACs should never be outputted on the denial or confirmation of the MAC.
Modified
p. 89 → 92
TF1.1 The tester shall determine from vendor documentation that the message authentication device can be manually activated and the identity of the key used is displayed by the device.
Modified
p. 89 → 92
TF1.2 The tester shall verify that the device only outputs a confirmation or denial during a MAC verification and that the clear-text MAC is never output.
Removed
p. 90
TF2.1 The tester shall examine the vendor’s response to Section F2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F2 of the PCI PTS HSM Modular Security Requirements for ensuring the MAC being generated or verified meets the ISO 16609. The tester shall summarize the responses.
Modified
p. 90 → 93
TF2.1 The tester shall examine and cite any relevant documentation (e.g., design documentation, key- management specification) that describes the MAC length.
Modified
p. 90 → 93
TF2.2 The tester shall list the MAC length values used by the device and all values supports.
Modified
p. 90 → 93
TF2.3 The tester shall verify and list all MAC generation algorithms used by the device.
Removed
p. 91
TF3.1 The tester shall examine the response to Section F3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F3 of the PCI PTS HSM Modular Security Requirements for consistency relating to ISO 16609 two key MAC verification and generation techniques. The tester shall summarize the responses TF3.2 The tester shall and cite examine any additional documentation (e.g., design documentation, key-management specification) submitted by the vendor that describes the MAC generation and verification to determine whether it supports the assertions made by the vendor.
Modified
p. 91 → 94
TF3.2 The tester shall verify that the MAC generation and verification techniques meet ISO 16609.
Modified
p. 91 → 94
TF3.3 The tester shall list the techniques used for MAC generation and verification.
Removed
p. 92
TF4.1 The tester shall examine the vendor’s response to Section F4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement F4 of the PCI PTS HSM Modular Security Requirements to ensure unidirectional MAC keys are used for only a single function. The tester shall summarize the responses.
Modified
p. 92 → 95
TF4.1 The tester shall examine and cite any additional documentation (e.g., design documentation, key-management specification) that describes unidirectional MAC keys.
Modified
p. 92 → 95
TF4.2 The tester shall verify that in the use of unidirectional MAC keys, they are used for one type of MAC function only. The tester shall try multiple functions and document the results.
Modified
p. 92 → 95
TF4.3 The tester shall list all MAC functions to ensure that each MAC key is used for a single function.
Removed
p. 93
TG1.1 The tester shall examine the vendor’s response to Section G1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G1 of the PCI PTS HSM Modular Security Requirements to verify that the device has protections from unauthorized removal and meets at least one of the outlined requirements. The tester shall summarize the response.
Modified
p. 93 → 96
•such as the user guide, specification of the device’s logical structure, installation guide
•submitted by the vendor to verify that
TG1.1 The tester shall examine and cite any relevant documentation
•such as the user guide, specification of the device’s logical structure, installation guide
•submitted by the vendor to verify that the device has protections from unauthorized removal and meets at least one of the outlined requirements.
•such as the user guide, specification of the device’s logical structure, installation guide
•submitted by the vendor to verify that the device has protections from unauthorized removal and meets at least one of the outlined requirements.
Modified
p. 93 → 96
TG1.2 The tester shall note which techniques are employed by the vendor to meet the requirement.
Removed
p. 94
TG2.1 The tester shall examine the vendor’s response to Section G2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G2 of the PCI PTS HSM Modular Security Requirements to ensure the device only exports plaintext key under dual control. The tester shall summarize the vendor’s response.
Modified
p. 94 → 97
• The device requires that at least two passwords (or some equivalent mechanism for dual or multiple control) be correctly entered within a period of no more than five minutes before the device will output a key.
• The device requires that at least two passwords/authentication codes be correctly entered within a period of no more than five minutes before the device will output a key.
Modified
p. 94 → 97
TG2.1 The tester shall examine and cite any documentation (e.g., key-management specification, operator manual) that describes the techniques used to export clear-text keys.
Modified
p. 94 → 97
TG2.2 The tester shall verify the techniques used to export clear-text keys meet the requirement of dual control as described in vendor documentation.
Removed
p. 95
TG3.1 The tester shall examine the vendor’s response to Section G3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G3 of the PCI PTS HSM Modular Security Requirements to ensure the device is in a sensitive state when using special operator functions. The tester shall summarize the vendor’s response.
TG3.4 The tester shall verify the device is placed in a sensitive state when permitting manual input of control data (e.g., key verification code) to enable export, import or use of a key, as described in vendor documentation.
TG3.4 The tester shall verify the device is placed in a sensitive state when permitting manual input of control data (e.g., key verification code) to enable export, import or use of a key, as described in vendor documentation.
Modified
p. 95 → 98
• Manual input of control data (e.g., key verification code) to enable export, import or use of a key; and
• Manual input of control data⎯e.g., key-verification code⎯to enable export, import or use of a key; and
Modified
p. 95 → 98
TG3.1 The tester shall examine and cite any documentation (e.g., key-management specification, operator manual) that describes the special operator functions that place the device into a sensitive state, TG3.2 The tester shall verify the device is placed in a sensitive state when permitting movement of the device without activating a key-erasure mechanism as described in vendor documentation.
Modified
p. 95 → 98
TG3.3 The tester shall verify the device is placed in a sensitive state when permitting movement of the device without activating a key-erasure mechanism as described in vendor documentation.
TG3.3 The tester shall verify the device is placed in a sensitive state when permitting manual input of control data (e.g., key-verification code) to enable export, import or use of a key, as described in vendor documentation.
Removed
p. 96
TG4.1 The tester shall examine the vendor’s response to Section G4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement G4 of the PCI PTS HSM Modular Security Requirements to ensure that proprietary functions are listed and do not impact security of the device. The tester shall summarize the vendor’s response.
Modified
p. 96 → 99
TG4.1 The tester shall examine and cite any documentation (e.g., key-management specification, operator manual) that describes any proprietary functions in the device.
Modified
p. 96 → 99
TG4.2 The tester shall verify that any proprietary function is totally equivalent to a series of standard and approved functions or is limited to use only keys that, by virtue of key separation, cannot be used with keys, or modified keys, of non-proprietary functions.
Removed
p. 97
TH1.1 The tester shall examine the vendor’s response to Section H1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement H1 of the PCI PTS HSM Modular Security Requirements for how the device meets the described above. The tester shall summarize the vendor’s response.
TH1.2 The tester shall examine and cite any relevant documentation
•such as a user guide, operator manual, key-management guidance documents)
•submitted by the vendor to verify that it supports the vendor responses.
TH1.4 The tester shall verify that the asymmetric private key is not exported outside the original digital signature device except under dual control for backup and archival purposes.
TH1.2 The tester shall examine and cite any relevant documentation
•such as a user guide, operator manual, key-management guidance documents)
•submitted by the vendor to verify that it supports the vendor responses.
TH1.4 The tester shall verify that the asymmetric private key is not exported outside the original digital signature device except under dual control for backup and archival purposes.
Modified
p. 97 → 100
• The asymmetric private key is only exported outside the original digital signature device under dual control and only for backup and archival purposes; and
• The asymmetric private key is only exported outside the original digital signature device under dual control; and
Modified
p. 97 → 100
TH1.3 The tester shall verify whether the asymmetric private and public key pair is generated within the digital signature device.
TH1.3 The tester shall verify that the asymmetric private key is not exported outside the original digital signature device except under dual control for backup and archival purposes.
Modified
p. 97 → 100
TH1.4 The tester shall verify that mechanisms for the control of the use of the private key are provided.
Removed
p. 98
TH2.1 The tester shall examine the vendor’s response to Section H2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement H2 of the PCI PTS HSM Modular Security Requirements to ensure the device meets the standard. The tester shall summarize the vendor’s response.
Modified
p. 98 → 101
• Use of public key certificates, where the public key certificate was obtained from an authorized certificate authority (e.g., the vendor PKI); or
• Use of public key certificates, where the public key certificate was obtained from an authorized certificate authority⎯e.g., the vendor PKI; or
Modified
p. 98 → 101
•such as a user guide, operator manual, key-management guidance document
•submitted by the
TH2.1 The tester shall examine and cite any relevant documentation
•such as a user guide, operator manual, key-management guidance document
•submitted by the vendor.
•such as a user guide, operator manual, key-management guidance document
•submitted by the vendor.
Modified
p. 98 → 101
TH2.2 The tester shall verify that the binding between the public key and the identity of the owner of the private key is readily determined by one of the following:
Removed
p. 99
TI1.1 The tester shall examine the vendor’s response to Section I1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I1 of the PCI PTS HSM Modular Security Requirements for consistency relevant to physical and functional change control procedures. The tester shall summarize the responses.
Modified
p. 99 → 127
TL1.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail change control processes and procedures for physical and functional changes to the device, describing how the items are uniquely identified such that it is possible to track the different versions of the items, and including criteria for when changes are submitted for PCI evaluation and details of the vulnerability management process.
Modified
p. 99 → 127
TL1.2 The tester shall review any vendor documentation describing all changes to the software to ensure that changes that rectify errors or faults did not remove, modify, or add functionality that impacts security unless they are submitted immediately upon completion for evaluation. This is to validate the process of deferring submissions for evaluation unless all changes are submitted for evaluation immediately upon completion.
Modified
p. 99 → 128
•including engineers and programming staff, supervisory staff, technical management, etc.
TL1.4 The tester shall interview those responsible for the change control processes
•including engineers and programming staff, supervisory staff, technical management, etc.
•including engineers and programming staff, supervisory staff, technical management, etc.
Modified
p. 100 → 128
TL1.5 The tester shall validate that either:
Removed
p. 101
TI2.1 The tester shall examine the vendor’s response to Section I2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I2 of the PCI PTS HSM Modular Security Requirements for consistency relevant to certified firmware control procedures. The tester shall summarize the responses.
TI2.5 The tester shall examine a sample of documentation for firmware authentication (e.g., signing) and storage during manufacturing, including change control logs and firmware validation procedure to ensure procedures are followed.
TI2.5 The tester shall examine a sample of documentation for firmware authentication (e.g., signing) and storage during manufacturing, including change control logs and firmware validation procedure to ensure procedures are followed.
Modified
p. 101 → 132
All certified firmware must be signed prior to distribution and signed using dual control. It should be managed such that no single person is able to sign files. If two secrets (passwords or PINs) are required for operation of the signing tool, no single person should know both secrets. All certified firmware must be reviewed against the organization’s coding standards prior to signature.
All certified firmware must be signed prior to distribution and signed using dual control. It should be managed such that no single person is able to sign files. If two secrets (passwords/authentication codes) are required for operation of the signing tool, no single person should know both secrets. All certified firmware must be reviewed against the organization’s coding standards prior to signature.
Modified
p. 101 → 132
TL3.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail firmware control and validation processes and procedures for storage during the manufacturing process.
Modified
p. 101 → 132
TL3.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail dual-control and cryptographic authentication processes and procedures during manufacturing and describe how this shows compliance to this requirement.
Modified
p. 101 → 132
•including engineers and programming staff, peer reviewers, supervisory staff, technical management, etc.
TL3.4 The tester shall interview those responsible for the firmware control processes
•including engineers and programming staff, peer reviewers, supervisory staff, technical management, etc.
•including engineers and programming staff, peer reviewers, supervisory staff, technical management, etc.
Modified
p. 101 → 132
TL3.5 If firmware signing is done on site, the tester shall observe the signing process, the signing tools, and ensure they are under dual control and that the signing procedures are followed.
Modified
p. 101 → 132
TL3.6 The tester shall observe the firmware storage and validation process to ensure that only signed and valid firmware is used during manufacturing.
Removed
p. 102
TI3.1 The tester shall examine the vendor’s response to Section I3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I3 of the PCI PTS HSM Modular Security Requirements for consistency relevant to device component control procedures. The tester shall summarize the responses.
Modified
p. 102 → 133
TL4.1 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. The documentation should detail the components used and the hardware component control processes and procedures for storage and verification during the manufacturing process including hardware components identification verification, with the procedures checked in TL1.
Modified
p. 102 → 133
•including
• including engineers and line staff, supervisory staff, technical management, etc.
Modified
p. 102 → 133
TL4.4 The tester shall examine the device parts listing and sample hardware components during manufacturing, to ensure the correct components are used.
Modified
p. 102 → 133
TL4.5 The tester shall observe hardware component control to ensure that authorized components are verified prior to manufacturing and that unauthorized substitutions are not made.
Removed
p. 103
TI4.1 The tester shall examine the vendor’s response to Section I4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I4 of the PCI PTS HSM Modular Security Requirements for consistency relevant to production firmware control procedures. The tester shall summarize the responses.
TI4.5 The tester shall examine a sample of documentation for firmware control and storage during manufacturing
•including change control logs and firmware validation procedures
•to ensure the principle of dual control is followed to prevent unauthorized modifications and/or substitutions.
TI4.5 The tester shall examine a sample of documentation for firmware control and storage during manufacturing
•including change control logs and firmware validation procedures
•to ensure the principle of dual control is followed to prevent unauthorized modifications and/or substitutions.
Modified
p. 103 → 134
TL5.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail firmware control processes and procedures for loading firmware during the manufacturing process.
Modified
p. 103 → 134
TL5.2 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail firmware control processes and procedures for transporting and storing firmware during the manufacturing process and that the principle of dual control is followed to prevent unauthorized modifications and/or substitutions.
Modified
p. 103 → 134
TL5.4 The tester shall interview those responsible for the software (e.g., firmware) control processes
Modified
p. 103 → 134
TL5.5 The tester shall observe the firmware storage and validation process to ensure that procedures are followed during manufacturing.
Removed
p. 104
TI5.1 The tester shall examine the vendor’s response to Section I5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I5 of the PCI PTS HSM Modular Security Requirements for consistency relevant to post-production storage. The tester shall summarize the responses.
TI5.6 The tester shall observe the device and component storage and validation process to ensure that procedures are followed subsequent to production.
TI5.6 The tester shall observe the device and component storage and validation process to ensure that procedures are followed subsequent to production.
Modified
p. 104 → 135
TL6.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail documented and approved post-production control processes and procedures for storage and validation of devices or their components subsequent to production but prior to shipping.
Modified
p. 104 → 135
TL6.2 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail tamper-evident packaging or the access-controlled area where devices and components are stored prior to shipping.
Modified
p. 104 → 135
TL6.4 The tester shall interview those responsible for the post-production control processes
Modified
p. 104 → 135
•to
TL6.5 The tester shall observe the device and component storage and validation process to ensure that procedures are followed subsequent to production.
Modified
p. 104 → 135
TL6.6 The tester shall examine the vendor’s tamper-evident packing or access-controlled area to ensure unauthorized access to devices or their components is not possible.
Removed
p. 105
TI6.1 The tester shall examine the vendor’s response to Section I6 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I6 of the PCI PTS HSM Modular Security Requirements for consistency relevant to secret information. The tester shall summarize the responses.
TI6.5 The tester shall examine a sample of documentation for secret information
•including user documentation and device-validation procedures
•to ensure procedures are followed.
TI6.5 The tester shall examine a sample of documentation for secret information
•including user documentation and device-validation procedures
•to ensure procedures are followed.
Modified
p. 105 → 136
TL7.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail that if the device will be authenticated at the key-loading facility or the facility of initial deployment by means of secret information placed in the device during manufacturing, this secret information is unique to each device, unknown, and unpredictable to any person.
Modified
p. 105 → 136
TL7.2 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail that if the device will be authenticated at the facility of initial deployment by means of secret information placed in the device during manufacturing. The secret information is installed in the device under dual control to ensure that it is not disclosed during installation, or the device may use an authenticated public-key method.
Modified
p. 105 → 136
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
TL7.4 The tester shall interview those responsible for the control processes
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
Modified
p. 105 → 136
TL7.5 The tester shall observe the device secret installation and validation process to ensure that documented and approved procedures are followed subsequent to production. The tester shall verify that if secret information is placed in the device during manufacturing, this secret information is unique to each device, unknown and unpredictable to any person, and installed in the device under dual control to ensure that it is not disclosed during installation.
Removed
p. 106
The PCI Terminal Software Security Best Practices Guidance document can provide additional guidance for software development and testing.
TI7.1 The tester shall examine the vendor’s response to Section I7 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I7 of the PCI PTS HSM Modular Security Requirements for consistency relevant to component control procedures during design and development. The tester shall summarize the responses.
TI7.4 The tester shall examine a sample of approved documentation for component control during design and development
•including user documentation and component validation procedures
•to ensure procedures are followed.
TI7.1 The tester shall examine the vendor’s response to Section I7 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I7 of the PCI PTS HSM Modular Security Requirements for consistency relevant to component control procedures during design and development. The tester shall summarize the responses.
TI7.4 The tester shall examine a sample of approved documentation for component control during design and development
•including user documentation and component validation procedures
•to ensure procedures are followed.
Modified
p. 106 → 137
TL8.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the design and development processes and procedures to ensure security measures are followed during the development and maintenance of the device’s security-related components. Furthermore, the approved documentation must justify that the security measures provide the necessary level of protection to maintain the integrity of the device’s security-related components.
Modified
p. 106 → 137
•including engineers and line staff, supervisory staff, technical management, etc.
TL8.3 The tester shall interview those responsible for component control processes
•including engineers and line staff, supervisory staff, technical management, etc.
•including engineers and line staff, supervisory staff, technical management, etc.
Modified
p. 106 → 137
TL8.4 The tester shall observe the approved component control procedures during design and development to ensure security measures are followed during the development and maintenance of the device’s security-related components.
Modified
p. 106 → 137
TL8.5 The tester shall verify that the manufacturer maintains approved development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of the design and implementation of the device’s security-related components in their development environment and that this provides evidence that these security measures are followed during the development and maintenance of the device’s security-related components.
Removed
p. 107
TI8.1 The tester shall examine the vendor’s response to Section I8 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement I8 of the PCI PTS HSM Modular Security Requirements for consistency relevant to repair and inspection subsequent to repair. The tester shall summarize the responses.
TI8.5 The tester shall examine a sample of approved documentation for repairs, including the resetting of tamper mechanisms; inspection and post-inspection storage, including inventory logs, repair logs, shipping documentation; and device-validation procedures to ensure procedures are followed.
TI8.5 The tester shall examine a sample of approved documentation for repairs, including the resetting of tamper mechanisms; inspection and post-inspection storage, including inventory logs, repair logs, shipping documentation; and device-validation procedures to ensure procedures are followed.
Modified
p. 107 → 138
•including the resetting of tamper mechanisms, inspection, and post-inspection control processes
•and procedures for storage and validation of devices or their components subsequent to repair and inspection but prior to shipping.
TL9.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail repair
•including the resetting of tamper mechanisms, inspection, and post-inspection control processes
•and procedures for storage and validation of devices or their components subsequent to repair and inspection but prior to shipping.
•including the resetting of tamper mechanisms, inspection, and post-inspection control processes
•and procedures for storage and validation of devices or their components subsequent to repair and inspection but prior to shipping.
Modified
p. 107 → 138
TL9.2 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The approved documentation shall detail the inspection process and tamper-evident packaging or the access-controlled area where devices and components are stored prior to shipping.
Modified
p. 107 → 138
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
TL9.4 The tester shall interview those responsible for repair, inspection, and post-inspection control processes
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
Modified
p. 107 → 138
TL9.5 The tester shall observe the device repair, inspection, and post-inspection storage process to ensure that procedures are followed subsequent to production.
Modified
p. 107 → 138
TL9.6 The tester shall examine the vendor’s tamper-evident packing or accessed-controlled area to ensure unauthorized access to devices or their components is not possible.
Removed
p. 108
TJ1.1 The tester shall examine the vendor’s response to Section J1 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J1 of the PCI PTS HSM Modular Security Requirements regarding the protection of devices during shipping. The tester shall summarize the responses.
Modified
p. 108 → 139
TM1.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should provide customers instruction on validation of the authenticity and integrity of the device, detailing the shipping process, tamper protection, instructions for receiving and inspection, as well as procedures for suspected tamper evidence. Alternatively, the approved documentation must detail how the device is shipped from the manufacturer’s facility to the facility of initial deployment and stored en route under auditable controls that can account …
Modified
p. 108 → 139
TM1.2 The tester shall examine approved documentation detailing that where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing is compliant with this requirement.
Modified
p. 108 → 140
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
TM1.4 The tester shall interview those responsible for the shipping control processes
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
Modified
p. 109 → 140
TM1.5 The tester shall observe the shipping process to ensure that customers are provided documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the device; or alternatively, the device is shipped from the manufacturer’s facility to the facility of initial deployment and stored en route under auditable controls.
Removed
p. 110
TJ2.1 The tester shall examine the vendor’s response to Section J2 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J2 of the PCI PTS HSM Modular Security Requirements for device-accountability transfer procedures. The tester shall summarize the responses.
TJ2.4 The tester shall examine a sample of transfer documentation
•including inventory logs and shipping documentation
•to ensure procedures are followed.
TJ2.4 The tester shall examine a sample of transfer documentation
•including inventory logs and shipping documentation
•to ensure procedures are followed.
Modified
p. 110 → 141
TM2.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the instructions for receiving and inspection, as well as procedures for the transfer of responsibility. Furthermore, the documentation should detail that where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment.
Modified
p. 110 → 141
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
TM2.3 The tester shall interview those responsible for the shipping control processes
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
Modified
p. 110 → 141
TM2.4 The tester shall observe the shipping and transfer procedures to ensure that procedures are followed to transfer accountability for the device from the manufacturer to the facility of initial deployment.
Modified
p. 110 → 141
TM2.5 The tester shall verify that where the device is shipped via intermediaries such as resellers, accountability is with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment.
Removed
p. 111
TJ3.1 The tester shall examine the vendor’s response to Section J3 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J3 of the PCI PTS HSM Modular Security Requirements for shipping tamper-protection documentation. The tester shall summarize the responses.
TJ3.6 The tester shall observe the shipping process to ensure that devices are shipped and stored”
• In tamper-evident packaging; and/or
• Containing a secret that is immediately and automatically erased if any physical or functional alteration to the device is attempted, that can be verified by the initial key- loading facility but that cannot feasibly be determined by unauthorized personnel.
TJ3.6 The tester shall observe the shipping process to ensure that devices are shipped and stored”
• In tamper-evident packaging; and/or
• Containing a secret that is immediately and automatically erased if any physical or functional alteration to the device is attempted, that can be verified by the initial key- loading facility but that cannot feasibly be determined by unauthorized personnel.
Modified
p. 111 → 142
- Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and
Modified
p. 111 → 142
- Can be verified by the initial key-loading facility but cannot feasibly be determined by unauthorized personnel.
Modified
p. 111 → 142
TM3.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the shipping process, tamper protection, instructions for receiving and inspection, as well as procedures for suspected tamper evidence; and describe how this shows compliance to this requirement.
Modified
p. 111 → 142
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
TM3.3 The tester shall interview those responsible for the shipping control processes
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
•including engineers, software developers, line staff, supervisory staff, technical management, etc.
Modified
p. 111 → 142
TM3.4 The tester shall examine a sample of documentation for tamper protection using secret keys to ensure approved procedures for validation at the key-loading facility are followed.
Modified
p. 111 → 143
•including inventory logs, shipping documentation, and device-
TM4.2 The tester shall examine a sample of documentation for device-development security, including user documentation and component validation procedures to ensure procedures are followed.
Removed
p. 112
TJ4.1 The tester shall examine the vendor’s response to Section J4 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J4 of the PCI PTS HSM Modular Security Requirements for consistency relevant to assure the authenticity of the TOE’s security-relevant components at the facility of initial deployment. The tester shall summarize the responses.
Modified
p. 112 → 143
TM4.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail the device’s development-security documentation to ensure the authenticity of the device’s security-relevant components and describe how this shows compliance to this requirement.
Modified
p. 112 → 143
•including engineers and line staff, supervisory staff, technical management, etc.
TM4.3 The tester shall interview those responsible for the initial key-loading facility
•including engineers and line staff, supervisory staff, technical management, etc.
•including engineers and line staff, supervisory staff, technical management, etc.
Modified
p. 112 → 143
TM4.4 The tester shall observe the secure development component control procedures to ensure security measures are followed during the initial key loading.
Modified
p. 112 → 144
TM5.2 The tester shall examine a sample of documentation, including user documentation, and component validation procedures to ensure procedures are followed.
Removed
p. 113
TJ5.1 The tester shall examine the vendor’s response to Section J5 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J5 of the PCI PTS HSM Modular Security Requirements for consistency relevant to assure the authenticity of the device security related components. The tester shall summarize the responses.
TJ5.4 The tester shall examine a sample of documentation, including user documentation, and component validation procedures to ensure procedures are followed.
TJ5.4 The tester shall examine a sample of documentation, including user documentation, and component validation procedures to ensure procedures are followed.
Modified
p. 113 → 144
TM5.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail procedures for the manufacturer to ensure the authenticity of the device’s security-relevant components.
Modified
p. 113 → 144
•including engineers and line staff, supervisory staff, technical management, etc.
TM5.3 The tester shall interview those responsible for the initial key-loading facility
•including engineers and line staff, supervisory staff, technical management, etc.
•including engineers and line staff, supervisory staff, technical management, etc.
Modified
p. 113 → 144
TM5.4 The tester shall observe the initial key-loading procedures to ensure the authenticity of the device’s security-related components is verified.
Removed
p. 114
TJ6.1 The tester shall examine the vendor’s response to Section J6 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J6 of the PCI PTS HSM Modular Security Requirements for consistency relevant to assure the manufacturer provides the means to the facility of initial deployment to assure the authenticity of the device’s security- related components. The tester shall summarize the responses.
Modified
p. 114 → 145
TM6.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail procedures provided by the manufacturer to the initial key-loading facility to assure the authenticity of the device’s security-relevant components for the initial key- loading facility.
Modified
p. 114 → 145
•including engineers and line staff, supervisory staff, technical management, etc.
TM6.2 The tester shall interview those responsible for the initial key-loading facility
•including engineers and line staff, supervisory staff, technical management, etc.
•including engineers and line staff, supervisory staff, technical management, etc.
Modified
p. 114 → 145
TM6.3 The tester shall examine a sample of documentation, including user documentation and component-validation procedures, to ensure procedures are followed at the facility of initial deployment.
Removed
p. 115
TJ7.1 The tester shall examine the vendor’s response to Section J7 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J7 of the PCI PTS HSM Modular Security Requirements for consistency relevant to the manufacturer providing a unique visible identifier for each device. The tester shall summarize the responses.
Modified
p. 115 → 146
TM7.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail how the change control procedures required in L1 are used in compliance with this requirement.
Modified
p. 115 → 146
TM7.3 The tester shall observe the manufacturing process to ensure the visible identifier is affixed to each device.
Modified
p. 115 → 146
TM7.4 The tester shall sample the devices to ensure that each visible identifier is unique and is consistent with the identifiers checked with the change control procedure in as required in L1.
Removed
p. 116
TJ8.1 The tester shall examine the vendor’s response to Section J8 of the PCI PTS HSM Modular Evaluation Vendor Questionnaire and the response to Requirement J8 of the PCI PTS HSM Modular Security Requirements for consistency relevant to assure the vendor maintains a manual that provides instructions for the operational management of the device. The tester shall summarize the responses.
Modified
p. 116 → 147
TM8.1 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. The documentation should include instructions for recording the entire life cycle of the device’s security-related components and the manner in which those components are integrated into a single device. The operations management manual must be current and up to date.
Modified
p. 116 → 147
•including engineers and software developers, supervisory staff, technical management, etc.
TM8.2 The tester shall interview those responsible for maintaining the operation management manual
•including engineers and software developers, supervisory staff, technical management, etc.
•including engineers and software developers, supervisory staff, technical management, etc.
Modified
p. 116 → 147
TM8.3 The tester shall examine a sample of the operations management manual to ensure procedures are followed and recorded.
Modified
p. 118 → 149
Expertise refers to the level of generic knowledge of the application area or product type (e.g., UNIX operation systems and Internet protocols). Identified levels are as follows:
Expertise refers to the level of generic capabilities including but not limited to knowledge, skills, experience, etc. of the application area or product type (e.g., UNIX operation systems and Internet protocols). Identified levels are as follows:
Modified
p. 118 → 149
b) Skilled persons are skilled in doing or using something and are able to do more complex tasks and attack steps. They have or can demonstrate the ability and training to perform a specific task well.
b) Skilled persons are able to perform more complex tasks and attack steps without direction. They have or can demonstrate the ability and training to perform a specific task well.
Modified
p. 118 → 149
c) Proficient persons are (highly) competent and have the necessary ability, knowledge, or skill to do something successfully. They are knowledgeable and skilled in that they are familiar with the security functionalities and behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully. Proficient personnel can acquire capabilities equivalent to the skill sets of PTS lab evaluators.
c) Proficient persons are (highly) competent and have the necessary ability, knowledge, and skill to perform complex attacks successfully. They are familiar with the security functionalities and behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully. Proficient personnel can acquire capabilities equivalent to the skill sets of PTS lab evaluators.
Modified
p. 118 → 149
c) Experts are very knowledgeable about or skillful in a particular area. They are very familiar with the underlying algorithms, protocols, hardware components, physical and logical architectures, etc., implemented in the device or system type and the principles and concepts of security employed. Experts are capable of quickly devising new attack paths that require specific competencies similar to those of experienced PTS lab personnel.
c) Experts are extremely knowledgeable and skillful in one or more areas. They are very familiar with the underlying algorithms, protocols, hardware components, physical and logical architectures, etc., implemented in the device or system type and the principles and concepts of security employed. Experts are capable of quickly devising new attack paths that require specific competencies similar to those of experienced PTS lab personnel.
Modified
p. 118 → 149
a) Public information about the HSM (or no information): Information is considered public if it can be easily obtained by anyone (for example, from the Internet) or if it is provided by the vendor to any customer.
a) Public information about the HSM (or no information): Information is considered public if it can be easily obtained by anyone (for example, from the Internet) or if it is provided by the vendor to any customer. Examples include open protocol specifications and electronic component datasheets. Information with automated access-control mechanisms (such as online account subscription) without human intervention classifies as Public.
Removed
p. 119
Care should be taken here to distinguish between information required to identify the vulnerability and the information required to exploit it, especially in the area of sensitive information. Requiring sensitive information for exploitation would be unusual.
Specialist expertise and knowledge of the HSM are concerned with the information required for persons to be able to attack an HSM. There is an implicit relationship between an attacker’s expertise and the ability to effectively make use of equipment in an attack. The weaker the attacker’s expertise, the lower the potential to effectively use equipment. Likewise, the greater the expertise, the greater the potential for equipment to be used in the attack. Although implicit, this relationship between expertise and the use of equipment does not always apply•for instance, when environmental measures prevent an expert attacker’s use of equipment; or when, through the efforts of others, attack tools requiring little expertise for effective use are …
Specialist expertise and knowledge of the HSM are concerned with the information required for persons to be able to attack an HSM. There is an implicit relationship between an attacker’s expertise and the ability to effectively make use of equipment in an attack. The weaker the attacker’s expertise, the lower the potential to effectively use equipment. Likewise, the greater the expertise, the greater the potential for equipment to be used in the attack. Although implicit, this relationship between expertise and the use of equipment does not always apply•for instance, when environmental measures prevent an expert attacker’s use of equipment; or when, through the efforts of others, attack tools requiring little expertise for effective use are …
Modified
p. 119 → 150
c) Sensitive information about the HSM (for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering).
c) Sensitive information about the HSM (for example, knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering). Distinction must be made between information required to identify the vulnerability and the information required to exploit it, especially in the area of sensitive information. Requiring restricted or sensitive information for exploitation would be unusual.
Modified
p. 119 → 150
Table 1: Multiple Samples Factors Number of Devices Factor Equipment refers to the equipment that is required to identify or exploit vulnerability. See Appendix B for details of equipment classification.
Table A-1: Multiple Samples Factors Number of Devices Factor Equipment refers to the equipment that is required to identify or exploit vulnerability. See Appendix B for details of equipment classification.
Modified
p. 119 → 150
b) Specialized equipment isn’t readily available to the attacker, but could be acquired without undue effort.
b) Specialized equipment isn’t readily available to the attacker but could be acquired without undue effort.
Modified
p. 120 → 151
Parts refer to components required to hide the signs of an attack; to otherwise replace components that have been broken during an attack, like a case part, a display or a printer; to create a data-monitoring or communicating bug; or otherwise are needed to perform the attack. If the same part may be used for identification and exploitation, it must only be accounted for once.
Parts refer to components required to hide the signs of an attack; to otherwise replace components that have been broken during an attack, like a case part, a display, or a printer; to create a data-monitoring or communicating bug; or otherwise are needed to perform the attack. If the same part may be used for identification and exploitation, it must only be accounted for once.
Modified
p. 120 → 151
b) Specialized parts are not readily available to the attacker but could be acquired without undue effort. These might be parts that can be ordered from the stock but require long delivery time or a certain minimum component count for purchase.
b) Specialized parts are not readily available to the attacker but could be acquired without undue effort. These might be parts that are not readily available from a supply store but can be ordered from stock and require delivery time or a certain minimum component count for purchase.
Modified
p. 120 → 151
Parts used during the Identification phase that can be used in the initial exploitation must be counted fully in the Exploitation phase to equalize the attack potential value across all exploitations. If it is not readily reusable
•the part once used in installation becomes unusable for exploitation because, for example, it is glued with epoxy and difficult to remove
•it can be accounted for twice: once in the Identification phase and again in the Exploitation phase.
•the part once used in installation becomes unusable for exploitation because, for example, it is glued with epoxy and difficult to remove
•it can be accounted for twice: once in the Identification phase and again in the Exploitation phase.
Parts used during the Identification phase that can be used in the initial exploitation must be counted fully in the Exploitation phase to equalize the attack potential value across all exploitations. While equipment readily lends itself to reuse for each exploitation, parts are typically a one-time use. Each exploitation should have the same attack potential value. Accounting for parts that are reused in the initial exploitation only in the Identification phase, or even splitting between the Identification and Exploitation phases, …
Removed
p. 122
First Attack Example The attack aims to insert a keypad signal-disclosing bug into an HSM that allows for manual key- component entry through the keypad. The bug is placed nearby the keyboard PCB, under the housing, and aims at monitoring the keypad signal and recording keypad entries.
1. Reverse-engineer the device to understand its design, including the tamper-detecting sensors and keypad signal. Expert level in electronics is required to understand the routing of security signals, as well as to understand the keyboard scanning method. Locations of tamper mechanisms are determined and methods devised to bypass/deactivate them. It is therefore determined that 60 working hours, expert skills, standard equipment and one mechanical sample are required.
3. The attack is exercised on a functional device with test keys. Injecting test keys as well as possibly resetting the tamper state requires having access to key-loading software or specification•rated as restricted knowledge.
1. Reverse-engineer the device to understand its design, including the tamper-detecting sensors and keypad signal. Expert level in electronics is required to understand the routing of security signals, as well as to understand the keyboard scanning method. Locations of tamper mechanisms are determined and methods devised to bypass/deactivate them. It is therefore determined that 60 working hours, expert skills, standard equipment and one mechanical sample are required.
3. The attack is exercised on a functional device with test keys. Injecting test keys as well as possibly resetting the tamper state requires having access to key-loading software or specification•rated as restricted knowledge.
Modified
p. 122 → 153
Determining Applicable Time and Levels For each phase, the testing laboratory shall document all necessary steps, including expertise, equipment, and specific parts needed, time required to operate (in hours), and when relevant, a probability of success.
Determining Applicable Time and Levels For each phase, the testing laboratory shall document all necessary steps, including expertise, equipment, specific parts needed, and time required to operate (in hours).
Modified
p. 122 → 154
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Public None 1 mechanical 60 hours 2. A bug is customized to monitor the keypad signals and record keypad entries. In this example, the scanning technique is simple, therefore the following levels apply: Expert, 30 hours’ work, standard parts, standard equipment, and reusing the same mechanical sample.
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Public None 1 functional 40 hours As a summary for the identification phase, the following would apply:
Modified
p. 122 → 154
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Public Standard None 30 hours
Expertise Equipment Knowledge Parts Samples Time needed Expert Specialized Public None None 80 hours
Removed
p. 123
2. Once inside, the attack needs to reach sensitive signals (e.g., key-scanning signals) located within a deeper layer of the device, protected by other, harder to defeat, tamper-detection mechanisms.
3. Once the previous step is successfully achieved, the attacker will now attach the keypad signal- disclosing bug to the keyboard lines, replace the housing, and test the device. The device is ready to be placed back at the target location. Specialized equipment is required to implant the bug, due to the limited access obtained from previous step.
Expertise Equipment Knowledge Parts Samples Time needed Proficient Specialized Public Standard (bug) 1 working with keys 6 hours As a summary for the exploitation phase, the following would apply:
3. Once the previous step is successfully achieved, the attacker will now attach the keypad signal- disclosing bug to the keyboard lines, replace the housing, and test the device. The device is ready to be placed back at the target location. Specialized equipment is required to implant the bug, due to the limited access obtained from previous step.
Expertise Equipment Knowledge Parts Samples Time needed Proficient Specialized Public Standard (bug) 1 working with keys 6 hours As a summary for the exploitation phase, the following would apply:
Modified
p. 123 → 154
1. Attack the tamper-detection mechanisms to penetrate into the device. It is deemed that, assuming the housing can be replaced by a spare part, each detection mechanism can be disabled with a success rate of 0.9 and requires one hour per mechanism. In this example, there are eight tamper-detection mechanisms, but only four of them need to be defeated. One additional hour is required to stabilize the attack.
1. Attack the tamper-detection mechanisms to penetrate into the device. It was deemed during testing that the casing has tamper-detection switches, and each detection mechanism can be disabled with a success rate of 0.95 and requires 30 minutes per mechanism. In this example, there are eight tamper-detection casing switches, but only four of them need to be defeated. One additional hour is required for setup and finalization of this stage of the attack.
Modified
p. 123 → 155
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Restricted Standard 1 mechanical 1 working with testing keys Exploitation Attacker uses a functional sample with keys and implements the attack. Several steps are necessary to perform the attack:
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard (reused) Public None 1 working with keys 4 hours
Modified
p. 123 → 155
Expertise Equipment Knowledge Parts Samples Time needed Expert Standard (reused) Public None 1 working with keys 12 hours
Expertise Equipment Knowledge Parts Samples Time needed Proficient Specialized (reused) Public None 1 working with keys 4 hours As a summary for the exploitation phase, the following would apply:
Removed
p. 124
Table 3: Attack Potential for Inserting a Keypad Signal-Disclosing Bug Aspect Identifying Value Exploiting Value Attack time ≤ 160h 7 ≤ 24 h 3 Expertise Expert 4 Expert 4 Knowledge of the device Restricted 2 Public 0 Access to HSM 1 mechanical sample 1 working sample without working key 4 Functional sample with working keys Equipment Standard 1 Specialized 3 Specific parts Standard 1 Standard 1 Attack potential per phase 19 15 Total Attack Potential 34 Second Attack Example The attack aims at the determination of a TDES key used for encryption at the device using differential power analysis (DPA). It is assumed that:
Modified
p. 124 → 156
1. Determine the method to run DPA on a HSM. This consists mostly of analyzing the electrical and logical interface. This step requires professional knowledge of electronic and computer engineering.
1. Determine the method to run DPA on an HSM. This consists mostly of analyzing the electrical and logical interface. This step requires professional knowledge of electronic and computer engineering.
Modified
p. 124 → 156
3. Get a HSM and perform the measurement. We expect that at least 20,000 PIN translations and the associated decryptions/encryptions have to be observed. In the identification phase, this may have to be repeated several times. Since such an amount of translation operations cannot be performed surreptitiously in a real live environment, it must be possible to run the device off-line with a simulated host.
3. Get an HSM and perform the measurement. We expect that at least 20,000 PIN translations and the associated decryptions/encryptions have to be observed. In the identification phase, this may have to be repeated several times. Since such an amount of translation operations cannot be performed surreptitiously in a real live environment, it must be possible to run the device off-line with a simulated host.
Removed
p. 125
Table 4: Attack Potentials Example for DPA Analysis Aspect Identifying Value Exploiting Value Attack time Beyond 160h 7.5 ≤ 8 h 3 Expertise Expert 4 Expert 4 Knowledge of the device Restricted 2 Public 0 Access to PIN entry device Functional sample with trial keys 2 Functional sample with working keys Equipment Bespoke 5 Specialized 3 Specific parts Standard 1 No further parts Attack potential per phase 21.5 14 Total Attack Potential 35.5 Payment Card Industry PTS HSM Modular Derived Test Requirements, v3.0
• Simple side-channel software (able to perform basic sum-of-least-squares alignment and single order correlation attacks)
• Oven (up to 250 C) and freezer/cooler with dry ice (down to -78.5 C)
• Standard PC (either off the shelf or built from components) Payment Card Industry PTS HSM Modular Derived Test Requirements, v3.0
• Simple side-channel software (able to perform basic sum-of-least-squares alignment and single order correlation attacks)
• Oven (up to 250 C) and freezer/cooler with dry ice (down to -78.5 C)
• Standard PC (either off the shelf or built from components) Payment Card Industry PTS HSM Modular Derived Test Requirements, v3.0
Modified
p. 126 → 157
• Oscilloscope
•up to around200Mhz with some leeway either way depending on buffers, bit-depth of A/D, additional features, etc.
•up to around
• Oscilloscopes with two channels and external trigger inputs
•up to around 1GHz with some leeway either way depending on buffers, bit-depth of A/D, additional features, etc.
•up to around 1GHz with some leeway either way depending on buffers, bit-depth of A/D, additional features, etc.
Removed
p. 127
• It is expected that this will be run on a standard PC (Standard equipment)
• EMFI glitching system
• Electron tunneling microscope/Scanning Electron Microscope Note on “parts”: Although this document does not seek to outline all types of parts, it is considered that the vast majority of PIN bugs will be considered as standard parts, including those that use a flexible circuit mat to cover the keypad (as this is very common during PIN attacks).
• EMFI glitching system
• Electron tunneling microscope/Scanning Electron Microscope Note on “parts”: Although this document does not seek to outline all types of parts, it is considered that the vast majority of PIN bugs will be considered as standard parts, including those that use a flexible circuit mat to cover the keypad (as this is very common during PIN attacks).
Modified
p. 127 → 158
• Expensive, high-resolution, high-frequency, deep-buffer oscilloscopes (> 1GS/s, 1GHz, 16 bit, etc.)
• Expensive, high-resolution, high-frequency, deep-buffer oscilloscopes (> 1GS/s, 1GHz, 16-bit, etc.)
Modified
p. 127 → 158
• Complex side-channel software, able to perform complex alignment, noise removal, etc.
• Complex side-channel software, able to perform complex alignment beyond linear shift techniques, and relatively advanced, noise removal, etc., in accordance with the tool capabilities described in Appendix F. It is expected that this will be run on a standard PC (Standard equipment)
Modified
p. 127 → 158
• 16/32 bit high-speed logic analyzer for capture and analysis of bus traffic
• 16/32-bit high-speed logic analyzer for capture and analysis of bus traffic
Modified
p. 127 → 158
Chip-level equipment “Rule of thumb” followed: Absolutely required for attacks at the feature level on chips (not bus level).
• Sophisticated X-ray 3-D imaging equipment Chip-level equipment “Rule of thumb” followed: Absolutely required for attacks at the feature level on chips (not bus level).
Removed
p. 128
Payment Card Industry PTS HSM Modular Derived Test Requirements, v3.0
Modified
p. 128 → 159
A note on STS versions: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test [Hamano 2009], and include fixes to the DFT (Spectral) test [Kim 2004], the Overlapping Template test [Hamano 2007], the Non-Overlapping test [NIST 2014], and the “Proportion of Sequences Passing a Test” …
A note on STS versions: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test [Hamano 2009] and include fixes to the DFT (Spectral) test [Kim 2004], the Overlapping Template test [Hamano 2007], the Non-Overlapping test [NIST 2014], and the “Proportion of Sequences Passing a Test” …
Modified
p. 129 → 160
(See SP800-22r1a Section 2.11.7.) [9] The Linear Complexity test block length is required to be set to between 500 and 5,000 (inclusive), and requires that . (See SP800-22r1a Section 2.10.7.) References [Rukhin 2010] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications,” NIST SP 800-22, Revision 1a.
(See SP800-22r1a Section 2.11.7.) [9] The Linear Complexity test block length is required to be set to between 500 and 5,000 (inclusive) and requires that . (See SP800-22r1a Section 2.10.7.) References [Rukhin 2010] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications,” NIST SP 800-22, Revision 1a.
Modified
p. 130 → 164
Payment Card Industry PTS HSM Modular Derived Test Requirements, v3.0
Payment Card Industry PTS HSM Modular Derived Test Requirements, v4.0
Removed
p. 131
Algorithm DES RSA Elliptic Curve DSA AES Minimum key size in number of bits: 112 2048 224 2048/224 128 Key-encipherment keys shall be at least of equal or greater strength than any key that they are protecting. This applies to any key-encipherment keys used for the protection of secret or private keys that are stored or for keys used to encrypt any secret or private keys for loading or transport. For purposes of this requirement, the following algorithms and keys sizes by row are considered equivalent.
4. Entities must authenticate the DH or ECDH public keys using DSA, ECDSA, a certificate, or a symmetric MAC (see ISO 16609
•Requirements for message authentication using symmetric techniques). One of the following should be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4.
4. Entities must authenticate the DH or ECDH public keys using DSA, ECDSA, a certificate, or a symmetric MAC (see ISO 16609
•Requirements for message authentication using symmetric techniques). One of the following should be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4.
Modified
p. 131 → 163
• Minimum key size in number of bits: 168 2048 224 2048/224
• Minimum key size in number of bits:
• 3072 256 3072/256 128 Minimum key size in number of bits:
• 7680 384 7680/384 192 Minimum key size in number of bits:
• 15360 512 15360/512 256
• 15360 512 15360/512 256 TDES refers to TDES keys with non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. The DSA key sizes refer to the size of the modulus and the minimum size of a large subgroup.
Modified
p. 131 → 163
For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH):
For implementations using FFC or ECC:
Modified
p. 131 → 163
•
• 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity must generate a private key x and a public key y using the domain parameters (p, q, g).
Modified
p. 131 → 163
• ECC implementations entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (see NIST SP 800-186). The elliptic curve specified by the domain parameters must be at least as secure as P-224. Each entity must generate a private key d and a public key Q using the specified elliptic curve domain parameters. (See NIST SP 800-186 for methods of generating d and Q.)
Modified
p. 131 → 163
• Each private key must be statistically unique, unpredictable, and created using an approved random number generator as described in this document.
Modified
p. 132 → 164
Note: This appendix is for use in conjunction with Requirement A5
• “Determining Keys Analysis.” Objectives Attackers’ objectives are to compromise high-value cryptographic keys in a device by finding leakage. Testers’ objectives are to search for paths to key leakage to be able to validate resistance to attacks. A test performed in accordance with the DTRs can result in no detectable leakage, may show how a key can be fully exposed but at an acceptable level of difficulty, or may produce …
• “Determining Keys Analysis.”
Note: This appendix is for use in conjunction with Requirement A5, “Non-Invasive Attacks for Cryptographic Keys.” Objectives Attackers’ objectives are to compromise high-value cryptographic keys in a device by finding leakage. Testers’ objectives are to search for paths to key leakage to be able to validate resistance to attacks. A test performed in accordance with the DTRs can result in no detectable leakage, may show how a key can be fully exposed but at an acceptable level of difficulty, or …
Modified
p. 132 → 164
Introduction Side-channel analysis (SCA) is an important activity in PCI PTS evaluations, relevant to tests where the highest levels of confidence in security assurance are needed, as part of Determining Keys Analysis•for example PTS v4.x DTR A6, requiring 35 points rating overall / 15 points minimum in exploitation. In these tests, it is necessary to derive an accurate measure of the effort to defeat a device using SCA techniques, distinctly from any physical penetration/modification.
Introduction Side-channel analysis (SCA) is an important activity in PCI PTS evaluations, relevant to tests where the highest levels of confidence in security assurance are needed, as part of DTR A5 In these tests, it is necessary to derive an accurate measure of the effort to defeat a device using SCA techniques, distinctly from any physical penetration/modification.
Modified
p. 132 → 164
Evaluations do not have to fully replicate SCA as would be applied in the field; a targeted, focused, ”quick-scan” approach based on optimized practices capable of assessing key leakage is sufficient. The information below provides guidance and a framework for testing. In no circumstances should this be interpreted as a formula or checklist of necessary procedures.
Evaluations do not have to fully replicate SCA as would be applied in the field; a targeted and focused ”quick-scan” approach based on optimized practices capable of assessing key leakage is sufficient. The information below provides guidance and a framework for testing. In no circumstances should this be interpreted as a formula or checklist of necessary procedures.
Modified
p. 132 → 164
This appendix provides an outline of SCA critieria to indicate PCI SSC’s expectations regarding PTS- recognized Laboratory capabilities. This does not define a complete scope of the application of SCA and should not be interpreted as the boundary of what is adequate. This appendix provides supplementary information that can be referred to by evaluators, but it is not a tutorial. This memorandum may be used as a guideline for structuring tests and providing test evidence in reports.
This appendix provides an outline of SCA criteria to indicate PCI SSC’s expectations regarding PTS- recognized Laboratory capabilities. This does not define a complete scope of the application of SCA and should not be interpreted as the boundary of what is adequate. This appendix provides supplementary information that can be referred to by evaluators, but it is not a tutorial. This memorandum may be used as a guideline for structuring tests and providing test evidence in reports.
Modified
p. 134 → 166
• SCA toolsets are updated incrementally to: improve performance, increase attack potential, remove bugs, and identify and resolve usability issues.
• SCA toolsets are updated incrementally to improve performance, increase attack potential, remove bugs, and identify and resolve usability issues.
Modified
p. 134 → 166
SCA tests must not be hindered by the types of obstacles that experienced attackers having contemporary tools can overcome straightforwardly. The following, non-exhaustive list gives examples of factors related to PCI SSC’s expectations in testing.
Modified
p. 135 → 167
• Understanding of the algorithm(s) to be attacked and how they are implemented: Determining the appropriate side channel(s) to acquire, collection method(s) and analysis tools, and their configuration. Next, validating that the device behaves as expected before proceeding further; if necessary gathering additional information and/or reconfiguring the test setup as required. This includes validation of: hardware/software identifiers and claimed countermeasures.
• Understanding of the algorithm(s) to be attacked and how they are implemented: Determining the appropriate side channel(s) to acquire, collection method(s) and analysis tools, and their configuration. Next, validating that the device behaves as expected before proceeding further⎯if necessary, gathering additional information and/or reconfiguring the test setup as required. This includes validation of hardware/software identifiers and claimed countermeasures.
Modified
p. 135 → 167
• Preparing the device: While many of the considerations for the assessment on device physical penetration or modification are relevant to performing SCA, PCI SSC expects that in most cases SCA is to be performed without needing challenging physical adaptation; the vendor’s assistance must significantly assist the ease of operating the device or, commonly, a specially prepared subset of the device (such as the security processor abstracted from the device). An important part of the evaluation is to determine which …
• Preparing the device: While many of the considerations for the assessment on device physical penetration or modification are relevant to performing SCA, PCI SSC expects that in most cases the vendor’s assistance must significantly ease the operation of the device and/or a specially prepared subset of the device (such as the security processor abstracted from the device). An important part of the evaluation is to determine which of these possibilities is optimum to assess leakage of the cryptographic implementation …
Modified
p. 136 → 168
• Signal analysis and processing: All side-channel recordings will contain a certain degree of noise in acquired waveforms
•for example, ambient noise sources in the test apparatus and environment, including a device’s physical architecture. Any noise source can be expected to introduce artifacts into side channels that obstruct an attacker seeking to identify exploitable signals such as:SPA patterns, correlation leakage pinpointing sensitive operations, and key-dependent leakage. Many types of hardware-generated and algorithmic SCA countermeasures exist. When implemented appropriately, individual countermeasures …
•for example, ambient noise sources in the test apparatus and environment, including a device’s physical architecture. Any noise source can be expected to introduce artifacts into side channels that obstruct an attacker seeking to identify exploitable signals such as:
• Signal analysis and processing: All side-channel recordings will contain a certain degree of noise in acquired waveforms
•for example, ambient noise sources in the test apparatus and environment, including a device’s physical architecture. Any noise source can be expected to introduce artifacts into side channels that obstruct an attacker seeking to identify exploitable signals such as: SPA/SEMA patterns, correlation leakage pinpointing sensitive operations, and key- dependent leakage. Many types of hardware-generated and algorithmic SCA countermeasures exist. When implemented appropriately, individual …
•for example, ambient noise sources in the test apparatus and environment, including a device’s physical architecture. Any noise source can be expected to introduce artifacts into side channels that obstruct an attacker seeking to identify exploitable signals such as: SPA/SEMA patterns, correlation leakage pinpointing sensitive operations, and key- dependent leakage. Many types of hardware-generated and algorithmic SCA countermeasures exist. When implemented appropriately, individual …
Modified
p. 136 → 168
• Cryptanalysis: Attacks such as DPA succeed by discriminating a few inferences of guessed key values from among many other possible values. One specific algorithm’s key-leakage potential is unlikely to be similar to another algorithm or implementation. Detectable leakage is often highly dependent on the options an attacker pursues. Hence, a simplistic implementation of a published attack, alone, is often insufficient to validate a device’s compliance and the evaluation should make use of attack-modeling options available to expert attackers. Examples …
• Cryptanalysis: Attacks such as DPA succeed by discriminating a few inferences of guessed key values from among many other possible values. One specific algorithm’s key-leakage potential is unlikely to be similar to another algorithm or implementation. Detectable leakage is often highly dependent on the options an attacker pursues. Hence, a simplistic implementation of a published attack, alone, is often insufficient to validate a device’s compliance and the evaluation should make use of attack-modeling options available to expert attackers. Examples …
Modified
p. 136 → 169
• Optimization: There are many approaches that will improve the chance of SCA success, considering the application of critical steps such as those outlined above. Depending on the discoveries made early in analysis, it is likely that some of the steps performed should be adapted, branched, and repeated
•for example by iteratively re-applying well-chosen processes. Large data size may become problematic in some situations; however expert attackers are skilled in overcoming this unless robust obstacles are present
•for example, analysis time may …
•for example by iteratively re-applying well-chosen processes. Large data size may become problematic in some situations; however expert attackers are skilled in overcoming this unless robust obstacles are present
•for example, analysis time may …
• Optimization: There are many approaches that will improve the chance of SCA success, considering the application of critical steps such as those outlined above. Depending on the discoveries made early in analysis, it is likely that some of the steps performed should be adapted, branched, and repeated
•for example by iteratively re-applying well-chosen processes. Large data size may become problematic in some situations; however expert attackers are skilled in overcoming this unless robust obstacles are present
•for example, analysis time may …
•for example by iteratively re-applying well-chosen processes. Large data size may become problematic in some situations; however expert attackers are skilled in overcoming this unless robust obstacles are present
•for example, analysis time may …
Modified
p. 137 → 169
The outcome for an evaluation’s SCA testing is to either defeat the device emulating a realistic attack scenario or derive a definitive rating showing that the effort for an attack in the field is clearly above the necessary threshold. If the latter is not achieved in a test, detailed evidence is necessary to demonstrate compliance otherwise. The evaluation test report is the principle resource for demonstrating compliance to Security Requirements. The report must be self-consistent and adequate to justify compliance …
The outcome for an evaluation’s SCA testing is to either defeat the device emulating a realistic attack scenario or derive a definitive rating showing that the effort for an attack in the field is clearly above the necessary threshold. If the latter is not achieved in a test, detailed evidence is necessary to demonstrate compliance otherwise. The evaluation test report is the principal resource for demonstrating compliance to Security Requirements. The report must be self-consistent and adequate to justify compliance …
Modified
p. 138 → 170
• Local key protection (internal and external memory encryption), and
• Local key protection (internal and external memory encryption),
Modified
p. 138 → 170
• Authentication (e.g., firmware).
• Authentication (e.g., firmware), and
Modified
p. 138 → 170
The evaluation should determine at least one algorithm to analyze thoroughly, based on a rigorous assessment of asset value versus feasible attacks. Reasoning for not testing any algorithm has to be explained. This reasoning should include reliable assumptions made in the vulnerability analysis based on: asset value and attack complexity•for example, limits on collections such as delay insertions or key- usage counters, and any additional countermeasures.
The evaluation should determine at least one algorithm to analyze thoroughly, based on a rigorous assessment of asset value versus feasible attacks. Reasoning for not testing any algorithm has to be explained. This reasoning should include reliable assumptions made in the vulnerability analysis based on asset value and attack complexity•for example, limits on collections such as delay insertions or key- usage counters, and any additional countermeasures.
Modified
p. 138 → 170
Prerequisites To facilitate testing, the vendor must provide “open” samples (with a wire or pin attached for triggering and, if applicable, attachments to locations agreed with the lab for power measurements). The vendor must provide specially adapted firmware to allow cryptographic operations’ input/outputs to be collected. For both EMA and power consumption, the measurement shall be performed directly at the chip/processor.
Prerequisites To facilitate testing, the vendor must provide “open” samples (with a wire or pin attached for triggering and, if applicable, attachments to locations agreed with the lab for power measurements). The vendor must provide specially adapted firmware to allow cryptographic operations’ input/outputs to be collected. For both EMA and power consumption (if possible), the measurement shall be performed directly at the chip/processor.
Modified
p. 138 → 170
Effort for analyzing one implementation of an algorithm The descriptions below outline typical parameters that are acceptable for testing. Good attackers are creative and will not limit their efforts to below pre-defined limits such as disk storage size or an exact number of acquisitions, etc. PCI SCC expects the degree of any key leakage to be quantified using effective techniques (e.g., correlation, key attacks related to DPA, etc.) that are in agreement with these typical parameters but without reliance on …
Effort to complete the overall device side-channel analysis The descriptions below outline typical parameters that are acceptable for testing. Good attackers are creative and will not limit their efforts to below pre-defined limits such as disk storage size or an exact number of acquisitions, etc. PCI SCC expects the degree of any key leakage to be quantified using effective techniques (e.g., correlation, key attacks related to DPA, etc.) that are in agreement with these typical parameters but without reliance on …
Modified
p. 138 → 170
For evaluating cryptographic implementations developed by the device vendor, the overall side-channel analysis effort should be expert-level work, assuming that well-prepared samples are available for analysis with effective tools, and assuming that testers are skilled in applying robust methodologies using these tools. Elapsed time is four weeks in most situations⎯for example, to allow collections and computationally expensive processes to run automatically. EMA is generally expected to provide better results than other side channels; it is sufficient for a lab to …