Document Diff - PCI Watch

Added p. 2

December 2021 4.0 Added new module, “Cloud-Based HSMs as a Service

• Multi-tenant Usage Security Requirements.”

Added p. 6

This is particularly important for Multi-tenant HSM Solutions, which have been addressed since version 4 of this standard. In these implementations, the HSM user is not the same entity that is deploying and managing the HSM Solution being used, and there may be multiple users present and operating on any one Cloud-based HSM Solution.

Added p. 9

• For the purposes of PTS, the definition of “impractical” or “not practical” should be understood as not feasible within the scope of the PTS DTRs, for example, according to attack potential values and/or other criteria stated in the DTRs and guidance.

Added p. 11

Multiple test requirements require the test laboratories to review source code to facilitate validation to the applicable Security Requirements. Unless stated in the test requirement that the sample is not required, the code segments (snippets) are considered evidence of meeting the security requirement. Code samples serve as evidence in a manner similar to the inclusion of pictures of hardware components as evidence in meeting physical requirements.

Requirement The laboratory shall produce an Asset Flow Diagram highlighting each physical and logical component in the device and indicating how each asset flows between each physical component, showing the logical modules used to protect it. The goal is to indicate the status of an asset as it travels through the device⎯for example, whether the asset is cleartext or encrypted at a point in the data flow. Any hardware component or software module interfacing with the asset shall be virtually marked (or tagged) with the …

Added p. 12

For those devices that do not contain sensitive data, device disablement may be used in lieu of “immediate erasure of any sensitive data.” The device is protected against penetration by including features that: (i) detect any practical attempts to tamper with the device; and (ii) cause immediate erasure of all cryptographic keys and sensitive data when such an attempt is detected.

Added p. 13

• Vias of “upper grid” must be protected separately from vias of “lower grid”

•for example, the two tamper grids must not be connected by vias that are accessible on both grid layers, or vias must be protected by other tamper mechanisms, such as switches.

These best practice items apply to meshes in copper-on-substrate tamper grids. Tamper grids using other technologies may have different best practices. Implementations deviating from this best practice may be considered, but strong justification and testing evidence from the lab is required, including details on how the implementation under test meets or exceeds the level of security provided by the above best practice.

The attack potential is calculated to either disable all tamper detection or to gain sufficient access into areas where cleartext sensitive data is present in a form that is easily compromised.

Added p. 13

TA1.1 The tester shall provide an Asset Flow Diagram, which is in accordance with Appendix F. The asset flow diagram must be complete, accurate, and unambiguously map all hardware blocks to a security domain.

b) The version of the PCB (and PCBA version, if provided), and the main purpose of the

Added p. 16

TA1.29 Describe the different attack paths considered. Using the format shown in Appendix A, the tester shall generate attack costings using different attack techniques on the device, and present the two most practical. The attacks should be dissimilar in approach unless the lab can fully justify the infeasibility of any second divergent approach. The tester shall state explicitly where testing has verified any specific stage of the attack (including the time, equipment, skill required, and number of mechanisms to bypass), and where assumptions are used in place of testing. The tester shall justify why any assumptions have been used instead of actual testing. Calculations shall include evidence justifying particular rating levels as being appropriate.

Added p. 19

Sensitive functions or data are defined by the device implementation and asset flow, and include all account data, all cryptographic material used to protect that account data, and all firmware.

The protected areas of the device are defined as the areas that meet the attack rating of this requirement, and that are covered by the tamper-detection and response features of the device.

A component providing lower security is defined as anywhere that the data is not protected to a level of 26 points, as per this requirement.

Added p. 21

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

TA3.13 The tester shall attempt to transfer a cryptographic key to a component providing lower security.

Added p. 22

External memory is memory where keys are exposed outside of the die of the processing element, including on multi-die BGA packages.

Added p. 29

• Pre-operational critical functions test.

Added p. 30

In the case that the error log does not contain any sensitive module information, an operator can assume an authorized (any defined) role that does not require authentication in order to gain access to the module’s error log. CSPs cannot be present in the error log. The access also must not allow the modification or substitution of PSPs.

Added p. 31

Note: The private key may reside in the module only if the signature is generated on the module immediately after deploying the firmware, and in such cases the private key must be unique per device, and useable only for checking the authenticity for firmware already installed.

Added p. 32

e) Other self-tests that are performed pre-operation and on demand.

Added p. 37

Interfaces may be excluded from this requirement if:

• They are internal only (memory buses, or inter-IC buses).

• They are logically isolated from firmware or applications handling sensitive data (PINs, account data, cryptographic keys) by an enforcing mandatory access-control framework.

• They do not provide bi-directional communication (such as LEDs, buzzers, etc.).

Added p. 38

The tester shall identify in the report the publicly available sources of vulnerability disclosure used.

Added p. 43

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, such that they provide an effective key strength of 128 bits or stronger. Examples of appropriate algorithms are stated in Appendix D (excluding TDES), along with examples of acceptable hashing algorithms.

Added p. 44

TB3.1.7 The tester shall verify that authentication methods with known weaknesses, such as a CBC MAC, are not used for application authentication.

Added p. 46

• A key has been transferred and the device has no further use for the key,

• A secret or private key has been generated and any intermediate values are no longer needed, or

• The key is cleared after key usage, e.g., following a decryption operation.

The buffer space cleared is that holding the particular sensitive information that is no longer needed.

Added p. 51

Where the HSM provides a function to generate authentication values, these values are generated using a random or pseudorandom function. Examples of authentication values are one-time passwords or other values used in challenge/response processes. Authentication values within the module are transient and are considered a temporary critical security parameter.

All DRBGs must be seeded by an NRBG that provides sufficient authenticated entropy. The entropy required should be twice as many bits as the intended key strength and must not be less than the minimum effective bit strength of the key being generated. Entropy sources are discussed in NIST SP 800-90B.

Added p. 52

TB7.4 The tester shall validate that where the HSM provides a function to generate authentication values, these values are generated using a random or pseudorandom function.

Added p. 53

Post-Quantum Cryptography (PQC), also known as Quantum Resistant, should be supported in addition to classic cryptography. Specifically, cryptographic algorithms that are currently thought (e.g., as published by NIST) to be secure against a cryptanalytic attack by a quantum computer. See Appendix D.

• Testing performed by the evaluator. TB 8.5 The tester shall determine whether post-quantum cryptography is supported. Where validated as supported, the tester shall note it in the report.

Added p. 55

Devices must implement unique secret and private keys for any function directly or indirectly related to device security. This does not apply to public keys resident in the device.

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.

In support of ECC used in the EMV® Contact and Contactless Specifications, HSMs used in personalization must support the Elliptic Curve Schnorr Digital Signature Algorithm (EC-SDSA).

TB9.3 The tester shall verify that the minimum key sizes and parameters for the algorithm(s) for key management used for device security (such as firmware authentication, tamper/storage keys, etc.) must provide an effective key strength of 128 bits …

Added p. 60

This requirement does not preclude KEKs from being converted to KBPKs, where supported by the devices.

Added p. 62

Cleartext secret and private keys and cleartext PINs must not exist in unprotected environments.

Added p. 64

This table illustrates restrictions on translations between PIN-block formats that are applicable when the HSM is not using a unique-key-per-transaction encryption for the resulting PIN block. When a request is using UKPT for the output PIN block, any translation (with respect to other rules) is allowed.

- Permitted anywhere without a change of PAN - Change of PAN only permitted in a sensitive state for card issuance - Change of PAN Token to real PAN is only permitted with cryptographic binding of PAN Token to real PAN Not permitted Permitted for submission to an TB13.2 From the above list of PIN-block formats, the tester shall confirm that the HSM supports ISO PIN-block format 4 if the device supports online PIN. The device may optionally support formats 0, 1, or 3 for online PINs.

• Where the introduction of a new PAN is required to support account number changes for card issuance, support …

Added p. 66

Long-term storage, correlation, alerting, and monitoring may be performed by external systems (e.g., SIEMs or log-management platforms). The division of responsibilities between the HSM and external log infrastructure must be documented in the device's security policy, while still ensuring integrity, authenticity, and tenant isolation of log data.

Added p. 67

This requirement applies when the applications are all associated with a single tenant. Where applications associated with different tenants are executed on a single device, isolation techniques compliant with DTR F3 shall be used.

Added p. 70

For example, OS/firmware modules such as peripheral drivers, file systems, or inter-process communication protocols shall be regarded as components. Applications responding to external interfaces or communicating with the firmware shall be regarded as services.

Added p. 73

If a key hierarchy in a device is used in PCI mode or designated for PCI mode by the user, according to the device security policy, then the management and use of the key hierarchy and the keys protected by it are restricted to functionality―including cryptographic algorithms and protocols―that meet these HSM Security Requirements. A key hierarchy consists of the operational keys and key- protection keys that are protected under a single LMK/MFK of a secure cryptographic device.

Added p. 74

The device must be delivered in a secure state unless otherwise agreed to, and users must be able to restore the product to its original secure state. This secure state includes:

• No Universal Default Passwords: Unique, strong passwords must be generated per device, not generic ones such as "admin.”

• Minimized Attack Surfaces: Unnecessary network services and interfaces should be turned off by default.

• Strong Access Controls: Mechanisms to prevent unauthorized access must be present from first use.

• Secure Configurations: Default settings should prioritize security over convenience (e.g., turning off remote access unless explicitly enabled).

Also see DTR B16 - Minimal Configuration, and Evaluation Module 5: Life Cycle Security Requirements.

TB19.1 The tester shall examine documentation to verify the device meets this requirement as described in the guidance.

TB19.2 The tester shall verify that all conditions, as described above in the guidance, are met by the device.

Added p. 75

Switched network connections include Ethernet. Connections not requiring support for a secure channel include ICC interfaces and direct-connect keyboard interfaces. KLDs and RAP devices may support wireless connections.

Secure channels may be implemented using industry standard protocols such as TLS or SSH, or may be implemented using device-specific cryptography. In all cases, the secure channel is required to be supported in addition to any asset-level encryption. That is, a secure channel cannot be used to meet requirements for encryption or authentication of assets, such as requirements for key wrapping.

Enforcement of secure channels on all interfaces is not required by this standard. Secure channels are required to be supported but may not be used by the HSM deployer. Requirements for the enforcement of use of secure channels may exist in other PCI standards.

TB20.1 The tester shall examine documentation to verify that secure channels are supported on all connections that implement a switched …

Added p. 76

TC1.4 The tester shall confirm the security policy defines and documents all hardware and firmware identifiers, as listed on the PCI website, including those security and non-security relevant. Security-relevant options must be exhaustively defined and documented. For non-security options, the security policy must include a description of the option, but not a full list of all possible values. An example would be non-PCI mode⎯e.g., FIPS or PCI-mode support. If wildcards are used, the specific configurations validated by the PCI-Recognized Laboratory must be explicitly noted.

Added p. 78

TC1.18 The tester shall examine the security policy to verify that the device is properly identified.

Added p. 79

TC1.24 The tester shall confirm that the security policy addresses how the device is designed to be delivered in a secure state to the end customer.

TC1.25 The tester shall confirm that the security policy includes procedures for the ability to erase all sensitive data and configuration settings at its end-of-life or prior to transfer and re-deployment.

Each key-transfer mechanism is required to meet one of the following requirements. Individual keys may be imported or exported using one or more key-transfer mechanisms but must only use the key-transfer mechanisms specifically allowed.

These requirements are designed to be applied to all device types⎯including HSMs, RAPs, and KLDs⎯ and uses of cryptography, including remote administration, firmware management, and general cryptography.

DTR D1 Key Entry and Export Key entry and export are performed using only the techniques in the table below.

Key Form Manual Direct Network Cleartext keys No Yes No Cleartext key components Yes Yes No Enciphered …

Added p. 81

TD1.1 The tester shall consider all keys that are entered into and exported from the device and confirm that only compliant key forms and key-loading techniques are used.

TD1.2 For each key that can be loaded or exported, the tester shall confirm the key has been considered and found compliant against the assessment of the relevant requirement from Module 2 (Key-Transfer Functionality Requirements).

TD1.3 The tester shall describe the conditions upon which keys may be exported and confirm that only keys designated as exportable during creation or import can be subsequently exported.

TD1.4 The tester shall confirm that, by default, keys generated or imported into the device are not exportable, or else the change to being exportable must require dual control.

• Cleartext keys can only be manually entered as components.

• Cleartext keys can only be manually exported as components.

• Manual key operations require the use of dual-control techniques.

• Keypads, ICCRs, and other interfaces …

Added p. 83

TD2.5 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 for all but one share to perform the aforementioned.

For any methods that rely on the use of AES 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. For key shares, the tester shall use the same value for all but one share to perform the aforementioned.

TD2.6 The tester shall confirm the device will not manually output …

Added p. 84

• The device shall require explicit local authentication before allowing entry into the transfer mode.

• The device shall be designed to allow the operator to sight the complete cable between the key-export device and the key-import device.

• The device supports an encrypted transport mechanism.

This requirement applies to electronic key-loading techniques that are unsuitable for remote methods due to the absence of mutual authentication, lack of encryption, or other security limitations. Key- exchange techniques used for remote key loading are assessed under D4 or D5.

For the operator to sight the complete cable, the cable must terminate on an external face of the HSM that can be expected to be exposed during operation (such as the front face). The cable interface must not be recessed into the casing to where the point-of-termination cannot be observed by a user of the HSM.

Direct key injection is designed for situations where an operator can sight …

Added p. 85

TD3.5 The tester shall confirm the device will not output any cleartext key except under dual control using a direct connection. Such dual control is enforced by means such as the following:

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

• The device requires that at least two different physical keys―marked “not to be commercially reproduced”―be concurrently inserted in the unit before it will output a key.

Added p. 86

For storage and distribution of symmetric keys or private keys using symmetric techniques:

• Where the key and sensitive attributes field are encrypted with TDES, devices must support the ANSI X9.143 key-derivation methodology. The device may optionally support, in addition, the ANSI X9.143 Key Variant Binding Method or the TDKW method from ANSI X9.102. The device may optionally support equivalent methods as described below.

• Where the key and sensitive attributes field are encrypted with AES, devices must support the X9.143 methodology and/or the ISO 20038 methodology. The device may also optionally support mechanism 2 of ISO/IEC 19772. The device may optionally support equivalent methods as described below.

X9.143 is recognized as the standard for interoperable methods for both TDEA and AES. ISO 20038 is recognized as an interoperable method for AES. This does not imply that the device must enforce ANSI X9.143 or ISO 20038 or an equivalent scheme, but it must …

Added p. 86

• One or more attributes that define whether the protected key may be transferred outside the cryptographic domain in which the key is found⎯i.e., exportability.

• Use of key-length obfuscation padding for symmetric keys to the maximum length for the algorithm, 192 bits for TDEA and 256 bits for AES.

• Authentication over the encrypted key and attributes⎯i.e., MAC, digital signature, or authenticated encryption. Acceptable methods include, but are not limited to:

• A MAC computed over the concatenation of the cleartext attributes and the enciphered portion of the Key Block, which includes the key itself⎯e.g., ANSI X9.143.

• A digital signature computed over that same data⎯e.g., ASC X9 TR 34.

• An integrity check that is an implicit part of the key-encryption process such as that which is used in the AES key-wrap process specified in ANSI X9.102.

Added p. 87

Equivalent methods can be used where subject to an independent expert review and said review is publicly available as described below. Other methods may additionally be supported where required by legal or regulatory requirements in specific markets, but can no longer be supported in lieu of the aforementioned.

• 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 impractical for the key to be used if the key or its attributes have been modified. Modification includes, but is not limited to:

- Changing or replacing any bit(s) in the attributes or encrypted key

- Interchanging any bits of the protected key block with bits from another part of the block

• Holds one or more professional credentials applicable to the field⎯e.g., doctoral-level qualifications in a relevant discipline or government certification in …

Added p. 89

All key-block methods must, at a minimum, include:

• Use of key-length obfuscation padding for symmetric keys to the maximum length for the algorithm, 192 bits for TDEA and 256 bits for AES.

• One or more attributes that define whether the protected key may be transferred outside the cryptographic domain in which the key is found, i.e., exportability.

This requirement applies wherever asymmetric key-transport techniques are used, including but not limited to:

• Transferring of an initial symmetric key from an HSM into a remote POI device.

• Key transfer to/from a remote-administration terminal to an HSM.

Key recipient devices using PKI must ensure that the sender is trusted by at least one of the following methods: 1) The technique meets the requirements of DTR E2 and DTR E4. 2) Implements a binding mechanism. Following an initial key exchange, the key-receiving device must only accept future requests signed by the same key-distribution host key. 3) …

Added p. 90

• A MAC computed over the concatenation of the cleartext attributes and the enciphered. portion of the Key Block, which includes the key itself, e.g., ANSI X9.143.

• A digital signature computed over that same data, e.g., ASC X9 TR 34.

• An integrity check that is an implicit part of the key-encryption process, such as that which is used in the AES key-wrap process specified in ANSI X9.102.

A device may include more than one compliant key-exchange and storage scheme.

Note: RSA keys with a modulus of 2048 bits may be used to load 128-bit AES keys in conformance with ANSI TR-34. Other public-key techniques, such as Diffie-Hellman or Elliptic Curve, must be used to convey AES keys greater in strength than 128 bits.

TD5.1 The tester shall describe any mechanisms supported by the device for key transport using asymmetric techniques.

TD5.2 The tester shall confirm public and private-key lengths are acceptable for the algorithm …

Added p. 92

• Target device A device, typically an HSM, that is capable of being remotely administered. The target device is assumed to be networked, but otherwise inaccessible to the administrator.

• Remote-administration terminal or remote terminal A device or collection of devices through which the administrator physically interacts with the target device. A remote terminal uses communications networks and cryptography to connect to the target device. A remote-administration platform (RAP) is a type of remote terminal that utilizes a secure cryptographic device for the storage of cryptographic keys and cleartext key management.

Remote-administration requirements are designed to be suitable for both target devices and remote terminals, with the applicability of individual requirements determined by the specific architecture in use. Hardware required for remote administration may be bundled with the target device or procured separately by the user. Complete solutions using approved target devices and/or remote terminals are expected to comply with all requirements.

DTR …

Added p. 93

Secure remote administration requires cryptographically-strong mutual authentication between the remote-administration target device and remote-administration client device. Mutual authentication protocols require both devices to have been provisioned with keys trusted by the peer device. The provisioning of these initial keys must be performed securely.

Hardware-management devices and other removable components used by the remote administrator that are needed to meet security requirements are considered part of the remote-administration terminal.

If the target device is a partition of a physical HSM, secure remote access to the partition manager can be used to provision authorization keys to the target device.

This requirement applies to both the target device and the remote terminal.

The target device must support deprovisioning of individual remote terminals or revocation of the identities used for provisioning. This could be accomplished by deleting the cryptographic key used for authenticating the remote terminal, by using a certificate revocation list, or by using an allowlist.

Cryptography used …

Added p. 94

• Identification of the target device with cryptographic authentication,

• Retrieving the status of the target device, including tamper status, and

• Retrieval of logs useful for reconstructing security incidents.

Any functionality that allows for modification of security-related settings must include strong authentication of the operator.

Cryptography authenticity methods for identity verification allow remote users to confirm they are connecting to a genuine and specific target device. The primary identity mechanism and related cryptographic keys must be managed by the target device vendor and not under the control of the operator. An operator-managed identity mechanism may optionally be deployed in addition to the vendor-managed identity mechanism. Cryptographic keys used for identity verification may be used as part of the remote management cryptography.

Where a device allows for replacement of the factory-installed cryptographic keys used for identity attestation:

• The device shall be in a sensitive state compliant with DTR B6.

• Identifiers protected by the identity attestation …

Added p. 95

Remote-administration functionality that allows for modification of security-related settings is considered a sensitive state and must comply with requirements from B6. This includes, but is not limited to, time limits in the sensitive state and password/authentication code-change requirements.

TE3.1 The tester shall examine the supporting documentation submitted by the device vendor. The documents must describe the remote-access functionality supported by the device. Summarize the remote-access functionality, specifically including any functionality with security impact.

TE3.2 The tester shall confirm all security-relevant remote functionality is described in the security policy.

TE3.4 The tester shall describe the cryptography used for authenticating the identity information and how the system protects against in-the-middle-style attacks. References may be made to TH7.2 if the mechanism used to address this requirement is the same as that used to address DTR H7.

TE3.5 The tester shall exercise the functionality to retrieve the status of the target device and confirm that, at a minimum, …

Added p. 97

• The remote terminal must incorporate a physically secured device that is used to handle all cleartext key material (keys and components).

• The remote terminal must use a device-unique secret key to establish a key-transport key shared with the target device.

• The key-transport mechanism must ensure the integrity, authenticity, and purpose of the key, in addition to any confidentiality controls.

• Keypads used for the manual entry of key components are protected.

“Manual” refers to a human interface where cryptographic material may be exposed•for example, import of a key through key components.

Operational keys are secret and private keys used by the target device for operational activities, such as decrypting payment messages or verifying incoming PIN blocks. Operational key material includes key components and cleartext key values.

A device compliant with the physical security requirements in Module 1 is considered a physically secured device.

Where key material is exported or imported from the device exclusively …

Added p. 98

TE5.5 The tester shall provide details on the key used to protect operational keys transported between the RAP and the target device. Detail how this key is unique per device.

Added p. 99

Devices not restricted to deployment in at least a controlled environment protect sensitive data to an attack potential of at least 35 per HSM processing element for identification and initial exploitation, with a minimum of 15 for initial exploitation, as defined in Appendix A.

Environmental requirements, including the requirements for a controlled environment, are defined in the PCI Key Management and Operations Security and Test Requirements.

TF1.1 The tester shall provide an Asset Flow Diagram of the HSM Solution that 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.

Added p. 101

Strong isolation requires at least two security boundaries to be used between code handling different consumers[tenants] plaintext key material. A security boundary provides a logical separation between the code and data of security domains with different levels of trust. For example, the separation between kernel mode and user mode is a classic and straightforward security boundary. Standard containers, including Docker apps and Windows Server Containers, are separated only by the process-to-process security boundary, which is insufficient isolation to meet this requirement.

Added p. 102

• Verified erase of memory where code confirms the successful overwrite of memory ahead of re- assignment to another tenant.

• Use of dedicated hardware buffers whereby data from one tenant will overwrite data from a previous tenant⎯i.e., both keys and fresh data⎯and where it can be shown that it is not possible to achieve a mismatch between different tenants’ keys and data due to error conditions.

Added p. 105

In the context of this requirement, a provisioning key is a KEK that is used to transport the initial high- level cryptographic keys of an HSM Tenant to an HSM processing element for storage/management.

Added p. 106

A HSM service provider providing multi-tenant HSM services may not share the same master/storage key (''Local Master Key'' or ''Master File Key'') between HSM Tenants. In other words, master/storage keys managed or owned by the HSM service provider must be unique per HSM Tenant, except in cases where a Tenant instance pair/cluster has a designated purpose of load balancing or hot-spare backup.

TF7.1 The tester shall confirm how the HSM Solution stores the cryptographic keys of HSM Tenants, and how this ensures isolation between the cryptographic keys of different HSM Tenants present on the same HSM processing element.

TF7.2 For solutions where the cryptographic keys of HSM Tenants may be stored external to the tamper-responsive boundary of the HSM processing element, the tester shall confirm that the tamper key that is implemented for the storage of keys for each separate HSM Tenant is either internally generated by the HSM processing element itself …

Added p. 107

TF7.4 The tester shall confirm that any keys used to protect cryptographic keys stored external to the tamper-responsive boundary of the HSM processing element, do so in compliant (i.e., ANSI X9.143/ISO 20038), key-wrapped blocks at all times.

Added p. 108

A HSM Cluster is expected to have HSM tenants to migrate away from that service at some point and require that their keys are erased upon their exit from the service. In these cases, it is important that the erasure of the keys of any one HSM tenant does not negatively impact any other HSM tenant.

Where cryptographic erasure of a KEK used to encrypt HSM tenant keys is erased in lieu of the erasure of all tenant keys, the HSM cluster operator is provided with sufficient information to prevent this KEK being used again. Any archived versions of the KEK are to be similarly deleted.

TF8.1 The tester shall confirm the HSM Solution allows for the erasure of the keys belonging to any one HSM tenant, and detail how this is implemented.

TF8.2 The tester shall confirm that the erasure of the keys of any one HSM tenant does not negatively impact …

Added p. 110

• Site inspections are required where documentation is not available or is otherwise inadequate to validate the processes in place to meet the Life Cycle Security Requirements.

Added p. 114

TG2.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 TG2.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, with remarks indicating how each issue has been addressed for the firmware under evaluation. For example:

• Not including unused packages;

• Not being able to log into the operating system without cryptographic authentication in the operational mode of the device;

• Not being able to use debug functions like "netdump" during operational use.

Added p. 115

TG3.3 The tester shall confirm that the authorization of each individual person includes a method that can uniquely identify the individual(s) signing the firmware, and that either passwords or 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.

Added p. 118

• Access-controlled area logs (may be by electronic/signing logs); and

• Inventory logs⎯samples/logs that the vendor maintains (any PLM system) of the parts and devices (includes raw materials) for tracking purposes.

Added p. 122

Standardized cryptographic authentication uses verified, industry-standard algorithms•such as RSA, AES, and ECC―to securely verify user identity through challenge-response mechanisms, to ensure data integrity, confidentiality, and non-repudiation.

All public keys must be signed prior to distribution under dual control, using cryptographic keys protected by a FIPS 140-3 Level 3 or higher cryptographic module or a PCI-approved HSM. It should be managed such that no single person is able to sign certificates. If two secrets (passwords/authentication codes) are required for operation of the signing tool, no single person should know both secrets.

TG10.1 The tester shall examine and cite any supporting documentation submitted by the vendor detailing cryptographic-key control and validation processes and procedures for storage during the manufacturing process.

TG10.2 The tester shall examine and cite any supporting documentation submitted by the vendor detailing dual-control and cryptographic authentication processes and procedures during manufacturing, and describe how they show compliance to this requirement.

TG10.3 The tester …

Added p. 123

The procedures must provide:

• Methods for any HSM Tenants to be informed of the vulnerabilities, and

• The maintenance of an accurate software bill of materials.

The intent of this requirement is to ensure that the vendor has an effective process for detecting vulnerabilities within the firmware.

It is understood that vulnerability survey only represents a snapshot in time, and that vulnerabilities may become known in the public domain after that time. It is therefore expected that the vulnerability analysis incorporates up-to-date assessment mechanisms.

The mechanism the vendor uses to assess each protocol and interface should be effective for that protocol or interface. For example, it is not acceptable to use automated network scanning tools to assess a client protocol for vulnerabilities.

If an OEM module is present and shares resources with the rest of the device, a vulnerability assessment is required to ensure that the OEM module cannot adversely impact the function of the …

Added p. 124

TG11.5 The tester shall examine the vendor’s documentation to verify that a process to create an auditable record of completed vulnerability assessments exists. The record is to include what testing has been done, the results of the assessment, and sign-off from management.

This vulnerability assessment cannot be older than three months since the beginning of the security evaluation.

TG11.6 The tester shall examine the vendor’s documentation to verify that the reports are reviewed internally, and if vulnerabilities are detected, the proper steps are taken.

TG11.7 The tester shall confirm that the vendor has an explicit procedure in place for the acceptance and processing of new vulnerabilities through external communications. This requirement does not mandate the implementation of a "bug bounty" program but does require that all reported vulnerabilities are formally registered and managed according to a documented process.

TG11.8 The tester shall confirm that there is a public-facing procedure for the reporting of vulnerabilities …

Added p. 125

• Site inspections are required where documentation is not available or otherwise inadequate to validate the processes in place to meet the Life Cycle Security Requirements.

The product shall be protected at all points during the shipping process. Tamper-detection security features, instructions for receiving and inspection, and documentation covering suspected tampering must be provided and used.

Added p. 148

Additionally, NIST-approved Post-Quantum Cryptography (PQC) algorithms are approved for use.

TDES IFC (RSA) ECC (ECDSA, ECSDSA, ECDH, ECMQV) EdDSA FFC (DH, MQV) AES NIST Security PQC Security level Minimum key size in number 112 2048 224 255 2048/224 128 Level 1 Key-encipherment keys are to be at least of equal or greater strength than any key they protect, except where explicitly allowed in this standard. This applies to any key-encipherment keys used to protect stored secret or private keys, keys used to encrypt any secret or private keys, or private keys for loading or transport. For purposes of this requirement, the algorithms and key sizes in each row are considered equivalent.

Equivalent Key Sizes TDEA IFC (RSA) ECC (ECDSA, ECDH, ECMQV) EdDSA FFC (DSA, DH, MQV) AES Effective Strength PQC4 168 2048 224 2048/224 112 3072 256 Ed25519 3072/256 128 128 Level 1 7680 384 7680/384 192 192 Level 3 15360 512 …

Added p. 150

Random-Number Generators RNGs are either a deterministic random-number generator (DRNG) or a non-deterministic random- number generator (NRNG).

All DRNGs must be seeded by an NRNG that provides sufficient authenticated entropy. The entropy required should be twice as many bits as the intended key strength, and must not be less than the minimum effective bit strength of the key to be generated. Entropy sources are discussed in NIST SP800- 90B.

Added p. 151

Key Check Values Acceptable KCV Methods Algorithm Key Check Value Method TDES Encryption of a single block of binary zeros, returning at most the leftmost 24 bits (6 hexadecimal digits) of the result. This method has known security impacts, and should be considered for legacy use only. A CMAC calculation across a single block of binary zeros, returning at most the leftmost 64 bits (16 hexadecimal digits) of the result.

A HMAC of a single zero byte (0x00), returning the leftmost 64 bits (16 hexadecimal digits) of the result. The HMAC calculation must use the same underlying hash algorithm for which the key is intended (e.g., the KCV of a HMAC-SHA256 key is to use SHA256 as the underlying hash algorithm). Alternatively, the algorithm specified in ANSI X9.24 A.4 may be used.

Asymmetric The SHA-512 digest of the public or private key (the hash output of the private key is to return …

Added p. 159

It is very likely that a significant part − even the majority − of the test effort will involve processing data (e.g., iteratively collecting, analyzing, filtering, aligning, performing correlation trials) following initial collections to optimize inputs to key attacks.

A good test may discover total, partial, or zero key leakage, practical in a field attack scenario, and/or practical in the white-box context of the evaluation. In situations where a practical attack is known to be capable of exposing the key, the evaluation shall explain definitively the effort needed to extract the key and how compliance is assessed, considering obstacles to key-leakage attacks. In assessing this, the evaluation must consider and justify how any degree of key leakage is acceptable, considering that successful attacks may require a lower degree of effort than the effort discovered through testing.

Added p. 165

A description of this analysis should be in the hardware architecture. It should make clear on the implementation level where the assets are produced, transferred, stored, and destroyed, giving a focused design description.

The lab shall provide a block diagram at the domain level that clearly identifies how the domains interact with one another. The corresponding programming interfaces or, if applicable, hardware interfaces shall be uniquely identified and documented. The diagram shall clearly identify whether software is executed on the same hardware or on a separate CPU, memory, etc.

Removed p. 1

Payment Card Industry (PCI) PIN Transaction Security (PTS) Hardware Security Module (HSM) Modular Derived Test Requirements Version 4.0

Modified p. 2

April 2009 1.0 ~~PCI~~ Initial release

April 2009 1.0 Initial release

Modified p. 2

February 2012 2.x ~~PCI~~ RFC modifications for consistency with PCI POI requirements

February 2012 2.x RFC modifications for consistency with PCI POI requirements

Modified p. 2

May 2012 2.0 ~~PCI~~ Public release

May 2012 2.0 Public release

Modified p. 2

February 2016 3.x ~~PCI~~ RFC version

February 2016 3.x RFC version

Modified p. 6 → 5

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.

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-3, although a solution meeting the requirements of those standards is not necessarily guaranteed to meet all applicable requirements within this document.

Modified p. 6 → 5

4. Protect and enforce the ~~properties⎯such~~ as purpose, algorithm, and ~~length⎯of~~ cryptographic keys.

4. Protect and enforce the properties − such as purpose, algorithm, and length - of cryptographic keys.

Modified p. 6 → 5

The simplest HSM implementation protects a single cryptographic key and requires physical access in secured facilities to protect the loading and operational use of that key. This one key is stored in ~~clear text~~ within the secure boundary of the HSM and is never output from this boundary.

The simplest HSM implementation protects a single cryptographic key and requires physical access in secured facilities to protect the loading and operational use of that key. This one key is stored in cleartext within the secure boundary of the HSM and is never output from this boundary.

Modified p. 6 → 5

In such ~~implementations~~ it is common for some subset⎯and potentially all⎯of the working keys to be protected through encryption under another key. This key may be known as the “storage master,” “local master,” “master file,” or “housekeeping” key⎯or by many other potential names. In this ~~standard~~ we refer to this key as the “tamper key.” However this key is named, its purpose is to allow for the tamper boundary of the HSM to be focused on this key alone, and …

In such implementations, it is common for some subset⎯and potentially all⎯of the working keys to be protected through encryption under another key. This key may be known as the “storage master,” “local master,” “master file,” or “housekeeping” key⎯or by many other potential names. In this standard, we refer to this key as the “tamper key.” However this key is named, its purpose is to allow for the tamper boundary of the HSM to be focused on this key alone, and …

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

Modified p. 7 → 6

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.

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.

Modified p. 7 → 6

An example of an HSM Solution utilizing the external storage of working keys, which may be considered for assessment under these ~~requirements~~ is provided below, with the scope of assessment noted. This is an example only, and many other implementation methods are possible.

An example of an HSM Solution utilizing the external storage of working keys, which may be considered for assessment under these requirements, is provided below, with the scope of assessment noted. This is an example only, and many other implementation methods are possible.

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

Modified p. 8 → 7

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 …

Figure 2: Example of Multi-tenant 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 Tenants in an encrypted form, the same way the working keys are themselves stored encrypted under the HSM Tenant master key. In either implementation, the requirements for protecting the ownership and security of the user keys remain, and it is expected that any HSM tamper key⎯regardless …

Modified p. 10 → 9

• A device overview that summarizes the device’s design, hardware and software architectures, functionalities, and any other security-relevant attributes, features, or ~~functions~~ including (but not restricted to):

• A device overview that summarizes the device’s design, hardware and software architectures, functionalities, and any other security-relevant attributes, features, or functions, including (but not restricted to):

Modified p. 10 → 9

• A list or table of the device’s principal physical ~~components~~ along with a photograph of the ~~components, disassembled, indicating~~ each of the components.

• 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. 10 → 9

• If applicable, a diagram or description the device’s integration into other architectures and/or integrating components.

• If applicable, a diagram or description of the device’s integration into other architectures and/or integrating components.

Modified p. 11 → 9

• Clear definitions of which hardware and firmware features of the overall device solution are within or ~~without~~ the scope of evaluation.

• Clear definitions of which hardware and firmware features of the overall device solution are within or outside the scope of evaluation.

Modified p. 11 → 10

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.

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 interfaces, DPA, etc.) to avoid prohibitively lengthy test activities.

Modified p. 11 → 10

The vendor shall make all 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 in making a systematic review of relevant security functions.

Modified p. 11 → 10

• At the beginning of the report, a list of all documentation, including DTR sections and Technical FAQs ~~version~~ used during the ~~evaluation~~

• At the beginning of the report, a list of all documentation, including DTR sections and Technical FAQs versions used during the evaluation;

Modified p. 11 → 10

• Throughout the report, inline references to specific documents when addressing other sub- ~~requirements~~

• Throughout the report, inline references to specific documents when addressing other sub- requirements;

Modified p. 11 → 10

• For each DTR, the DTR definition and guidance (if any), followed by the sequence of all DTR work items (e.g., TA1.1, TA1.2, TA1.3, etc.), directly preceding the report’s explanations on each item. Cited DTR text shall match the current ~~DTRs~~ version and shall be clearly distinguishable from Laboratory-generated report text. “N/A” verdicts shall be clearly identifiable as such.

• For each DTR, the DTR definition and guidance (if any), followed by the sequence of all DTR work items (e.g., TA1.1, TA1.2, TA1.3, etc.), directly preceding the report’s explanations on each item. Cited DTR text shall match the current DTR’s version and shall be clearly distinguishable from Laboratory-generated report text. “N/A” verdicts shall be clearly identifiable as such.

Modified p. 11 → 10

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

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 their own judgment in determining the appropriate tests and shall document why the test evidence and methods used are valid against the PTS Program• i.e., considering DTRs, FAQs, Program Guide, …

Modified p. 12 → 11

In most ~~cases~~ the DTR text is insufficient without combining photographs and/or other graphic illustrations that explain the evaluation. Images shall be of sufficient quality for relevant details to be viewed•for example, clear identification of a hardware component, relevant information clearly discernible in a graph, images capturing displays and other outputs, source-code fragments, etc.

In most cases, the DTR text is insufficient without combining photographs and/or other graphic illustrations that explain the evaluation. Images shall be of sufficient quality for relevant details to be viewed•for example, clear identification of a hardware component, relevant information clearly discernible in a graph, images capturing displays and other outputs, source-code fragments, etc.

Modified p. 12 → 11

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.

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. 12 → 11

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.

Re-use of test results for PTS HSM v5.0 evaluations is only allowed where the evidence is no older than five years. Other v5.0 evaluation work may supplement work done in the current review.

Modified p. 12 → 11

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 each flow diagram is interconnected and/or interrelated.

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 comprised of several flow diagrams, so long as it is clear how each flow diagram is interconnected and/or interrelated.

Modified p. 12 → 11

Within the Asset Flow ~~Analysis,~~ appropriate domains are assigned for each logical and physical component in the ~~device~~ including software modules, hardware components, and PCB tracks (which may be grouped if several tracks combine a bus). The tester then uses this Asset Flow ~~Analysis~~ to scope the device and apply the appropriate DTRs for the specific domain.

Within the Asset Flow Diagram, appropriate domains are assigned for each logical and physical component in the device, including software modules, hardware components, and PCB tracks (which may be grouped if several tracks combine a bus). The tester then uses this Asset Flow Diagram to scope the device and apply the appropriate DTRs for the specific domain.

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

Removed p. 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/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.

The device is protected against penetration by including features that detect: (i) any feasible attempts to tamper with the device; and (ii) cause immediate erasure of all cryptographic keys and sensitive data when such an attempt is detected.

Modified p. 14 → 12

“Immediately inoperable” is defined as immediately ceasing all processing activities involving secure key materials and critical security parameters. Diagnostic ~~functionality~~ such as status information and audit ~~trails~~ may continue to be available following the stoppage of processing activities. The user may have access to utilities to recover the device to an operative state. Additionally, the tamper-detection and response mechanisms must result in the automatic and immediate erasure of any sensitive data that may be stored in the device, such that …

“Immediately inoperable” is defined as immediately ceasing all processing activities involving secure key materials and critical security parameters. Diagnostic functionality, such as status information and audit trails, may continue to be available following the stoppage of processing activities. The user may have access to utilities to recover the device to an operative state. Additionally, the tamper-detection and response mechanisms must result in the automatic and immediate erasure of any sensitive data that may be stored in the device, such that …

Removed p. 15

Secret or private cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication, do not need to be considered secret data and therefore do not need to be erased•for example, where the device uses a chip set that automatically generates keys at initialization but the keys are not subsequently used by the device.

• Vias of ”upper grid” must be protected separately to vias of “lower grid”

•for example, the two tamper grids must not be connected by vias that are accessible on both grid layers, or vias must be protected by other tamper mechanisms, such as switches.

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.

Modified p. 15 → 13

If tamper grids are used as a primary mechanism, ~~they meet~~ the ~~following:~~

If tamper grids are used as a primary tamper-detection and response mechanism, the following best practice methods should be considered:

Removed p. 16

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 remove the cover.

b) The version of the PCB;

c) The main purpose of the PCB;

Modified p. 16 → 14

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

TA1.8 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. 16 → 14

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

TA1.9 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. 16 → 14

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

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. 16 → 14

~~TA1.12~~ The tester shall enumerate each of the circuit boards indicated in the device in the table below, providing, at a minimum:

TA1.11 The tester shall enumerate each of the circuit boards indicated in the device in the table below, providing, at a minimum:

Modified p. 16 → 14

d) Pictures of the front and back of each PCB and references thereto;

c) Pictures of the front and back of each PCB and references thereto;

Modified p. 16 → 14

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,

d) Note as to whether the PCB contains any sensitive signals (such as cleartext PINs or keying material•but not tamper signals); and, finally,

Modified p. 16 → 14

f) Outline of the tamper-detection mechanisms used on that board•such as “4 tamper switches on lower face,” “6 tamper switches on upper face,” “two internal tamper grids,” etc.

e) Outline of the tamper-detection mechanisms used on that board•such as “4 tamper switches on lower face,” “6 tamper switches on upper face,” “two internal tamper grids,” etc.

Removed p. 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. 17 → 14

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

TA1.13 If the HSM has one or more keypads, all keypads must be considered and identified. This includes a description of the sensitive data each keypad is used to input. The tester shall describe whether any of the items on the path of the keypad signals are not protected by all tamper-detection mechanisms. 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 …

Modified p. 17 → 15

c) The size of the conductive traces and the distance between each tamper-detecting trace (not necessarily between each ~~trace)~~ as well as the distance between layers for tamper grids that provide protection against penetration through the side of the PCB;

c) The size of the conductive traces and the distance between each tamper-detecting trace (not necessarily between each trace), as well as the distance between layers for tamper grids that provide protection against penetration through the side of the PCB;

Modified p. 17 → 15

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.

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.

Modified p. 17 → 15

~~TA1.17~~ For each tamper switch used in the device, the tester shall complete the details indicated in the table below, at a minimum.

TA1.16 For each tamper switch used in the device, the tester shall complete the details indicated in the table below, at a minimum.

Modified p. 17 → 15

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.

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

TA1.21 The tester shall describe what testing was performed to validate any volume encapsulation.

Modified p. 18 → 15

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

TA1.18 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. 18 → 15

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

TA1.19 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. 18 → 16

Testing must include chemical ~~and/or abrasive,~~ and heating methods to bypass this protection.

Testing must include chemical (and/or abrasive) and heating methods to bypass this protection.

Modified p. 18 → 16

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

TA1.21 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. 18 → 16

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

TA1.22 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. 18 → 16

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

TA1.23 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. 18 → 16

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

Modified p. 18 → 16

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

TA1.25 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. 18 → 16

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

TA1.26 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. 18 → 16

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

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

Modified p. 18 → 16

~~TA1.29~~ From the above ~~descriptions~~ the tester shall explain how the device is rendered inoperative after any tamper event.

TA1.28 From the above descriptions, the tester shall explain how the device is rendered inoperative after any tamper event.

Modified p. 19 → 16

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.

If the device is restricted to deployment in an environment meeting at least the security requirements 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 between the 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. 19 → 16

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

Modified p. 20 → 17

The objective is not to replicate the vendor testing, but ~~instead~~ it is to account for shortcomings within the vendor’s testing of the implementation.

The objective is not to replicate the vendor testing, but it is instead to account for shortcomings within the vendor’s testing of the implementation.

Modified p. 20 → 17

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

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. 20 → 17

TA2.3 The tester shall use the table below to detail the environmental protection features implemented by the device. For voltage, the tester shall outline which voltage is being monitored•for example, external, main processor core voltage, battery voltage, etc. If more than one voltage monitoring is provided, the tester shall detail all of these. For each environmental factor monitored, the tester shall detail what circuitry is performing this monitoring and what occurs ~~when~~ during an out-of-range detection.

TA2.3 The tester shall use the table below to detail the environmental protection features implemented by the device. For voltage, the tester shall outline which voltage is being monitored•for example, external, main processor core voltage, battery voltage, etc. If more than one voltage monitoring is provided, the tester shall detail all of these. For each environmental factor monitored, the tester shall detail what circuitry is performing this monitoring and what occurs during an out-of-range detection.

Modified p. 20 → 17

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.

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, or detail how they validated the equivalent vendor testing, to verify 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. 21 → 18

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.

TA2.8 The tester shall develop attack scenarios to compromise the device by altering operational conditions, and should consider whether altering environmental conditions may be used to develop attacks.

Modified p. 21 → 18

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.

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 to demonstrate compliance to this DTR.

Removed p. 22

The protected area of the device is that area(s) within the boundaries of the tamper-detection and response mechanisms.

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. 22 → 19

The lab shall consider glitch ~~attacks~~ including (but not restricted to): voltage and EM glitching. At a minimum, these should consider the core and battery input for the security processor.

The lab shall consider glitch attacks, including (but not restricted to): voltage and EM glitching. At a minimum, these should consider the core and battery input for the security processor.

Modified p. 22 → 19

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. 22 → 19

It is expected that each type of information may have multiple “storage areas” and “methods of protection” (for example, ~~clear-text~~ PINs may appear in internal memory of the security processor, as well as on the external heap cache and within the processor registers, and the external memory may be protected by encryption with the external bus key as well as with physical protections of the secure area of the device).

It is expected that each type of information may have multiple “storage areas” and “methods of protection” (for example, cleartext PINs may appear in internal memory of the security processor, as well as on the external heap cache and within the processor registers, and the external memory may be protected by encryption with the external bus key as well as with physical protections of the secure area of the device).

Modified p. 23 → 20

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.

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. 23 → 20

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.

TA3.7 If the device allows for the execution of applications and firmware on the same processor that stores or operates on cleartext 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. 23 → 20

TA3.9 Where physical protections are used as a method of protection (for example, when ~~clear-text~~ information is stored in external memory), the tester shall:

TA3.9 Where physical protections are used as a method of protection (for example, when cleartext information is stored in external memory), the tester shall:

Modified p. 23 → 21

c) Justify how this prevents the ~~re-location~~ of memory from one area to another.

c) Justify how this prevents the relocation of memory from one area to another.

Modified p. 23 → 21

d) Justify how the method of encryption prevents the exposure of sensitive information through building of a “dictionary” of possible encrypted values.

d) Justify how the method of encryption prevents the exposure of sensitive information through the building of a “dictionary” of possible encrypted values.

Modified p. 24 → 21

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

TA3.14 The tester shall describe and produce a costing for the most practical 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. 24 → 21

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

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. 24 → 21

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.

If the device is restricted to deployment in an environment meeting at least the security requirements 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 between the 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. 25 → 22

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

“Keys resident in the device or its components” means cleartext 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 → 22

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.

All physical and logical protections shall be evaluated and reported. Only protections that can be demonstrated as both enabled and effective shall be used to determine attack potential.

Modified p. 25 → 22

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 …

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 → 22

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.

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 that the storage locations listed are correct. The tester shall reference the relevant aspects of the asset flow.

Modified p. 25 → 23

d) Describe why any secure boot-up operations are implemented appropriately to obstruct glitch attacks, referring to any available literature and vulnerability disclosures to support ~~this~~ or otherwise perform practical penetration tests to demonstrate this.

d) Describe why any secure boot-up operations are implemented appropriately to obstruct glitch attacks, referring to any available literature and vulnerability disclosures to support this, or otherwise perform practical penetration tests to demonstrate this.

Modified p. 26 → 23

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

TA4.7 If the device stores cleartext 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 plaintext cryptographic keys unless restricted to deployment in a controlled environment.

Modified p. 26 → 23

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:

TA4.8 The tester shall describe and cost the most practical 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. 26 → 23

• The steps needed in any penetration.

• The steps needed for any penetration.

Modified p. 26 → 23

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

• Attacks involving some or all of the attacks modeled elsewhere. For example, DTRs A1 and A3 (but not restricted thereto) must be considered and included in this attack, if relevant.

Modified p. 26 → 23

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 …

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. 26 → 23

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.

If the device is restricted to deployment in an environment meeting at least the security requirements 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 between the 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 → 24

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

“Keys resident in the device or its components” means cleartext 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. 27 → 24

Notwithstanding physical protections, which may be validated by other DTRs, approved devices must not contain cryptographic implementations ~~which,~~ under analysis, can be straightforwardly compromised through SCA.

Notwithstanding physical protections, which may be validated by other DTRs, approved devices must not contain cryptographic implementations that, under analysis, can be straightforwardly compromised through SCA.

Modified p. 27 → 24

To pass this requirement, it must be demonstrated that any static-value keys resist SCA attacks by expert-level skill using state-of-the-art ~~tools~~ analyzing at least 100,000 demonstrably high-quality recordings, ~~in-line~~ with the details of this DTR.

To pass this requirement, it must be demonstrated that any static-value keys resist SCA attacks by expert-level skill using state-of-the-art tools, analyzing at least 100,000 demonstrably high-quality recordings, in line with the details of this DTR.

Modified p. 27 → 24

For security-related keys, the evaluation should determine at least one algorithm to analyze thoroughly, applying the SCA approach most likely to succeed, based on a rigorous assessment of asset value versus ~~feasible~~ attacks. Reasoning for not testing any algorithm must 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.

For security-related keys, the evaluation should determine at least one algorithm to analyze thoroughly, applying the SCA approach most likely to succeed, based on a rigorous assessment of asset value versus practical attacks. Reasoning for not testing any algorithm must 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. 27 → 24

For HSMs restricted to deployment in an environment meeting at least the security of a controlled environment as defined in ~~ISO 13491-2,~~ the evaluation shall perform ~~SEMA~~ and ~~SPA~~ (see Appendix E) at a sufficient depth of investigation to show that cryptographic algorithms processing account- data-protection keys have active and effective SCA countermeasures.

For HSMs restricted to deployment in an environment meeting at least the security requirements of a controlled environment as defined in the PCI Key Management and Operations Security and Test Requirements, the evaluation shall perform SEMA, SPA, and timing attacks (see Appendix E) at a sufficient depth of investigation to show that cryptographic algorithms processing PIN and account- data-protection keys have active and effective SCA countermeasures.

Modified p. 28 → 25

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.

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

Modified p. 28 → 25

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

• A list of all security-related cryptographic keys (secret and private) that may be directly or indirectly (e.g., requiring a precursor step such as breaking a higher-level key) 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.

Modified p. 28 → 25

• Any specific key-management techniques that either prevent or obstruct side-channel analysis, such as ~~unique keys per operation~~ or other constraints on exercising static key values or any other algorithmic constraints on SCA attacks.

• Any specific key-management techniques that either prevent or obstruct side-channel analysis, such as unique-keys-per-operation or other constraints on exercising static key values or any other algorithmic constraints on SCA attacks.

Modified p. 28 → 25

TA5.2 The tester shall check the evidence provided by the vendor on the implemented cryptographic operations and detail all of the different cryptographic operations implemented within the device. The tester shall verify whether they are implemented in software or hardware, and what side- channel analysis protections are implemented to protect each of these operations. The tester shall describe methods used for each side-channel protection

•for example, time variance, masking, dual-rail logic, etc. If it is not possible to determine this information …

Modified p. 28 → 25

TA5.3 Verify the items above, generally using source-code review, to ensure that the side-channel protection methods are implemented. For example, if the device relies on protections provided by the ~~processor~~ hardware cryptographic engine, the tester shall confirm that the registers that enable this protection are correctly set by the device firmware before every use of this cryptographic engine. If the protections are provided by the firmware, the tester shall check that the implementation is as described by the vendor. This …

TA5.3 Verify the items above, generally using source-code review, to ensure that the side-channel protection methods are implemented. For example, if the device relies on protections provided by the processor’s hardware cryptographic engine, the tester shall confirm that the registers that enable this protection are correctly set by the device firmware before every use of this cryptographic engine. If the protections are provided by the firmware, the tester shall check that the implementation is as described by the vendor. This …

Modified p. 29 → 26

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.

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.

Modified p. 29 → 26

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.

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 of any PCI security-related secret or private cryptographic key resident in the device, through side-channel analysis, is not practical on this device.

Modified p. 29 → 26

• Whether the attack can be ~~feasible~~ at any distance away from the processor,

• Whether the attack can be practical at any distance away from the processor,

Modified p. 29 → 26

• Signal ~~analysis / filtering~~ techniques,

• Signal analysis/filtering techniques,

Modified p. 29 → 26

• How adequate ~~key selection function~~ coverage was applied.

• How adequate key-selection-function coverage was applied.

Modified p. 29 → 26

Evidence to support this shall include (but is not restricted to) annotated graphical profiling of side-channel ~~results~~ such as:

Evidence to support this shall include (but is not restricted to) annotated graphical profiling of side-channel results, such as:

Modified p. 30 → 27

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 …

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., v4.x or other v5.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 …

Modified p. 30 → 27

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.

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.

Modified p. 31 → 28

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.

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 the 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. 31 → 28

The HSM must detect hardware ~~errors~~ in order to prevent the return of incorrect results or the disclosure of sensitive information. Examples of methods to detect hardware errors include:

The HSM must detect hardware errors, in order to prevent the return of incorrect results or the disclosure of sensitive information. Examples of methods to detect hardware errors include:

Modified p. 31 → 28

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

• Execution of periodic self-tests with a frequency of at least once every 24 hours, in addition to pre-operational execution and after a hardware reset.

Modified p. 31 → 28

Failure in accordance with FIPS ~~140-2/140-3~~ can be either a degraded mode of operation where the module allows functionality not related to the self-test ~~failure~~ or the module halting and blocking output from all external interfaces.

Failure in accordance with FIPS 140-3 can be either a degraded mode of operation where the module allows functionality that is not related to the self-test failure, or the module halting and blocking output from all external interfaces.

Modified p. 31 → 28

In all cases, initial testing of firmware when it is loaded from mass storage to memory is still required to detect tampering ~~when~~ on the storage device.

In all cases, initial testing of firmware when it is loaded from mass storage to memory is still required to detect tampering on the storage device.

Modified p. 31 → 28

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.

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, 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. 31 → 28

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.

Internal generation of a cryptographic signature is valid immediately 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.

Modified p. 32 → 29

A device does not require authenticity checking when self-testing ~~its firmware~~ if (all apply):

A device does not require authenticity checking of firmware when self-testing if (all must apply):

Modified p. 32 → 29

• 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

• 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 initially established in that secure area; and

Modified p. 32 → 29

• A periodic integrity check according to Requirement B1 is performed for the firmware, ensuring that random changes will be ~~detected; and if cryptographic authenticity is not performed, the integrity check must be cryptographically based.~~ Although an algorithm using a secret key, such as a keyed hash, can be used, it is not necessary ~~for meeting~~ the integrity criteria.

• A periodic integrity check according to Requirement B1 is performed for the firmware, ensuring that random changes will be detected. Although an algorithm using a secret key, such as a keyed hash, can be used, it is not necessary to meet the integrity criteria. However, if cryptographic authenticity is not performed internally according B3 (see bullet 1), the integrity check must be cryptographically based.

Modified p. 32 → 29

~~All~~ self-tests shall be performed and determination of pass or fail shall be made by the module without external controls, ~~externally provided~~ input test vectors, expected output results, or operator ~~intervention or whether the module will operate in an approved or non-approved mode.~~

Regardless of whether the module is operating in an approved or non-approved mode, all self-tests shall be performed and determination of pass or fail shall be made by the module without external controls, externally-provided input test vectors, expected output results, operator intervention.

Modified p. 32 → 29

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.

Periodic self-tests shall be performed automatically and repeatedly within a defined time period, without external input or control. The device must ensure 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. 32 → 29

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 shall be specified in the security policy⎯e.g., if the module is performing mission-critical services that can’t 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 self-test must be performed on boot prior to any operational …

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 shall be specified in the security policy⎯e.g., if the module is performing mission-critical services that can’t 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 self-test must be performed on boot prior to any operational …

Modified p. 32 → 29

Pre-operational self-tests shall be performed and passed successfully by a cryptographic module between the time the module is powered on or instantiated (after being powered off, reset, rebooted, ~~cold-start,~~ power ~~interruption,~~ etc.) and before the module transitions to the operational state. A cryptographic module shall perform the following, as applicable:

Pre-operational self-tests shall be performed and passed successfully by a cryptographic module between the time the module is powered on or instantiated (after being powered off, reset, rebooted, cold-started, power interrupted, etc.) and before the module transitions to the operational state. A cryptographic module shall perform the following, as applicable:

Modified p. 32 → 29

• Pre-operational software/firmware integrity ~~test~~

• Pre-operational software/firmware integrity test,

Modified p. 32 → 29

• Pre-operational bypass ~~test~~

• Pre-operational bypass test, and

Modified p. 33 → 30

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

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

Modified p. 33 → 30

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.

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. 33 → 30

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.

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. 33 → 30

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.

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, and that cryptography used for this purpose provides an effective key strength of 128 bits or stronger. The tester shall confirm that any register settings required to activate hardware-based self-test functions are correctly assigned.

Modified p. 33 → 30

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.

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.

Removed p. 34

If a hardware module does not contain either software or firmware⎯for example where it is an IP block within an SOC or a dedicated ASIC cryptographic chip⎯the module shall at a minimum implement one cryptographic algorithm self-test as specified in TB1.15 as a pre-operational self-test.

Modified p. 34 → 31

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 …

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

Modified p. 34 → 31

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 …

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 …

Removed p. 35

A known-answer test consists of a set of known input vectors (e.g., data, keying material, or constants in lieu of random bits) which are operated on by the cryptographic algorithm to generate a result. The result is compared to the known expected output result. If the calculated output does not equal the known answer, the cryptographic algorithm known- answer self-test shall fail.

Modified p. 35 → 32

c) Bypass test If a cryptographic module implements a bypass capability, the module shall ensure the correct operation of the logic governing activation of the bypass capability by exercising that logic. The module shall also verify the data path by:

c) Bypass test If a cryptographic module implements a bypass capability, the module shall ensure the correct operation of the logic governing the activation of the bypass capability by exercising that logic. The module shall also verify the data path by:

Modified p. 35 → 32

− Setting the bypass switch to provide cryptographic ~~processing~~ and ~~verify~~ that data transferred through the bypass mechanism is cryptographically processed, and − Setting the bypass switch to not provide cryptographic ~~processing~~ and ~~verify~~ that data transferred through the bypass mechanism is not cryptographically processed.

− Setting the bypass switch to provide cryptographic processing, and verifying that data transferred through the bypass mechanism is cryptographically processed, and − Setting the bypass switch to not provide cryptographic processing, and verifying that data transferred through the bypass mechanism is not cryptographically processed.

Modified p. 35 → 32

d) ~~Random number generator~~ test

d) Random-number-generator test

Modified p. 35 → 32

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

TB1.14 If applicable, the tester shall induce the periodic self-tests and, if applicable, view any status.

Modified p. 35 → 32

TB1.15 The tester shall verify that the device performs the following conditional ~~self-tests~~ where applicable, when the conditions specified ~~exists:~~

TB1.15 The tester shall verify that the device performs the following conditional self-tests, where applicable, when the conditions specified exist:

Modified p. 35 → 33

An algorithm self-test shall ~~use~~ at ~~minimum~~ the smallest approved key length, modulus size, DSA prime, or curves (as appropriate) supported by the ~~module.~~

An algorithm self-test shall use, at minimum, the smallest approved key length, modulus size, DSA prime, or curves (as appropriate) supported by the current module configuration.

Modified p. 36 → 33

- One-way functions: ~~Input~~ test vector(s) generate ~~output~~ which shall be identical to expected output⎯e.g., hashing, keyed hashes, message authentication, RBG (fixed entropy vector), SSP agreement.

- One-way functions: Inputted test vector(s) generate output, which shall be identical to expected output⎯e.g., hashing, keyed hashes, message authentication, RBG (fixed entropy vector), SSP agreement.

Modified p. 36 → 33

- Reversible functions: Both the forward and reverse ~~function~~ shall be self-tested (e.g., symmetric key encryption and decryption, SSP transport encryption and decryption, digital signature generation and verification) A comparison test compares the output of two or more independent cryptographic algorithm implementations; if the outputs are not equal, the cryptographic algorithm comparison self-test shall fail.

- Reversible functions: Both the forward and reverse functions shall be self-tested (e.g., symmetric key encryption and decryption, SSP transport encryption and decryption, digital signature generation and verification).

Modified p. 36 → 33

A fault-detection test involves the implementation of ~~fault detection~~ mechanisms integrated within the cryptographic algorithm ~~implementation; if~~ a fault is detected, the cryptographic algorithm fault-detection self-test shall fail.

A fault-detection test involves the implementation of fault-detection mechanisms integrated within the cryptographic algorithm implementation. If a fault is detected, the cryptographic algorithm fault-detection self-test shall fail.

Modified p. 36 → 33

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

• If the keys are used to perform key transport, the public key shall encrypt a cleartext value. The resulting ciphertext value shall be compared to the original cleartext 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 cleartext value. If the two values are not equal, the test shall fail.

Modified p. 36 → 33

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

• 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. 36 → 33

c) Manual entry test If SSPs 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:

c) Manual entry test If SSPs or key components are manually entered into a cryptographic module, or if an 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:

Modified p. 37 → 34

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

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

Modified p. 37 → 34

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.

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. 37 → 34

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

f) Bypass test If a cryptographic module implements a bypass capability where the services may be provided without cryptographic processing (e.g., transferring cleartext 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 cleartext:

Modified p. 38 → 35

TB1.17 For both pre-operational and continuous/periodic ~~tests~~ the tester shall:

TB1.17 For both pre-operational and continuous/periodic tests, the tester shall:

Modified p. 38 → 35

a) Verify the vendor documentation provides, for each error ~~state~~

a) Verify the vendor documentation provides, for each error state:

Modified p. 38 → 35

b) Cause each error state to occur and attempt to clear the error state. The tester shall verify that actions necessary to clear the error state are consistent with the vendor documentation. If the tester cannot cause each error state to occur, the tester shall verify the code listing and/or design ~~documentation~~ and whether the actions necessary to clear each error state are consistent with the descriptions in the vendor documentation.

b) Cause each error state to occur and attempt to clear the error state. The tester shall verify that actions necessary to clear the error state are consistent with the vendor documentation. If the tester cannot cause each error state to occur, the tester shall verify the code listing and/or design documentation, and whether the actions necessary to clear each error state are consistent with the descriptions in the vendor documentation.

Modified p. 38 → 35

e) Verify that upon entering an error ~~state~~ the cryptographic module does not perform any cryptographic ~~operations~~ or output control and ~~data~~ via the control and ~~data output~~ interface while in an error state.

e) Verify that upon entering an error state, the cryptographic module does not perform any cryptographic operations, or output control and data, via the control and data-output interface while in an error state.

Modified p. 39 → 37

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. 39 → 37

• Penetration testing to validate the robustness of the device to protect against ~~feasible~~ attacks by addressing known attack methods. For example (but not restricted to), fuzzing, using appropriate tools and techniques.

• Penetration testing to validate the robustness of the device to protect against practical attacks by addressing known attack methods. For example (but not restricted to), fuzzing, using appropriate tools and techniques.

Modified p. 39 → 37

• Audits of relevant existing test evidence, which may be utilized where appropriate by giving justifications for validity of evidence and test methodologies overall.

• Audits of relevant existing test evidence, which may be utilized where appropriate by giving justifications for the validity of evidence and test methodologies overall.

Modified p. 40 → 38

The source-code review should be targeted on relevant security-critical functionalities such as (but not restricted to): buffer ~~overflows;~~ unhandled exceptions, read-access violations, and denial-of-service ~~conditions, including~~ factors that are specific to the device’s OS, communications protocols, and source code software language(s).

The source-code review should be targeted on relevant security-critical functionalities such as (but not restricted to): buffer overflows, unhandled exceptions, read-access violations, and denial-of-service conditions•including factors that are specific to the device’s OS, communications protocols, and source code software language(s).

Modified p. 40 → 38

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.

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 on the device, together with the application’s source code. The tester shall run the application and determine whether the device fails securely.

Modified p. 40 → 38

The tester shall compare ~~his/her~~ analysis with the analysis provided by the ~~vendor~~ and confirm that the vendor has remediated any problems with these vulnerabilities, and that firmware-audit report documents exist and have been updated to validate this assertion.

The tester shall compare their analysis with the analysis provided by the vendor, and confirm that the vendor has remediated any problems with these vulnerabilities, and that firmware-audit report documents exist and have been updated to validate this assertion.

Modified p. 40 → 38

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.

TB2.10 The tester shall execute a vulnerability assessment, public vulnerability check, and/or testing to identify vulnerabilities associated with the interfaces, as well as associated communication methods of the device.

Modified p. 40 → 39

The tester shall describe fuzzing methodologies and tools used, as well as any assistance provided by the vendor in the case of white-box ~~fuzzing~~ and results obtained. The description and results should be sufficient to provide a demonstrably high level of confidence in the security of the device’s interfaces.

The tester shall describe fuzzing methodologies and tools used, as well as any assistance provided by the vendor in the case of white-box fuzzing, and results obtained. The description and results should be sufficient to provide a demonstrably high level of confidence in the security of the device’s interfaces.

Modified p. 41 → 39

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.

TB2.12 The tester shall identify all command interpreters within the firmware, including all command interpreters within the HSM software that 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. 42 → 40

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 update mechanism ensures., integrity, mutual authentication, and protection against replay⎯by using an appropriate and declared security protocol when using a network connection.

Modified p. 42 → 40

TB3.4 The tester shall determine the level of protection for the external component involved in firmware/software ~~updates~~ and that the authentication of firmware updates is performed by a component of equal or greater strength.

TB3.4 The tester shall determine the level of protection for the external component involved in firmware/software updates, and that the authentication of firmware updates is performed by a component of equal or greater strength.

Removed p. 43

Examples of acceptable hashing algorithms include SHA-256, SHA-384 and SHA-512. MD5 and SHA-1 are not allowed for use.

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. 43 → 41

Elements Used to Perform Authentication Algorithms and Key Sizes Used for Firmware Authentication Format of Authentication Process Performed if Authentication If the method used for initial loading of the firmware differs from the method used for code update, provide additional details (including another of the tables above, if deemed necessary) of how initial code is loaded into the device.

Elements Used to Perform Authentication Algorithms and Key Sizes Used for Firmware Authentication Format of Authentication Process Performed if Authentication If the method used for initial loading of the firmware differs from the method used for code update, provide additional details (including another of the tables above, if deemed necessary) on how initial code is loaded into the device.

Modified p. 43 → 41

In the “Format of Authentication Block Column,” include details on the format and padding of the authentication block (for ~~example~~ X.509 certificate using OAEP padding).

In the “Format of Authentication Block Column,” include details on the format and padding of the authentication block (for example, X.509 certificate using OAEP padding).

Modified p. 43 → 41

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.

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 the use of evaluation resources against evaluation goals overall.

Modified p. 43 → 41

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.

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 from 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. 43 → 41

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.

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 the use of evaluation resources against evaluation goals overall.

Modified p. 44 → 42

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.

TB3.12 The tester shall confirm how any public or private/secret keys used for the purpose of this DTR 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.

Modified p. 45 → 43

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.

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.

Modified p. 45 → 43

TB3.1.4 For each of the processing elements listed in DTR A3, the tester shall complete the following table. Where different applications or application components⎯e.g., executable code, scripts, ~~etc⎯can~~ be updated independently, or if one part of the application cannot be updated, the tester shall ensure that this is detailed in the table as well.

TB3.1.4 For each of the processing elements listed in DTR A3, the tester shall complete the following table. Where different applications or application components⎯e.g., executable code, scripts, etc.⎯can be updated independently, or if one part of the application cannot be updated, the tester shall ensure that this is detailed in the table as well.

Removed p. 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. 46 → 44

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.

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 the use of evaluation resources against evaluation goals overall.

Modified p. 46 → 44

~~TB3.1.9~~ For each of the methods of ~~authentication~~ the tester shall obtain a correctly authenticated application image and:

TB3.1.8 For each of the methods of authentication, the tester shall obtain a correctly authenticated application image and:

Modified p. 46 → 44

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

TB3.1.9 The tester shall confirm how any public or private/secret keys used for the purpose of this DTR 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.

Modified p. 47 → 45

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

• All data (except control data entered via the control input interface) that is input to and processed by a cryptographic module (including cleartext data, ciphertext data, cryptographic keys and CSPs, authentication data, and status information from another module) shall enter via the "data input" interface.

Modified p. 47 → 45

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

• All data (except status data output via the status output interface) that is output from a cryptographic module (including cleartext 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. 47 → 45

TB4.1 The tester shall examine any relevant documentation distributed by the ~~vendor~~ such as schematics, data sheets, asset flow diagrams, and assembly drawings submitted by the vendor to ensure that the vendor has exhaustively defined all protocols and interfaces supported by the device. The vendor must also identify the source of its code used to implement protocols, as well as document all protocols and the physical interfaces to which they apply. When public libraries are used to implement protocols, their …

TB4.1 The tester shall examine any relevant documentation distributed by the vendor, such as schematics, data sheets, asset flow diagrams, and assembly drawings submitted by the vendor to ensure that the vendor has exhaustively defined all protocols and interfaces supported by the device. The vendor must also identify the source of its code used to implement protocols, as well as document all protocols and the physical interfaces to which they apply. When public libraries are used to implement protocols, their …

Removed p. 48

• The transaction is completed, or

Modified p. 48 → 46

• The device has timed ~~out or~~

• The device has timed out,

Modified p. 48 → 46

• The device recovers from an error ~~state.~~

• The device recovers from an error state,

Modified p. 48 → 46

This applies to sensitive data, such as passwords/authentication codes, ~~clear-text~~ cryptographic keys outside of the crypto-processor, and ~~clear-text~~ PIN values.

This applies to sensitive data, such as passwords/authentication codes, cleartext cryptographic keys outside of the crypto-processor, sensitive intermediate data used during key generation, and cleartext PIN values.

Modified p. 48 → 46

TB5.1 The tester will verify that and summarize how the vendor has identified all data that is automatically cleared once the information is no longer needed, including when the ~~transaction is completed, the~~ device has timed out, or the device recovers from an error state, and that all sensitive data is included. Passwords, ~~clear-text~~ cryptographic keys, key components outside of the crypto-processor, and PIN values are considered sensitive data.

TB5.1 The tester will verify that and summarize how the vendor has identified all data that is automatically cleared once the information is no longer needed, including when the device has timed out, or the device recovers from an error state, and that all sensitive data is included. Passwords, cleartext cryptographic keys, key components outside of the crypto-processor, and PIN values are considered sensitive data.

Modified p. 48 → 46

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:

TB5.4 The tester shall detail the testing performed to verify that the buffer-clearing code/function is robust. This requires assistance from the vendor and may involve, for example:

Modified p. 48 → 46

TB5.5 The tester shall confirm that

•and indicate how

•via review, the vendor has the requirement for buffer clearing documented in their software-development practices documentation, including specific notes on how this should be done to prevent removal by compiler optimization, and that the correct implementation of this guide is reviewed as part of the firmware-verification process validated as part of DTR ~~B3.~~

TB5.5 The tester shall confirm that

•and indicate how

•via review, the vendor has the requirement for buffer clearing documented in their software-development practices documentation, including specific notes on how this should be done to prevent removal by compiler optimization, and that the correct implementation of this guide is reviewed as part of the firmware-verification process validated as part of DTR G2.

Modified p. 48 → 46

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.

TB5.6 The tester shall perform any additional tests necessary to verify that all data is automatically cleared, including when 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. 49 → 47

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 …

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 cleartext or split knowledge of manual CSP loading or CSP output, …

Modified p. 49 → 47

A sensitive service (state) allows the execution of functions that are not available during normal use•e.g., load a master key, delete stored transactions, alter device configuration, etc. The authority to execute functions that are not available during normal use is controlled through use of a sensitive state or other special authorization that controls the ability to execute these functions. Services not normally available may include CSP loading, CSP output, enabling or disabling device security functions, or the modification of authentication …

A sensitive service (state) allows the execution of functions that are not available during normal use•e.g., load a master key, delete stored transactions, alter device configuration, etc. The authority to execute functions that are not available during normal use is controlled through the use of a sensitive state or other special authorization that controls the ability to execute these functions. Services not normally available may include CSP loading, CSP output, enabling or disabling device security functions, or the modification of …

Modified p. 49 → 47

It must not be ~~feasible~~ to determine a key or other secret information by the use of diagnostic or special test modes.

It must not be practical to determine a key or other secret information by the use of diagnostic or special test modes.

Modified p. 49 → 47

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.

The functionality implemented within the device is such that there is no practical way in which cleartext 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.

Modified p. 49 → 47

Key components entered manually constitute sensitive data during ~~entry~~ and the device shall not differentiate via sound or display the entry of different values.

Key components entered manually constitute sensitive data during entry, and the device shall not differentiate via sound or display the entry of different values.

Modified p. 50 → 48

TB6.1 The tester shall examine vendor documentation and verify 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/authentication codes.

TB6.1 The tester shall examine vendor documentation and verify 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/authentication codes.

Modified p. 50 → 48

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.

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. 50 → 48

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.

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 cleartext or split knowledge of manual CSP loading or CSP output, enabling or disabling device security functions, or the modification of authentication data.

Modified p. 50 → 48

TB6.10 The tester shall attempt to exceed the ~~vendor specified~~ limit on the number of function calls (services) and time limit. Once the limit is exceeded, the tester shall verify that the device has returned to its normal state and requires re-authentication.

TB6.10 The tester shall attempt to exceed the vendor-specified limit on the number of function calls (services) and time limit. Once the limit is exceeded, the tester shall verify that the device has returned to its normal state and requires re-authentication.

Modified p. 51 → 49

• Data inputs cannot be discerned by monitoring audible or ~~electro-magnetic~~ emissions.

• Data inputs cannot be discerned by monitoring audible or electromagnetic emissions.

Modified p. 51 → 49

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.

Cryptographic Method of loading Authentication Master File Key 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. 51 → 49

TB6.16 The tester shall detail any further sensitive services provided by the device that have not been addressed as defined above. This must include the disabling or alteration of any systems or functions relied upon by the device to meet the ~~PTS requirements .~~

TB6.16 The tester shall detail any further sensitive services provided by the device that have not been addressed as defined above. This must include the disabling or alteration of any systems or functions relied upon by the device to meet the HSM requirements.

Modified p. 51 → 49

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.

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.

Removed p. 53

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:

a) Manual (e.g., key-component entry via a keypad);

b) Electronic direct loading (e.g., direct key injection via a cable from the originating device or a key-transfer device);

c) Network distribution and loading (e.g., remote key transport via a network), including remote key loading using asymmetric techniques.

Keys loaded using any other mechanism can only be loaded enciphered.

See ISO 11568 for further information.

HSM commands that include operational keys encrypted under an HSM master or storage key are not in scope for this requirement.

The tester shall verify all that apply.

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 …

Removed p. 54

Clear-text Key Components Entry:

TB7.4 For clear-text key components, the tester shall verify the following:

• Key components are directly entered without traveling through enclosing or intervening systems or a directly connected SCD is used as key loader.

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

TB7.5 The tester shall verify that the device does not allow entry of clear-text key components using network techniques.

TB7.6 The tester shall verify that an audit log is kept by the device and the device …

Removed p. 55

The tester shall ensure that initializing and/or seeding of the RNG cannot be abused to intentionally reproduce a given random value or sequence.

Modified p. 55 → 51

Unpredictability of random numbers is as important as distribution. The implementation shall ensure that seeding or initializing the ~~random number~~ generator at startup cannot be abused to intentionally reproduce a given random value or sequence.

Unpredictability of random numbers is as important as distribution. The implementation shall ensure that seeding or initializing the random-number generator at startup cannot be abused to intentionally reproduce a given random value or sequence.

Modified p. 55 → 51

The device output of those numbers cannot be influenced•e.g., by varying environmental conditions of the ~~device~~ such as manipulating the power ~~supply/electro-magnetic~~ injection.

The device output of those numbers cannot be influenced•e.g., by varying environmental conditions of the device, such as manipulating the power supply/electromagnetic injection.

Modified p. 55 → 51

PRNG designs (Deterministic Random Bit Generator, or DRBG) from NIST ~~SP800-90A~~ or ANSI X9.82 shall be used. Specifically, HASH_DRBG, HMAC_DRBG or CTR_DRBG. DEA and ~~2-key~~ TDEA, as well as DUAL_EC_DRBG are not acceptable for use in a DRBG.

PRNG designs (Deterministic Random Bit Generator, or DRBG) from NIST SP800-90A, ISO 18031, or ANSI X9.82 shall be used. Specifically, HASH_DRBG, HMAC_DRBG or CTR_DRBG. DEA and 2- key TDEA, as well as DUAL_EC_DRBG are not acceptable for use in a DRBG.

Modified p. 55 → 51

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

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

Modified p. 55 → 51

The tester shall outline the process used by the vendor to ensure that any secret values relied upon for ~~random number~~ generation (such as seed values, or keys used in ~~DPRNGs)~~ are sufficiently random, and unique per device.

The tester shall outline the process used by the vendor to ensure that any secret values relied upon for random-number generation (such as seed values, or keys used in DRBGs) are sufficiently random, and unique per device.

Modified p. 55 → 51

~~TB8.2~~ The tester shall confirm that the process outlined above includes a method to provide entropy from a hardware-based source, as well as a software-based “whitening” process such as a ~~DPRNG~~ to remove any bias in the hardware-based system. The tester shall provide a justification that this method ensures that sufficient entropy is provided for all uses of the ~~random number~~ generator.

TB7.2 The tester shall confirm that the process outlined above includes a method to provide entropy from a hardware-based source, as well as a software-based “whitening” process such as a DRBG to remove any bias in the hardware-based system. The tester shall provide a justification that this method ensures that sufficient entropy is provided for all uses of the random-number generator.

Modified p. 55 → 52

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

TB7.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. 56 → 52

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

TB7.6 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. 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:

Modified p. 57 → 53

All ~~PCI related~~ algorithms used must be implemented in accordance with standards referenced in the PCI PTS HSM Modular Security Requirements and the PCI PTS Testing and Approval Program Guide.

All PCI-related algorithms used must be implemented in accordance with standards referenced in the PCI PTS HSM Modular Security Requirements and the PCI PTS Testing and Approval Program Guide.

Modified p. 57 → 53

Any method used to produce encrypted text that relies on “non-standard” modes of operations (e.g., format-preserving Feistel-based Encryption Mode (FFX)) shall be approved by at least one independent security evaluation organization (e.g., a standards body) and subjected to independent expert review; such methods shall also be implemented following all guidelines of said evaluation and peer review including any recommendations for associated key management.

Any method used to produce encrypted text that relies on “non-standard” modes of operations (e.g., format-preserving Feistel-based Encryption Mode (FFX)) shall be approved by at least one independent security evaluation organization (e.g., a standards body) and subjected to independent expert review; such methods shall also be implemented following all guidelines of said evaluation and peer review including any recommendations for associated key management. The independent expert must be qualified via a combination of education, training, and experience in cryptology to …

Modified p. 57 → 53

~~TB9.1~~ The tester shall verify that accepted algorithms are used for the following (as applicable):

TB8.1 The tester shall verify that accepted algorithms are used for the following (as applicable):

Modified p. 57 → 53

• All security protocols ~~Examples of~~ appropriate algorithms and minimum key sizes are stated in Appendix D.

• All security protocols Requirements for appropriate algorithms and minimum key sizes are stated in Appendix D.

Modified p. 57 → 53

Examples of acceptable hashing algorithms include SHA-256, ~~SHA-384~~ and SHA-512. MD5 and SHA-1 are not allowed for use ~~for~~ protocols impacting the device’s security, such as firmware updates.

Examples of acceptable hashing algorithms include SHA-256, SHA-384, and SHA-512. MD5 and SHA-1 are not allowed for use in protocols impacting the device’s security, such as firmware updates.

Modified p. 57 → 53

~~TB9.2~~ In the event of a non-standard mode of operation being used, the tester shall examine documented credentials of the expert reviewer and assess his/her ability to perform the review. The tester shall also examine documentation supporting the assertion of independence of review and confirm that the reviewer is indeed independent. The tester will use ~~his or her~~ judgment in determining the appropriate due diligence.

TB8.2 In the event of a non-standard mode of operation being used, the tester shall examine documented credentials of the independent expert reviewer and assess his/her ability to perform the review. The tester shall also examine documentation supporting the assertion of independence of review and confirm that the reviewer is indeed independent. The tester will use their judgment in determining the appropriate due diligence.

Modified p. 57 → 53

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

TB8.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. 57 → 54

• Review of algorithm verification certifications (e.g., NIST ~~CMVP)~~

• Review of algorithm verification certifications (e.g., NIST CAVP).

Modified p. 57 → 54

• Review of algorithm test results submitted by the vendor from an ~~independent~~ accredited testing ~~organization~~

• Review of algorithm test results submitted by the vendor from an independent, accredited testing organization.

Modified p. 57 → 54

• Evaluation of sample data or internal testing performed by the ~~vendor~~

• Evaluation of sample data or internal testing performed by the vendor.

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

A device may include more than one compliant key exchange and storage scheme.

Devices must support …

Modified p. 58 → 55

When a check value is generated for a key or key component, it shall be generated by a cryptographic ~~process~~ such that all portions of the key or key component are involved in generating the check value.

When a check value is generated for a key or key component, it shall be generated by a cryptographic process, such that all portions of the key or key component are involved in generating the check value.

Removed 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

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

• 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

• Holds one or more professional credentials applicable to the field, e.g., doctoral-level qualifications in a relevant discipline or government certification in cryptography by an authoritative body (e.g., NSA, CES, …

Removed p. 60

These methods must be used for key loading whenever a symmetric key (e.g., AES or TDES) is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually•i.e., through a secure interface, 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.

The software library/chipset used to generate asymmetric keys shall be identified in the Asset Flow Diagram to help safeguard against weak key-generation algorithms.

AES keys can only be:

• Encrypted by another AES key of equal or greater strength.

• Internally generated using a random number generator compliant with B8.

Note: RSA keys with a modulus of 2048 bits may be used to load 128-bits AES keys in conformance with ANSI TR-34. Other public key techniques such as Diffie-Hellman or Elliptic Curve must be used to convey AES keys greater in strength than 128 …

Modified p. 60 → 55

The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.

The evaluating lab may require copies of the source code and assistance from the vendor to make a systematic review of relevant security functions.

Modified p. 60 → 55

~~TB10.1~~ The tester shall determine from vendor documentation the key-management technique used for firmware and application updates. Symmetric key techniques must include the use of ~~Unique Key(s) per Device.~~

TB9.1 The tester shall determine from vendor documentation the key-management technique used for firmware and application updates. Symmetric key techniques must include the use of Unique- Key(s)-per-Device.

Modified p. 60 → 55

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

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

Removed p. 61

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 the device and must be at least seven characters or an equivalent strength These passwords/authentication codes must either be unique per device (and per custodian), except by chance, or if vendor default, they are pre-expired and force a change upon initial use. Clear-text keys or their components are never permitted over a network connection.

c) For encrypted values injected into the device, either from a key loader or from a network …

Modified p. 61 → 56

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

TB9.5 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. 61 → 56

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

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

Removed p. 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. 62 → 56

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

TB9.8 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. 62 → 56

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

TB9.9 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. 62 → 57

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 …

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 cleartext components One Device Designated Key Register Manufacturer Authentication Root Public Key Authentication of firmware updates RSA 3072 Manufacturer Self-signed Public Key Certificate One Vendor- Designated Key Register Manufacturer …

Modified p. 62 → 57

Note: Other keys may be loaded to the device as components (e.g., a terminal master key) or internally generated for external storage under the device’s Master File Key or a variant thereof. If ~~internally stored,~~ the tester shall note this in the summary table.

Note: Other keys may be loaded to the device as components (e.g., a terminal master key) or internally generated for external storage under the device’s Master File Key or a variant thereof. If internally-stored, the tester shall note this in the summary table.

Modified p. 62 → 57

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

TB9.11 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. 62 → 57

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

TB9.12 Using the key table and API guide as a reference, the tester shall note which keys can be loaded by applications in cleartext.

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

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:

a) The method used does not provide a potential timing attack on the device•for example, by using a standard C “memcmp()” function to compare all keys.

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 …

Modified p. 63 → 57

b) ~~Clear-text~~ cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used to encrypt external memory).

b) Cleartext cryptographic keys are not stored encrypted under bulk data-encryption keys (such as keys used to encrypt external memory).

Modified p. 63 → 57

~~TB10.15~~ The tester shall detail any ways in which the device generates keys from other keys, specifically:

TB9.14 The tester shall detail any ways in which the device generates keys from other keys, specifically:

Modified p. 63 → 57

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

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 the ANSI X9.143 variant method (for backwards compatibility).

Modified p. 63 → 58

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

TB9.16 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 in Appendix D.

Modified p. 63 → 58

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

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

Removed p. 64

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

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 for all but one share to perform the aforementioned.

Modified p. 64 → 58

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

TB9.18 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. 65 → 59

Any unintentional or malicious modification (i.e., corruption) of cryptographic security parameters is ~~detected~~ and the device fails in a secure manner.

Any unintentional or malicious modification (i.e., corruption) of cryptographic security parameters is detected, and the device fails in a secure manner.

Modified p. 65 → 59

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

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

Modified p. 66 → 60

The evaluating lab may require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.

The evaluating lab may require copies of the source code and assistance from the vendor to make a systematic review of relevant security functions.

Modified p. 66 → 60

PIN-encryption keys used for acquiring shall only be used to encrypt PIN data. Key-encrypting keys shall only be used to encrypt keys. PIN keys shall never be used to encrypt keys. Key-encrypting keys shall never be used to encrypt PIN data.

PIN-encryption keys used for acquiring shall only be used to encrypt PIN data. Key-encrypting keys shall only be used to encrypt keys. PIN keys shall never be used to encrypt keys. Key-encrypting keys shall never be used to encrypt PIN data. Derivation keys shall never be used to encrypt keys.

Modified p. 66 → 60

~~Account-data~~ encryption keys shall only be used to encrypt ~~account~~ data. ~~Account-data~~ encryption keys shall never be used to encrypt keys.

Data encryption keys shall only be used to encrypt data. Data encryption keys shall never be used to encrypt keys.

Modified p. 66 → 60

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

TB11.1 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the use of cryptographic keys 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. 66 → 60

~~TB12.2~~ The tester shall verify that the device uses one of the following techniques to ensure that a key is only used for its intended purpose:

TB11.2 The tester shall verify that the device uses one of the following techniques to ensure that a key is only used for its intended purpose:

Modified p. 66 → 60

• Physical ~~segregation~~

• Physical segregation,

Modified p. 66 → 60

• Storing keys enciphered under a KEK dedicated to encipherment of a specific type of ~~key~~

• Storing keys enciphered under a KEK dedicated to the encipherment of a specific type of key, or

Removed p. 67

d) Data keys shall never be used to encrypt other keys or PIN or account data.

Modified p. 67 → 61

b) ~~Account-data encryption~~ keys are only used to encrypt ~~account data.~~

b) Key-encrypting keys are only used to encrypt keys.

Modified p. 67 → 61

c) ~~Key-encrypting~~ keys ~~are only~~ used to encrypt ~~keys.~~

c) Data keys shall never be used to encrypt other keys or PINs

Modified p. 67 → 61

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.

d) Derivation keys are never used to encrypt other keys, PINs, or data This evaluation activity should be focused on relevant security-critical sections of the source code to provide an optimum balance between the use of evaluation resources against evaluation goals overall.

Modified p. 68 → 62

~~Clear-text secret and private keys and clear-text PINs must not exist in unprotected environments.~~ Note: This does not apply to cryptographic keys that are never used to encrypt or decrypt ~~data;~~ or are not used for authentication.

Note: This does not apply to cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication.

Modified p. 68 → 62

~~Clear-text~~ secret and private keys shall only be output into another secure cryptographic device under dual control if the device is designed for key injection.

Cleartext secret and private keys shall only be output into another secure cryptographic device under dual control if the device is designed for key injection.

Modified p. 68 → 62

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

Cleartext PINs may be output in issuer environments. Cleartext PINs are not allowed to be output under the security policy (see C1 and B13) for devices used for PIN processing by an acquirer or its agent.

Modified p. 68 → 62

The evaluating lab shall require copies of source code and assistance from the vendor to make a systematic review of relevant security functions.

The evaluating lab shall require copies of the source code and assistance from the vendor to make a systematic review of relevant security functions.

Modified p. 68 → 62

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

TB12.1 The tester shall examine any documentation•i.e., the Asset Flow Diagram, API programmer’s guide, specifications, block diagrams, etc.•containing information relating to:

Modified p. 68 → 62

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

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

TB14.1 The tester shall verify that the security policy configuration examined in C1 only allows the following translations when the policy is implemented.

PINs enciphered using ISO format 0, ISO format 3, or ISO format 4 must not be translated into any PIN-block format other than ISO format 0, 3, or 4 except when translated to ISO format 2 as specified in the table below. PINs enciphered using ISO format 1 may be translated into ISO format 0, 3, or 4 but must not be translated back into ISO format 1. ISO format 1 may be translated into ISO format 2 as specified in the table below.

Translations between PIN-block formats that each include the PAN shall not support a change in the PAN. The PIN-translation capability between ISO formats 0, 3, or 4 (including translations from ISO format 0 to ISO format 0, from ISO format 3 to ISO format 3, …

Modified p. 69 → 63

~~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 in the table in TB13.1.

Modified p. 69 → 63

~~Note:~~ If supporting online PIN processing:

Note 1: If supporting online PIN processing:

Modified p. 69 → 63

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

• It may also support Fixed Key Note 2: If supporting online PIN entry, the device must support ISO PIN-block format 4 and may support any of the following PIN-block formats:

Modified p. 69 → 63

~~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 PVV/offset calculating or verifying function.

• ISO Format 3 Note 3: 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 then invoking a PVV/offset calculating or verifying function.

Modified p. 69 → 64

Standard PIN-block formats (i.e., ISO formats 0, 1, 2, 3, and 4) shall not be translated into ~~non- standard~~ PIN-block formats.

Note: Standard PIN-block formats (i.e., ISO formats 0, 1, 2, and 4) shall not be translated into non-standard PIN-block formats.

Removed p. 70

This table illustrates restrictions on translations between PIN block formats that are applicable when the HSM does not enforce unique-key-per-transaction encryption for the resulting PIN block:

• Permitted anywhere without change of PAN

TB14.4 The tester shall verify the following restrictions apply for compact PIN block formats (0, 1, 2, and 3) regardless of key-management technology used.

• ISO format 4 may be supported in calculating values used for PIN verification that are derived from the PIN and PAN, e.g., PIN offsets and PIN verification values (PVV).

Modified p. 70 → 64

~~Translation~~ To → From  ~~ISO~~ Format ~~ISO~~ Format ~~ISO~~ Format ~~ISO~~ Format 0, 3, 4

Requirements for Translations To → From  Format 0 Format 1 Format 2 Format 3, 4

Modified p. 70 → 64

• 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 formats, the tester shall confirm that the …~~

- Permitted anywhere without a change of PAN - Change of PAN only permitted in a sensitive state for card issuance - Change of PAN Token to real PAN is only permitted with cryptographic binding of PAN Token to real PAN Not permitted Permitted for submission to an Format 1 Permitted Permitted Permitted for submission to an Format 2 Not permitted Not permitted Permitted for submission to an Not permitted Format 3, 4

Modified p. 70 → 64

~~TB14.3~~ The tester shall verify the following (as applicable):

TB13.3 The tester shall verify the following (as applicable):

Modified p. 70 → 64

• All key-encryption keys ~~must~~ have an appropriate length and are used with an accepted algorithm.

• All key-encryption keys have an appropriate length and are used with an accepted algorithm.

Modified p. 70 → 65

• Only ISO formats 0 and 3 shall be supported in calculating values used for PIN verification that are derived from the PIN and ~~PAN⎯e.g.,~~ PIN offsets and PIN verification values (PVV).

• Only ISO formats 0, 3, and 4 shall be supported in calculating values used for PIN verification that are derived from the PIN and PAN•e.g., PIN offsets and PIN verification values (PVV).

Modified p. 70 → 65

• When calculating values derived from the PIN and PAN, if the portion of the account number enciphered in the ~~input encrypted~~ PIN block does not agree with the input PAN, the calculated value shall not be returned except in the following case: Where the introduction of a new PAN is required to support account number changes for card issuance, support for change of PAN during calculation of the derived value shall be provided only while the host security modules …

• When calculating values derived from the PIN and PAN, if the portion of the account number enciphered in the input-encrypted PIN block does not agree with the input PAN, the calculated value shall not be returned except in the following cases:

Modified p. 71 → 65

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

• 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), as well as the fill digits.

Modified p. 72 → 66

Logs shall not contain ~~clear-text~~ sensitive data unless those logs are protected in accordance with Requirement A3. Logs exported from the device shall never contain ~~clear-text~~ sensitive data.

Logs shall not contain cleartext sensitive data unless those logs are protected in accordance with Requirement A3. Logs exported from the device shall never contain cleartext sensitive data.

Modified p. 72 → 66

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

TB14.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. 72 → 66

~~TB15.2~~ The tester shall verify that the device supports secure logging, including time stamps, of ~~security sensitive~~ commands such as:

TB14.2 The tester shall verify that the device supports secure logging, including time stamps, of security-sensitive commands such as:

Modified p. 72 → 66

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.

d) Enabling and disabling device security functions TB14.3 The tester shall verify that the device requires dual control to delete secure logs stored internally.

Modified p. 72 → 66

~~TB15.4~~ The tester shall verify that the device never exports logs that contain ~~clear-text~~ sensitive data.

TB14.4 The tester shall verify that the device never exports logs that contain cleartext sensitive data.

Modified p. 73 → 67

Applications are considered to be separated by access rights. OS/firmware is considered all code, which is responsible ~~to enforce, manage,~~ or ~~change~~ such access rights. Therefore, OS/firmware code is necessarily part of the firmware as defined with B18.

Applications are considered to be separated by access rights. OS/firmware is considered all code, which is responsible for enforcing, managing, or changing such access rights. Therefore, OS/firmware code is necessarily part of the firmware as defined with B18.

Modified p. 73 → 67

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.

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. 73 → 67

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.

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.

Modified p. 73 → 67

Vendors should provide configuration lists and description of the separation mechanism to support answers.

Vendors should provide configuration lists and a description of the separation mechanism to support answers.

Removed p. 74

TB16.9 The tester shall review the configuration of the mechanisms described above and confirm that it maintains application separation.

Modified p. 74 → 68

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

TB15.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 with 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. 74 → 68

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

TB15.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. 74 → 68

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

TB15.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. 74 → 68

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

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

Modified p. 74 → 68

~~TB16.6~~ The tester shall detail what mechanisms exist within the device to allow for the execution of non-ROM-based configuration or program data•for example, processors, micro-controllers, FPGAs, etc. The tester shall note which of these mechanisms execute code that has been considered in-scope (code that impacts these security requirements) of the evaluation, and which do not.

TB15.6 The tester shall detail what mechanisms exist within the device to allow for the execution of non-ROM-based configuration or program data•for example, processors, micro-controllers, FPGAs, etc. The tester shall note which of these mechanisms execute code that has been considered in-scope (code that impacts these security requirements) of the evaluation, and which do not.

Modified p. 74 → 68

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

TB15.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. 74 → 68

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

TB15.8 If the device allows for the execution of different applications 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. 75 → 69

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

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

OS/firmware modules such as, for example, peripheral drivers, file systems, or inter-process communication protocols shall be regarded as components. Applications responding to external interfaces or communicating with the firmware shall be regarded as services.

Modified p. 76 → 70

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.

The intended operation is considered the functionality relevant to B2 and is representative of the functionality provided by the device. For multi-application devices, the intended operation further includes the operation of applications without security impacts.

Modified p. 76 → 70

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.

Firmware and software running on the device shall be designed to run with minimal privilege, and shall 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 are permitted to have such access.

Modified p. 76 → 70

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.

For the purposes of this requirement, sensitive information, functions, and peripherals include any method that may provide access to cleartext cryptographic keys and components, customer PINs, passwords/authentication codes used for entry into sensitive states, or other items of information or configuration that are required to meet the core logical and physical requirements.

Modified p. 76 → 70

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

TB16.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 that shows all OS/firmware components and other software, with an explanation of the purpose and a rationale for their presence.

Modified p. 76 → 70

~~TB17.2~~ The tester shall verify that the security policy enforced by the device does not allow unauthorized or unnecessary functions.

TB16.2 The tester shall verify that the security policy enforced by the device does not allow unauthorized or unnecessary functions.

Modified p. 76 → 70

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

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

Modified p. 76 → 70

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

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

Modified p. 76 → 70

~~TB17.5~~ The tester shall note whether the device implements a commercial operating system, custom operating system, function executive, or other mechanism. If the device uses a commercial operating system, the tester shall note the name and version of this system.

TB16.5 The tester shall note whether the device implements a commercial operating system, custom operating system, function executive, or other mechanism. If the device uses a commercial operating system, the tester shall note the name and version of this system.

Modified p. 76 → 70

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

TB16.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. 77 → 71

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 match or have differences. If differences are detected, it is necessary to address why these occur with regard to compliance to this requirement.

Modified p. 77 → 71

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

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

Modified p. 78 → 72

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

TB17.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. 78 → 72

~~TB18.2~~ The tester shall obtain the unique device ID from the device using the methods described in vendor documentation.

TB17.2 The tester shall obtain the unique device ID from the device using the methods described in vendor documentation.

Modified p. 79 → 73

When switching between the two modes, keys may either be zeroized or mechanisms must be in place to prevent keys from being used in both modes. This does not apply to keys generated ~~internal~~ to an IC that are used only ~~internal~~ to the IC and are never output.

When switching between the two modes, keys may either be zeroized or mechanisms must be in place to prevent keys from being used in both modes. This does not apply to keys generated internally to an IC that are used only internally to the IC and are never output.

Modified p. 79 → 73

~~Internally generated~~ keys that cannot be updated or output do not need to be zeroized and may be shared between the two modes if their only use is for internal storage protection.

Internally-generated keys that cannot be updated or output do not need to be zeroized and may be shared between the two modes if their only use is for internal storage protection.

Modified p. 79 → 73

Keys used to authenticate that it is a valid ~~device~~ or keys used to sign information ~~like~~ a device ~~identifier~~ may be shared between the two modes.

Keys used to authenticate that it is a valid device, or keys used to sign information such as a device identifier, may be shared between the two modes.

Modified p. 79 → 73

If the device allows the two modes to be selected remotely, the method used must enforce mutual authentication and prevent ~~reply~~ attacks.

If the device allows the two modes to be selected remotely, the method used must enforce mutual authentication and prevent replay attacks.

Modified p. 79 → 73

The mode indication may be either permanent (e.g., an indicator on the device or a prompt on a ~~display) or~~ transitory (e.g., an indication of the mode upon transition from one mode to the ~~other~~ and when querying the current device state), or both.

The mode indication may be either permanent (e.g., an indicator on the device or a prompt on a display), transitory (e.g., an indication of the mode upon transition from one mode to the other, and when querying the current device state), or both.

Modified p. 79 → 73

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

TB18.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. 79 → 73

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

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

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.

Modified p. 80 → 76

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

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

Modified p. 80 → 76

Also see ~~B14~~ for validation of allowed PIN translations.

Also see B13 for validation of allowed PIN translations.

Modified p. 80 → 76

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.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. The tester shall verify any URL in the security policy as being valid and usable.

Modified p. 80 → 76

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

TC1.2 The tester shall review the device security policy and note whether this clearly states that the device is restricted to use in environments meeting at least the security requirements of a controlled environment as defined in the Key Management and Operations Security and Test Requirements.

Modified p. 80 → 77

~~TC1.4~~ The tester shall confirm that the security policy defines all CSPs or classes of CSPs stored or used in the module. The required information for predefined cryptographic keys includes key name or identifier, associated algorithm, length, usage, storage location, and erasure method. The required information for other predefined CSPs includes name or identifier, usage, storage location, erasure method, and any associated algorithms.

TC1.6 The tester shall confirm that the security policy defines all CSPs or classes of CSPs stored or used in the module. The required information for predefined cryptographic keys includes key name or identifier, associated algorithm, length, usage, storage location, and erasure method. The required information for other predefined CSPs includes name or identifier, usage, storage location, erasure method, and any associated algorithms.

Removed p. 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. 81 → 77

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

TC1.8 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 practical to determine the key by exhaustive attack elapses, as defined in NIST SP 800-57-1.

Modified p. 81 → 77

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

TC1.9 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. 81 → 77

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 cleartext PINs).

Modified p. 81 → 77

~~TC1.8~~ The tester shall examine the security policy to verify that instructions are provided with regard to tamper evidence, inspection ~~frequency~~ and procedures.

TC1.10 The tester shall examine the security policy to verify that instructions are provided with regard to tamper evidence, inspection frequency, and procedures.

Modified p. 81 → 77

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

TC1.11 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 B14, any restrictions on operator access to logs, and procedures for accessing and deleting logs. Where used, the division of responsibilities between the HSM and external log infrastructure used for long-term storage is documented in the device's security policy.

Modified p. 81 → 77

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

TC1.12 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. 81 → 77

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

TC1.13 The tester shall examine the security policy and relevant vendor documentation to verify that the documentation includes procedures for authentication of the device when received via shipping. Note that this may include visual or cryptographic methods.

Modified p. 81 → 77

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

TC1.14 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. 81 → 78

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

TC1.16 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, or 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 …

Modified p. 81 → 78

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

TC1.17 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. 82

• 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 policy and confirm that only functions allowed in the policy can be executed when in approved mode.

Modified p. 82 → 78

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

TC1.19 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. 82 → 78

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

TC1.20 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. 82 → 78

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

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

Modified p. 82 → 78

This table illustrates restrictions on translations between ~~PIN block~~ formats that are applicable when the HSM ~~does~~ not ~~enforce~~ unique-key-per-transaction encryption for the resulting PIN block:

This table illustrates restrictions on translations between PIN-block formats that are applicable when the HSM is not using a unique-key-per-transaction encryption for the resulting PIN block:

Modified p. 82 → 78

Translation To → From  ISO Format ~~ISO Format ISO Format ISO Format~~ 0, 3, 4

Translation To → From  ISO Format 0, 3, 4 ISO Format 1 ISO Format 2 ISO Format

Modified p. 82 → 78

• Permitted anywhere without change of PAN

• Permitted anywhere without a change of PAN

Modified p. 82 → 79

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

TC1.23 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. 82 → 79

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

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

Modified p. 83 → 79

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

TC1.28 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. 83 → 79

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

TC1.29 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. 83 → 79

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

TC1.30 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. 83 → 79

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

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

Modified p. 83 → 79

~~TC1.28~~ For HSMs intended for ~~cloud~~ usage, the tester shall confirm that the security policy outlines how the HSM Solution is implemented, what cryptographic services are provided, how the user and components of the HSM Solution are authenticated, and how to securely disable or deprecate the storage of user keys from any or all components of that solution. Alternatively, the tester shall confirm that the information is in a separate ~~publicly available~~ security policy. See DTR ~~K9.~~

TC1.32 For HSMs intended for multi-tenant usage, the tester shall confirm that the security policy outlines how the HSM Solution is implemented, what cryptographic services are provided, how the user and components of the HSM Solution are authenticated, and how to securely disable or deprecate the storage of user keys from any or all components of that solution. Alternatively, the tester shall confirm that the information is in a separate publicly-available security policy. See DTR H9.

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

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.

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

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.

TD2.2 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.3 The tester shall generate secret and/or asymmetric key pairs and verify that the key …

Removed p. 86

This is not intended to preclude the following:

• The use of the KLD for loading multiple HSMs with the same Master File Key (e.g., when the HSMs are used for load sharing with a single key database);

• The use of the KLD to generate unique keys per device, load them into a PED, and later transfer the file of keys to an HSM;

• The use of Base Derivation Keys or similar to generate initial DUKPT keys or similar UKPT schemes;

• The loading of the same public key to multiple devices;

• The use of Key-Encipherment Keys for importing/exporting of cryptograms.

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.

TD3.2 The tester shall review the source code of …

Removed p. 87

See Appendix F, “Domain-Based Asset Flow Analysis” for definitions of security domains within the HSM. Assets may be passed within components sharing the same or higher security domain, as long as all of the components within that domain meet the security requirements of that domain.

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.

TD4.2 The tester shall attempt transfer a cryptographic key to a component providing lower security.

Removed p. 88

This is not meant to preclude authenticated firmware changes.

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.

TD5.2 The tester shall attempt to modify the device’s functional capabilities and document how the device responds.

Removed p. 89

The remote administration device cannot be put into an operational state until an initialization process has been completed and a secure relationship (i.e., cryptographic) has been established between the remote administration platform and the target device(s).

Remote admin connectivity must be terminated during the initialization sequence and can only be established after the initialization sequence is complete.

TE1.1 The tester shall verify that all operational services cease during the initialization processes.

TE1.2 The tester shall verify that no operational services are started until the initialization is complete.

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

• Disabling or enabling of device functions;

• Change of passwords/authentication codes or data that enable the device to enter 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.

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.

Sensitive state limits are consistent with B6.

The …

Removed p. 92

For devices that manually activate the MAC keys, the identity of the key is displayed on the device to ensure the correct key is used if multiple keys are present in the device.

Clear-text-computed MACs should never be outputted on the denial or confirmation of the MAC.

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.

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

One of the following as defined in ISO 16609 must be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4.

TF2.1 The tester shall examine and cite any relevant documentation (e.g., design documentation, key- management specification) that describes the MAC length.

TF2.2 The tester shall list the MAC length values used by the device and all values supports.

TF2.3 The tester shall verify and list all MAC generation algorithms used by the device.

Removed p. 94

One of the following should be used: MAC algorithm 1 using padding method 3, or MAC algorithm 5 using padding method 4.

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.

TF3.2 The tester shall verify that the MAC generation and verification techniques meet ISO 16609.

TF3.3 The tester shall list the techniques used for MAC generation and verification.

Removed p. 95

MAC keys shall be used for only one function such as verify the MAC of received text or generate and output a MAC for a text being transmitted.

TF4.1 The tester shall examine and cite any additional documentation (e.g., design documentation, key-management specification) that describes unidirectional MAC keys.

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.

TF4.3 The tester shall list all MAC functions to ensure that each MAC key is used for a single function.

Removed p. 96

• The device includes mechanisms such that the removal of the device from its operational location will cause the automatic erasure of the cryptographic keys contained within the device; or

• Removal of the device would be of no benefit because its tamper-resistance or tamper- responsive characteristics ensure that the extraction of cryptographic keys or other secret data is not feasible.

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.

TG1.2 The tester shall note which techniques are employed by the vendor to meet the requirement.

Removed p. 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. 97 → 93

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

TE2.2 The tester shall describe the algorithm and key sizes used for the initial keys and confirm they meet the requirements from DTR E3.

Removed p. 98

• Manual input of control data⎯e.g., key-verification code⎯to enable export, import or use of a key; and

• Permitting movement of the device without activating a key-erasure mechanism.

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.

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

• Totally equivalent to a series of standard and approved functions; or

• Limited to use only keys that, by virtue of key separation, cannot be used with keys, or modified keys, of non-proprietary functions.

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.

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

• The asymmetric private and public key pair is generated within the digital signature device; and

• The asymmetric private key is only exported outside the original digital signature device under dual control; and

• Mechanisms for the control of the use of the private key are provided.

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.

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. 100 → 95

~~TH1.4~~ The tester shall ~~verify that mechanisms~~ for the ~~control~~ of ~~the use of the private key are provided.~~

TE3.3 The tester shall detail the function/s for retrieving the identity of a target device.

Removed p. 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 and appropriate certificate management procedures; or

• Use of public key certificates and appropriate certificate management procedures; or

• Other equivalent mechanisms to irrefutably determine the identity of the owner of the corresponding private key.

• Other equivalent mechanisms to irrefutably determine the identity of the owner of the corresponding private key.

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.

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:

• Use of public key certificates, where the public key certificate was obtained from an authorized certificate authority;

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

Modified p. 102 → 99

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

TF1.2 The tester shall confirm the HSM processing element(s) are clearly defined within the solution, referencing the Asset Flow Diagram to show this is included correctly.

Modified p. 102 → 99

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

TF1.3 The tester shall confirm through their understanding of the HSM processing element(s) reviewed during testing that the Asset Flow Diagram is correct and complete, providing an accurate picture of how secret and private keys and key components are managed by the system.

Modified p. 102 → 99

~~TI1.4~~ The tester shall confirm that the HSM processing element definition includes a physical boundary and that no ~~clear-text~~ cryptographic keys or key components are accessible outside of this boundary.

TF1.4 The tester shall confirm that the HSM processing element definition includes a physical boundary and that no cleartext cryptographic keys or key components are accessible outside of this boundary.

Modified p. 102 → 99

~~TI1.5~~ The tester shall confirm that the HSM processing element physical boundary, and all firmware code therein, has been assessed as compliant to all PCI HSM physical and logical security requirements, including protection of sensitive data to an attack potential of at least 35 per HSM processing element for identification and initial exploitation, with a minimum of 15 for initial exploitation, as defined in Appendix A.

TF1.5 The tester shall confirm that the HSM processing element physical boundary, and all firmware code therein, has been assessed as compliant to all PCI HSM physical and logical security requirements, including protection of sensitive data to an attack potential of at least 35 per HSM processing element for identification and initial exploitation, with a minimum of 15 for initial exploitation, as defined in Appendix A.

Modified p. 102 → 99

~~TI1.6~~ The tester shall confirm that compliance to the PCI HSM physical and logical security requirements is provided entirely by the features of the HSM device defined by the physical boundary, and that there is no reliance on the security of the environment or procedural controls to achieve a protection level of at least 35 per HSM processing element for identification and initial exploitation, with a minimum of 15 for initial exploitation, as defined in Appendix A.

TF1.6 The tester shall confirm that compliance to the PCI HSM physical and logical security requirements is provided entirely by the features of the HSM device defined by the physical boundary, and that there is no reliance on the security of the environment or procedural controls to achieve a protection level of at least 35 per HSM processing element for identification and initial exploitation, with a minimum of 15 for initial exploitation, as defined in Appendix A. For devices restricted …

Removed p. 103

• Be installed and operated in an environment meeting at least the security requirements of a controlled environment, or

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 for the HSM virtualization system. The implementation and scope must include any features relied upon for compliance to other requirements within this standard that are not otherwise implemented in the HSM processing element.

TI2.2 The tester shall confirm …

Modified p. 103 → 99

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

Devices restricted to deployment in controlled (or higher) environments protect sensitive data to an attack potential of at least 26 per HSM processing element for identification and initial exploitation, with a minimum of 13 for initial exploitation as defined in Appendix A.

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

Modified p. 105 → 100

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 …

This requirement is designed for solutions where the HSM virtualization system and HSM processing element are contained in 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 …

Modified p. 105 → 100

~~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 that it is not possible for the virtualization code to have any access to ~~clear-text~~ keys or components, no further …

TF2.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 that it is not possible for the virtualization code to have any access to cleartext keys or components, no further …

Modified p. 105 → 100

~~TI4.2~~ Where the HSM virtualization system(s) and the HSM processing element(s) cannot be shown to have clear and physically distinct processing and memory storage areas, the tester shall confirm that the HSM virtualization system has been considered in scope for all testing requirements assessed against the HSM processing element(s), and that the findings confirm compliance in all areas.

TF2.2 Where the HSM virtualization system(s) and the HSM processing element(s) cannot be shown to have clear and physically distinct processing and memory storage areas, the tester shall confirm that the HSM virtualization system has been considered in scope for all testing requirements assessed against the HSM processing element(s), and that the findings confirm compliance in all areas.

Modified p. 106 → 101

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.

Strong isolation between the cryptographic keys of different HSM Tenants 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.

Modified p. 106 → 101

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 …

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

Modified p. 106 → 101

The intent is to ensure that the creation of customized functions or special operations does not allow for code loaded into the HSM processing element execution environment.

The intent is to ensure that the creation of customized functions or special operations does not allow for code to be loaded into the HSM processing element execution environment.

Modified p. 106 → 101

~~TI5.1~~ The tester shall detail where all ~~clear-text~~ secret and private cryptographic keys are processed or stored, including any key components, referring back to the asset flow diagram. This must consider temporary storage during execution, in register and cache memory, as well as external storage.

TF3.1 The tester shall detail where all cleartext secret and private cryptographic keys are processed or stored, including any key components, referring back to the asset flow diagram. This must consider temporary storage during execution, in register and cache memory, as well as external storage.

Modified p. 106 → 101

~~TI5.2~~ The tester shall note whether the HSM Solution supports the processing of more than one set of ~~clear-text~~ keys at any one time within the same HSM processing element⎯i.e., where processing on another key may begin prior to the execution of the buffer-clearing functions used by the HSM to erase key material. Where this is the case, this requirement shall be marked as non-compliant.

TF3.2 The tester shall note whether the HSM Solution supports the processing of more than one set of cleartext keys at any one time within the same HSM processing element⎯i.e., where processing on another key may begin prior to the execution of the buffer-clearing functions used by the HSM to erase key material. Where this is the case, this requirement shall be marked as non-compliant.

Modified p. 106 → 101

~~TI5.3~~ The tester shall note whether the HSM Solution supports or implements code that is not included within the scope of firmware and assessment under the HSM processing element requirements, such as customer scripts or application ~~code~~ Where this is the case, this requirement shall be marked as ~~non-compliant. I.e.,~~ you cannot have customer code in the HSM processing element. Any code in the HSM processing element is firmware and must be assessed as part of these requirements.

TF3.3 The tester shall note whether the HSM Solution supports or implements code that is not included within the scope of firmware and assessment under the HSM processing element requirements, such as customer scripts or application code. Where this is the case, this requirement shall be marked as non-compliant•i.e., you cannot have customer code in the HSM processing element. Any code in the HSM processing element is firmware and must be assessed as part of these requirements.

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

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

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

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

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

Modified p. 112 → 102

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.

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 Tenants 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 cleartext within a complex operating system or code where memory allocation and clearing are abstracted.

Modified p. 112 → 102

• 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 is an ASIC (or interfaces to such) that has RTL-level functions to manage cleartext keys (decrypt with a tamper key, perform crypto, clear keys before loading other keys).

Modified p. 112 → 102

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

• The HSM processing element does “touch” cleartext 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.

Modified p. 112 → 102

~~TJ6.1~~ The tester shall detail the execution environment used by the HSM processing element(s) of the solution, specifically indicating the short- and long-term storage areas used during processing of ~~clear-text~~ cryptographic keys and components.

TF4.1 The tester shall detail the execution environment used by the HSM processing element(s) of the solution, specifically indicating the short- and long-term storage areas used during processing of cleartext cryptographic keys and components.

Modified p. 112 → 102

~~TJ6.2~~ The tester shall confirm whether the HSM Solution allows for multiple HSM ~~Solution Consumers~~ to share the execution environment of any single HSM processing element. This includes processing of this data at different times but without complete decommissioning and ~~re- commissioning~~ of the HSM processing element, or at the same time using different processor cores or execution paths.

TF4.2 The tester shall confirm whether the HSM Solution allows for multiple HSM Tenants to share the execution environment of any single HSM processing element. This includes processing of this data at different times but without complete decommissioning and re-commissioning of the HSM processing element, or at the same time using different processor cores or execution paths.

Modified p. 112 → 102

~~TJ6.3~~ Where sharing of execution environments is possible, the tester shall confirm what methods are implemented to clear ~~clear-text cryptographic key~~ material from all short- and long-term storage areas of the HSM processing element. This may involve hardware or software ~~methods~~ but must accommodate for any and all virtualized memory, wear-leveling, internal registers, and data cache locations.

TF4.3 Where sharing of execution environments is possible, the tester shall confirm what methods are implemented to clear cleartext cryptographic-key material from all short- and long-term storage areas of the HSM processing element. This may involve hardware or software methods, but must accommodate for any and all virtualized memory, wear-leveling, internal registers, and data cache locations.

Modified p. 112 → 102

~~TJ6.4~~ For systems where it is not ~~feasible~~ to manage data clearance at the register level from software⎯such as when complex operating systems and high-level languages are involved⎯the tester shall confirm that hardware features are implemented. These may involve specific “data purge” commands to erase data paths, or power cycling of the HSM processing element prior to operation on the cryptographic keys of another HSM ~~Solution Consumer.~~

TF4.4 For systems where it is not practical to manage data clearance at the register level from software⎯such as when complex operating systems and high-level languages are involved⎯the tester shall confirm that hardware features are implemented. These may involve specific “data purge” commands to erase data paths, or power cycling of the HSM processing element prior to operation on the cryptographic keys of another HSM Tenant.

Modified p. 113 → 103

~~TJ6.6~~ The tester shall execute the buffer-clearing operation on the HSM processing element and confirm that it operates as expected.

TF4.6 The tester shall execute the buffer-clearing operation on the HSM processing element and confirm that it operates as expected.

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

Modified p. 115 → 104

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.

Due to the online and elastic nature of HSM Solutions, the signing of firmware images must be tightly controlled; hence additional security controls are required beyond standard PCI HSM implementations.

Modified p. 115 → 104

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

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

Modified p. 115 → 104

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

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

Modified p. 115 → 104

~~TJ8.3~~ The tester shall detail the methods used to prevent “roll back” of a previous firmware image. Where it is noted that installation of older firmware images is possible, the tester shall confirm that such installation ~~will erase all cryptographic keys from the HSM processing element.~~

TF5.3 The tester shall detail the methods used to prevent “roll back” of a previous firmware image. Where it is noted that installation of older firmware images is possible, the tester shall confirm that such installation is compliant with DTR B6.

Modified p. 115 → 104

~~TJ8.4~~ The tester shall attempt to install a correctly signed firmware version that is identified as being older than the one currently in the HSM processing element under test. The tester shall verify that the operation is rejected or all cryptographic keys stored by the HSM are erased.

TF5.4 The tester shall attempt to install a correctly signed firmware version that is identified as being older than the one currently in the HSM processing element under test. The tester shall verify that the operation is rejected or that all cryptographic keys stored by the HSM are erased.

Modified p. 115 → 104

~~TJ8.5~~ The tester shall confirm that all requirements from DTR L3 are met.

TF5.5 The tester shall confirm that all requirements from DTR G3 are met.

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

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

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

Modified p. 119 → 105

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

This requirement is intended to be assessed for processes used to provision new high-level cryptographic keys for an HSM Tenant 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 Tenants.

Modified p. 119 → 105

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

TF6.1 The tester shall confirm, for each method of provisioning HSM Tenant keys to an HSM processing element, that a transport key is established for the conveyance of the HSM Tenant key.

Modified p. 119 → 105

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

TF6.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 Tenants or by the same HSM Tenant between different provisioning processes.

Modified p. 119 → 105

~~TK4.3~~ The tester shall confirm that the process(es) used to establish the transport key implement the principles of perfect forward secrecy.

TF6.3 The tester shall confirm that the process(es) used to establish the transport key implement the principles of perfect forward secrecy.

Modified p. 119 → 105

~~TK4.4~~ The tester shall confirm that the cryptographic keys of an HSM ~~Solution Consumer~~ are encrypted within a key-wrapping process to protect them during provisioning.

TF6.4 The tester shall confirm that the cryptographic keys of an HSM Tenant are encrypted within a key-wrapping process to protect them during provisioning.

Modified p. 119 → 105

~~TK4.5~~ The tester shall confirm that the transport key(s) are erased using methods compliant with the HSM Solution buffer-clearing requirement once the provisioning process is complete, and no later than once the provisioned keys of the HSM ~~Solution Consumer~~ are able to be used for cryptographic operations (excluding any key-verification processes used to check the key is valid after loading).

TF6.5 The tester shall confirm that the transport key(s) are erased using methods compliant with the HSM Solution buffer-clearing requirement once the provisioning process is complete, and no later than once the provisioned keys of the HSM Tenant are able to be used for cryptographic operations (excluding any key-verification processes used to check the key is valid after loading).

Modified p. 119 → 105

~~TK4.6~~ The tester shall detail what cryptographic methods are implemented and confirm that these controls prevent man-in-the-middle, pre-play, and replay attacks. Methods must use acceptable algorithms and key lengths.

TF6.6 The tester shall detail what cryptographic methods are implemented and confirm that these controls prevent man-in-the-middle, pre-play, and replay attacks. Methods must use acceptable algorithms and key lengths.

Removed p. 120

TK5.1 The tester shall confirm how the HSM Solution stores the cryptographic keys of HSM Solution Consumers, and how this ensures isolation between the cryptographic keys of different HSM Solution Consumers present on the same HSM processing element.

TK5.2 For solutions where the cryptographic keys of HSM Solution Consumers may be stored external to the tamper-responsive boundary of the HSM processing element, the tester shall confirm that the tamper key that is implemented for the storage of keys for each separate HSM Solution Consumer is either internally generated by the HSM processing element itself, or is loaded and managed by the HSM Solution Consumer directly.

TK5.3 The tester shall confirm that the tamper key(s) created by the HSM processing element(s) are generated by a secure key-generation process, using either the random number generator validated under the PCI HSM requirements, or a key-derivation process approved by NIST. Tamper keys generated using a derivation …

Modified p. 120 → 106

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

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

Modified p. 120 → 106

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

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 Tenant as per Requirement G1, to achieve elastic processing during use. However, such master keys would be in scope of this requirement if used for the storage of the cryptographic keys of more than one HSM Tenant.

Modified p. 120 → 106

Cryptographic keys directly managed by the HSM ~~Solution Consumer~~ are not in scope of this requirement.

Cryptographic keys directly managed by the HSM Tenant are not in scope of this requirement.

Modified p. 120 → 106

Solutions that use cryptographic keys of the HSM ~~Solution Consumer~~ as the HSM tamper key for that HSM ~~Solution Consumer~~ must ensure that these keys are not shared between different HSM ~~Solution Consumers~~ (except by chance, or through methods outside of the control of the HSM Solution Provider). It is not acceptable for an HSM Solution to implement a master or tamper key that is under the control of the HSM Solution Provider (where it is open to compromise through …

Solutions that use cryptographic keys of the HSM Tenant as the HSM tamper key for that HSM Tenant must ensure that these keys are not shared between different HSM Tenants (except by chance, or through methods outside of the control of the HSM Solution Provider). It is not acceptable for an HSM Solution to implement a master or tamper key that is under the control of the HSM Solution Provider (where it is open to compromise through backup or loading …

Modified p. 120 → 106

This requirement does not mandate the storage of cryptographic keys owned by the HSM ~~Solution Consumers⎯systems~~ that dynamically allocate user keys on a per-operation basis and do not store user cryptographic keys do not need to meet this requirement. However, such systems would still be required to meet other requirements of this standard, including but not necessarily limited to those for provisioning and secure channels. .

This requirement does not mandate the storage of cryptographic keys owned by the HSM Tenants - systems that dynamically allocate user keys on a per-operation basis and do not store user cryptographic keys do not need to meet this requirement. However, such systems would still be required to meet other requirements of this standard, including but not necessarily limited to those for provisioning and secure channels.

Modified p. 121 → 107

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

TF7.5 The tester shall confirm that any tamper key not directly managed by an HSM Tenant cannot be exported from the HSM processing element⎯including 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 Tenant must not be able to be exported from the HSM processing element in any form.

Modified p. 121 → 107

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

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

Modified p. 121 → 107

~~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 that the wrapped keys stored ~~external~~ to the HSM processing elements are different in each case.

TF7.7 For solutions that implement tamper keys generated by the HSM processing element, the tester shall establish two HSM Tenant instances on a single HSM processing element and load the same cryptographic key into each instance. The tester shall confirm that the wrapped keys stored externally to the HSM processing elements are different in each case.

Modified p. 121 → 107

~~TK5.8~~ For solutions that implement the ability for HSM ~~Solution Consumers~~ to load their own tamper keys, the tester shall detail what cryptographic methods are implemented for the establishment or loading of any master keys used by the HSM ~~Solution Consumer(s),and~~ confirm that these controls prevent ~~man-in-the-middle,~~ pre-play, and replay attacks. These controls must include preventing such attacks by the HSM ~~Solution~~ Provider itself. Methods must use acceptable algorithms and key lengths.

TF7.8 For solutions that implement the ability for HSM Tenants to load their own tamper keys, the tester shall detail what cryptographic methods are implemented for the establishment or loading of any master keys used by the HSM Tenant(s) and confirm that these controls prevent man-in- the-middle, pre-play, and replay attacks. These controls must include preventing such attacks by the HSM Service Provider itself. Methods must use acceptable algorithms and key lengths.

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

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

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

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

Removed p. 126

• 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 all components of the overall HSM Solution. The tester shall further confirm that a documented policy exists …

Removed p. 127

TL1.3 The tester shall examine a sample of documentation of physical and functional changes to devices, such as change control logs, to validate that procedures⎯ including the submission and sign-off processes⎯are followed.

Modified p. 127 → 110

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.

DTR G1 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 recertification 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.

Modified p. 127 → 110

The organization must utilize a documented and approved, secure change management system, such that all development is traceable and access restricted. All changes should be reviewed and approved prior to release. The ~~change control~~ procedures shall include the unique identification of all configuration items and their developer, including the device, its ~~parts•and~~ its firmware.

The organization must utilize a documented and approved, secure change management system, such that all development is traceable and access restricted. All changes should be reviewed and approved prior to release. The change-control procedures shall include the unique identification of all configuration items and their developer, including the device, its parts, and its firmware.

Modified p. 127 → 110

Note: Hardware and firmware version number identifiers may consist of a combination of fixed and variable alphanumeric characters, whereby a lowercase "x" is used by PCI to designate all variable fields. The "x" represents fields that the vendor can change at any time to denote a different device configuration. Options that cannot be a variable ~~character~~ include those that directly pertain to meeting security requirements.

Note: Hardware and firmware version number identifiers may consist of a combination of fixed and variable alphanumeric characters, whereby a lowercase "x" is used by PCI to designate all variable fields. The "x" represents fields that the vendor can change at any time to denote a different device configuration. Options that cannot be variable characters include those that directly pertain to meeting security requirements.

Modified p. 127 → 110

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

TG1.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 in DTR G11.

Modified p. 127 → 110

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

TG1.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. 128 → 111

~~TL1.4~~ The tester shall interview those responsible for the ~~change control~~ processes

•including engineers and programming staff, supervisory staff, technical management, etc.

TG1.4 The tester shall interview those responsible for the change-control processes

•including engineers and programming staff, supervisory staff, technical management, etc.

Modified p. 128 → 111

~~TL1.5~~ The tester shall validate that either:

TG1.5 The tester shall validate that either:

Modified p. 129 → 112

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.

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 it’s labeled⎯e.g., OS, EPROM code, DLL’s, parameter files, applications, kernel code, etc. 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 …

Modified p. 129 → 112

~~TL2.1~~ The tester shall examine details provided by the vendor to confirm that the documented process explicitly addresses how testing/auditing has been carried out to check for unauthorized and undocumented functions.

TG2.1 The tester shall examine details provided by the vendor to confirm that the documented process explicitly addresses how testing/auditing has been carried out to check for unauthorized and undocumented functions.

Modified p. 129 → 112

~~TL2.2~~ The tester shall detail any compiler settings used by the vendor in order to maximize the mitigation of known vulnerabilities. If no specific compiler settings are used, the tester shall detail how known vulnerabilities are mitigated.

TG2.2 The tester shall detail any compiler settings used by the vendor in order to maximize the mitigation of known vulnerabilities. If no specific compiler settings are used, the tester shall detail how known vulnerabilities are mitigated.

Modified p. 129 → 112

~~TL2.3~~ The tester shall detail any mitigation techniques used by the vendor to help prevent common exploits. The tester must state and justify any reliance placed on these ~~technique(s)~~ in minimizing testing. If no specific techniques are used, the tester shall detail how the common exploits are prevented.

TG2.3 The tester shall detail any mitigation techniques used by the vendor to help prevent common exploits. The tester must state and justify any reliance placed on these techniques in minimizing testing. If no specific techniques are used, the tester shall detail how the common exploits are prevented.

Modified p. 130 → 113

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

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

Modified p. 130 → 113

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

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

Modified p. 130 → 113

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

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

Modified p. 130 → 113

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

TG2.8 The tester shall confirm and describe, via documentation review, that the certification process requires that the code review and security testing be performed by a person who was not involved in the authorship of the device code.

Modified p. 130 → 113

~~TL2.9~~ 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.

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

Modified p. 130 → 113

~~TL2.10~~ The tester shall confirm and describe, via documentation review, that the certification process is designed to result in an auditable process that shows the code review and security testing have been performed and require sign-off by the person(s) performing the code review and security testing. The tester shall confirm that the process will show any problems noted during the code review and security testing.

TG2.10 The tester shall confirm and describe, via documentation review, that the certification process is designed to result in an auditable process that shows the code review and security testing have been performed and require sign-off by the person(s) performing the code review and security testing. The tester shall confirm that the process will show any problems noted during the code review and security testing.

Modified p. 130 → 113

~~TL2.11~~ The tester shall obtain, review, and summarize the firmware-verification audit results provided by the vendor for the version of firmware submitted for evaluation. The tester shall confirm that this shows that no problems were found during review of this firmware (or that any problems found have been addressed).

TG2.11 The tester shall obtain, review, and summarize the firmware-verification audit results provided by the vendor for the version of firmware submitted for evaluation. The tester shall confirm that this shows that no problems were found during review of this firmware (or that any problems found have been addressed).

Modified p. 130 → 113

~~TL2.12~~ The tester shall review previous firmware-verification audit reports provided by the vendor and summarize these reports and their findings. The tester shall ensure that the reports sampled include security problems found during the review and confirm that these problems have been addressed. If all audit reports reviewed indicate that no security problems have been found, the tester shall justify why it is possible that the firmware image is, and has always been, completely free of security defects.

TG2.12 The tester shall review previous firmware-verification audit reports provided by the vendor and summarize these reports and their findings. The tester shall ensure that the reports sampled include security problems found during the review and confirm that these problems have been addressed. If all audit reports reviewed indicate that no security problems have been found, the tester shall justify why it is possible that the firmware image is, and has always been, completely free of security defects.

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

Modified p. 132 → 115

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.

All certified firmware must be signed prior to distribution and signed using dual-control process, using cryptographic keys protected by a FIPS 140-3 Level 3 or higher cryptographic modules or a PCI- approved HSM. 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 …

Modified p. 132 → 115

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

TG3.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. 132 → 115

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

TG3.2 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail as applicable the dual-control or cryptographic authentication processes and procedures during manufacturing and describe how they show compliance to this requirement.

Modified p. 132 → 115

~~TL3.3~~ The tester shall examine a sample of documentation for firmware ~~authentication (i.e., signing)~~ and storage during manufacturing⎯including ~~change control~~ logs and ~~firmware validation~~ procedures⎯to ensure procedures are followed.

TG3.4 The tester shall examine a sample of documentation for firmware authentication⎯i.e., signing and storage during manufacturing⎯including change-control logs and firmware-validation procedures⎯to ensure procedures are followed.

Modified p. 132 → 115

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

TG3.5 The tester shall interview those responsible for the firmware control processes

•including engineers and programming staff, peer reviewers, supervisory staff, technical management, etc.

Modified p. 132 → 115

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

TG3.6 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. 132 → 115

~~TL3.6~~ The tester shall observe the firmware storage and validation process to ensure that only signed and ~~valid~~ firmware is used during manufacturing.

TG3.7 The tester shall observe the firmware storage and validation process to ensure that only signed and validated firmware is used during manufacturing.

Modified p. 133 → 116

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

TG4.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 DTR G1.

Modified p. 133 → 116

~~TL4.2~~ The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. This shall include:

TG4.2 The tester shall examine and cite any supporting documentation submitted by the vendor and describe how this shows compliance to this requirement. This shall include:

Modified p. 133 → 116

• Describing how the manufacturer verifies parts before using them in ~~manufacture.~~

• Describing how the manufacturer verifies parts before using them in manufacturing.

Modified p. 133 → 116

~~TL4.3~~ The tester shall interview those responsible for hardware component control processes

TG4.3 The tester shall interview those responsible for hardware component control processes

Modified p. 133 → 116

~~TL4.4~~ The tester shall examine the device parts listing and sample hardware components during manufacturing, to ensure the correct components are used.

TG4.4 The tester shall examine the device parts listing and sample hardware components used during manufacturing, to ensure the correct components are used.

Modified p. 133 → 116

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

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

Modified p. 134 → 117

All software (e.g., firmware) loaded into the device must be signed prior to ~~use;~~ and all software (e.g., firmware) needs to be controlled and protected during manufacturing. All software (e.g., firmware) must be validated before each use to prevent unauthorized modifications and/or substitutions.

All software (e.g., firmware) loaded into the device must be signed prior to use, and all software (e.g., firmware) needs to be controlled and protected during manufacturing. All software (e.g., firmware) must be validated before each use to prevent unauthorized modifications and/or substitutions.

Modified p. 134 → 117

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

TG5.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. 134 → 117

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

TG5.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. 134 → 117

~~TL5.3~~ 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.

TG5.3 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. 134 → 117

~~TL5.4~~ The tester shall interview those responsible for the software (e.g., firmware) control processes

TG5.4 The tester shall interview those responsible for the software (e.g., firmware) control processes

Modified p. 134 → 117

~~TL5.5~~ The tester shall observe the firmware storage and validation process to ensure that procedures are followed during manufacturing.

TG5.5 The tester shall observe the firmware storage and validation process to ensure that procedures are followed during manufacturing.

Modified p. 135 → 118

Completed devices and any of their components must be controlled and stored in tamper-evident packaging and/or stored in an ~~accessed controlled~~ area until shipped. The device or components must be checked prior to shipping to ensure the device has not been modified or tampered.

Completed devices and any of their components must be controlled and stored in tamper-evident packaging and/or stored in an accessed-controlled area until shipped. The device or components must be checked prior to shipping to ensure the device has not been modified or tampered.

Modified p. 135 → 118

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

TG6.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. 135 → 118

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

TG6.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. 135 → 118

~~TL6.3~~ The tester shall examine a sample of documentation for post-production storage

•including inventory logs, shipping documentation, and device-validation procedures

•to ensure procedures are followed.

TG6.3 The tester shall examine a sample of documentation for post-production storage•including:

Modified p. 135 → 118

~~TL6.4~~ The tester shall interview those responsible for the post-production control processes

TG6.4 The tester shall interview those responsible for the post-production control processes

Modified p. 135 → 118

~~TL6.5~~ The tester shall observe the device and component storage and validation process to ensure that procedures are followed subsequent to production.

TG6.5 The tester shall observe the device and component storage and validation process to ensure that procedures are followed subsequent to production.

Modified p. 135 → 118

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

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

Authentication by secret information is mandatory in HSM v4.

Modified p. 136 → 119

Dual control is not required if the device generates the secret information and never outputs ~~it, for example~~ if it generates a ~~public/private key~~ pair and never outputs the private key.

Dual control is not required if the device generates the secret information and never outputs it•for example, if it generates a public-/private-key pair and never outputs the private key.

Modified p. 136 → 119

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

TG7.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should detail that 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. 136 → 119

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

TG7.2 The tester shall examine, cite, and reference any supporting documentation submitted by the vendor. The documentation should detail that 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. 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. 136 → 119

~~TL7.3~~ The tester shall examine a sample of documentation for secret information

•including user documentation and device-validation procedures

•to ensure procedures are followed.

TG7.3 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. 136 → 119

~~TL7.4~~ The tester shall interview those responsible for the control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

TG7.4 The tester shall interview those responsible for the control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

Modified p. 136 → 119

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

TG7.5 The tester shall observe the device’s 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.

Modified p. 137 → 120

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

TG8.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. 137 → 120

~~TL8.2~~ 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.

TG8.2 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. 137 → 120

~~TL8.3~~ The tester shall interview those responsible for component control processes

•including engineers and line staff, supervisory staff, technical management, etc.

TG8.3 The tester shall interview those responsible for component control processes

•including engineers and line staff, supervisory staff, technical management, etc.

Modified p. 137 → 120

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

TG8.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. 137 → 120

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

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

Modified p. 138 → 121

Completed devices and any of their components must be controlled and stored in tamper-evident packaging and/or stored in an ~~accessed controlled~~ area until shipped. The device or components should be checked prior to shipping to ensure the device has not been modified or tampered.

Completed devices and any of their components must be controlled and stored in tamper-evident packaging and/or stored in an access-controlled area until shipped. The device or components should be checked prior to shipping to ensure the device has not been modified or tampered.

Modified p. 138 → 121

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

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

Modified p. 138 → 121

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

TG9.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. 138 → 121

~~TL9.3~~ 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.

TG9.3 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. 138 → 121

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

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

Modified p. 138 → 121

~~TL9.5~~ The tester shall observe the device repair, inspection, and post-inspection storage process to ensure that procedures are followed subsequent to production.

TG9.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. 138 → 121

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

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

The product shall be protected for at all points during the shipping process. Tamper-detection security features, instructions for receiving and inspection, and documentation covering suspected tampering must be provided and used.

Modified p. 139 → 125

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

• 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 for tamper evidence.

Modified p. 139 → 125

DTR M1 Shipping Tamper-Protection Documentation The device should be protected from unauthorized modification with tamper-detection security features, and customers shall be provided with documentation ~~(both shipped~~ with the product ~~and~~ available securely online) that provides instruction on validating the authenticity and integrity of the device.

DTR H1 Shipping Tamper-Protection Documentation The device should be protected from unauthorized modification with tamper-detection security features, and customers shall be provided with documentation (shipped with the product and/or available securely online) that provides instruction on validating the authenticity and integrity of the device.

Modified p. 139 → 125

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.

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 are compliant with this requirement.

Modified p. 139 → 125

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

TH1.1 The tester shall examine and cite any supporting documentation submitted by the vendor. The documentation should provide customers instruction on the 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 …

Modified p. 139 → 125

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

TH1.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. 140 → 126

~~TM1.4~~ The tester shall interview those responsible for the shipping control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

TH1.4 The tester shall interview those responsible for the shipping control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

Modified p. 140 → 126

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

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

Modified p. 141 → 127

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

TH2.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. 141 → 127

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

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

Modified p. 141 → 127

~~TM2.3~~ The tester shall interview those responsible for the shipping control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

TH2.3 The tester shall interview those responsible for the shipping control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

Modified p. 141 → 127

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

TH2.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. 141 → 127

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

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

Modified p. 142 → 128

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

TH3.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. The tester should describe how these show compliance to this requirement.

Modified p. 142 → 128

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

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

Modified p. 142 → 128

~~TM3.3~~ The tester shall interview those responsible for the shipping control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

TH3.3 The tester shall interview those responsible for the shipping control processes

•including engineers, software developers, line staff, supervisory staff, technical management, etc.

Modified p. 142 → 128

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

TH3.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. 142 → 128

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

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

Modified p. 143 → 129

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

TH4.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. 143 → 129

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

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

Modified p. 143 → 129

~~TM4.3~~ The tester shall interview those responsible for the initial key-loading facility

•including engineers and line staff, supervisory staff, technical management, etc.

TH4.3 The tester shall interview those responsible for the initial key-loading facility

•including engineers and line staff, supervisory staff, technical management, etc.

Modified p. 143 → 129

~~TM4.4~~ The tester shall observe the secure development component control procedures to ensure security measures are followed during the initial key loading.

TH4.4 The tester shall observe the secure development component control procedures to ensure security measures are followed during the initial key loading.

Modified p. 144 → 130

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

TH5.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. 144 → 130

~~TM5.2~~ The tester shall examine a sample of documentation, including user documentation, and component validation procedures to ensure procedures are followed.

TH5.2 The tester shall examine a sample of documentation, including user documentation, and component validation procedures to ensure procedures are followed.

Modified p. 144 → 130

~~TM5.3~~ The tester shall interview those responsible for the initial key-loading facility

•including engineers and line staff, supervisory staff, technical management, etc.

TH5.3 The tester shall interview those responsible for the initial key-loading facility

•including engineers and line staff, supervisory staff, technical management, etc.

Modified p. 144 → 130

~~TM5.4~~ The tester shall observe the initial key-loading procedures to ensure the authenticity of the device’s security-related components is verified.

TH5.4 The tester shall observe the initial key-loading procedures to ensure that the authenticity of the device’s security-related components is verified.

Modified p. 145 → 131

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

TH6.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. 145 → 131

~~TM6.2~~ The tester shall interview those responsible for the initial key-loading facility

•including engineers and line staff, supervisory staff, technical management, etc.

TH6.2 The tester shall interview those responsible for the initial key-loading facility

•including engineers and line staff, supervisory staff, technical management, etc.

Modified p. 145 → 131

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

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

Modified p. 146 → 132

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

TH7.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 G1 are used in compliance with this requirement.

Modified p. 146 → 132

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

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

Modified p. 146 → 132

~~TM7.3~~ The tester shall observe the manufacturing process to ensure the visible identifier is affixed to each device.

TH7.3 The tester shall observe the manufacturing process to ensure the visible identifier is affixed to each device.

Modified p. 146 → 132

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

TH7.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 as required in G1.

Modified p. 147 → 133

• ~~Loss or theft~~ The ~~operational management~~ manual provides instructions and information concerning the identification, use, repair, updates, and configuration of hardware and firmware components of the device. This manual is in addition to user and ~~application operation~~ and configuration manuals.

• Device validation The operational-management manual provides instructions and information concerning the identification, use, repair, updates, and configuration of hardware and firmware components of the device. This manual is in addition to the user and application-operation and configuration manuals.

Modified p. 147 → 133

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

TH8.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. 147 → 133

~~TM8.2~~ The tester shall interview those responsible for maintaining the ~~operation management~~ manual

•including engineers and software developers, supervisory staff, technical management, etc.

TH8.2 The tester shall interview those responsible for maintaining the operational-management manual

•including engineers and software developers, supervisory staff, technical management, etc.

Modified p. 147 → 133

~~TM8.3~~ The tester shall examine a sample of the ~~operations management~~ manual to ensure procedures are followed and recorded.

TH8.3 The tester shall examine a sample of the operational-management manual to ensure procedures are followed and recorded.

Modified p. 148 → 134

d) Equipment ~~required~~ such as instruments, components, IT ~~hardware~~ and software required for the

d) Equipment required, such as instruments, components, IT hardware, and software required for the analysis;

Modified p. 148 → 134

d) Equipment ~~required~~ like instruments, components, IT hardware, software required for the

d) Equipment required, like instruments, components, IT hardware, and software required for the

Modified p. 149 → 135

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:

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 operating systems and Internet protocols). Identified levels are as follows:

Modified p. 149 → 135

a) Layman is a person without professional or specialized knowledge in a particular subject. They are unknowledgeable compared to experts, proficient, or skilled persons, with no particular ~~expertise~~ but capable of implementing simple attack steps, or capable of implementing more complex attack steps under direction. For the purpose of exploitation, they can implement an attack based on a script or a written procedure, without requiring any particular skill.

a) Layman is a person without professional or specialized knowledge in a particular subject. They are unknowledgeable compared to experts, proficient, or skilled persons, with no particular expertise, but capable of implementing simple attack steps, or capable of implementing more complex attack steps under direction. For the purpose of exploitation, they can implement an attack based on a script or a written procedure, without requiring any particular skill.

Modified p. 150 → 136

Access to the HSM is also an important factor. It is assumed here that the HSM would be purchased or otherwise obtained by the attacker and ~~that beside~~ other ~~factors~~ there is not any time limit in analyzing or modifying the HSM. Differences are defined in the status and functionality of the device to be analyzed/tested.

Access to the HSM is also an important factor. It is assumed here that the HSM would be purchased or otherwise obtained by the attacker and that, besides other factors, there is not any time limit in analyzing or modifying the HSM. Differences are defined in the status and functionality of the device to be analyzed/tested.

Modified p. 150 → 136

b) Functional samples without working keys might be used for the logical and electrical behavior of the ~~device~~ but are not loaded with working keys and are therefore not functional within a payment network or with real payment cards. Such devices might be regularly purchased. Please note that these also include devices fitted with test or dummy keys.

b) Functional samples without working keys might be used for the logical and electrical behavior of the device, but are not loaded with working keys and are therefore not functional within a payment network or with real payment cards. Such devices might be regularly purchased. Please note that these also include devices fitted with test or dummy keys.

Modified p. 150 → 136

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.

Table A-1: Multiple Samples Factors Number of Devices Factor Equipment refers to the equipment that is required to identify or exploit a vulnerability. See Appendix B for details of equipment classification.

Modified p. 150 → 137

c) Bespoke equipment is not readily available to the public, as it might need to be specially produced (for example, very sophisticated software), or because the equipment is so specialized that its distribution is controlled (for example, X-ray equipment), possibly even restricted. Bespoke equipment that can be rented must be treated as specialized equipment. Software that has been developed during the identification phase is considered as bespoke equipment and must not additionally be considered in the exploitation phase.

c) Bespoke equipment is not readily available to the public, as it might need to be specially produced (for example, very sophisticated software), or because the equipment is so specialized that its distribution is controlled (for example, X-ray equipment), possibly even restricted. Bespoke equipment that can be rented must be treated as specialized equipment. Software that has been developed during the identification phase is considered bespoke equipment and must not additionally be considered in the exploitation phase.

Removed p. 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. 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, will result in the initial exploitation having a lower attack-potential value than the actual subsequent exploitations. Therefore, 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 …

Modified p. 151 → 137

d) Chip-level attack equipment, necessary to implement chip-level attacks, is generally not widely available on the ~~market~~ and its access is restricted. It is also very ~~expensive,~~ and therefore is considered as a category on its own. Only the following equipment ~~belong~~ to this category:

d) Chip-level attack equipment, which is necessary to implement chip-level attacks, is generally not widely available on the market, and its access is restricted. It is also very expensive and therefore is considered a category on its own. Only the following equipment belongs to this category:

Modified p. 151 → 137

a) Standard parts are readily available to the attacker, either by purchasing them from a supply store or by ~~re-using~~ parts from a mechanical sample of the same device.

a) Standard parts are readily available to the attacker, either by purchasing them from a supply store or by reusing parts from a mechanical sample of the same device.

Modified p. 151 → 137

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.

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 a delivery time or a certain minimum component count for purchase.

Modified p. 152 → 138

The following items in calculation are typically subject to reuse in further exploitation phases:

The following items in the calculation are typically subject to reuse in further exploitation phases:

Modified p. 152 → 138

For a given ~~attack~~ it might be necessary to make several passes through the table for different attack scenarios (for example, trading off expertise for time or equipment). The lowest value obtained for these passes should be retained. In the case of a vulnerability that has been identified and is in the public domain, the identifying values should be selected for an attacker to uncover that attack scenario in the public domain, rather than to initially identify it.

For a given attack, it might be necessary to make several passes through the table for different attack scenarios (for example, trading off expertise for time or equipment). The lowest value obtained for these passes should be retained. In the case of a vulnerability that has been identified and is in the public domain, the identifying values should be selected for an attacker to uncover that attack scenario in the public domain, rather than to initially identify it.

Modified p. 153 → 139

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 parts required None 0 0 Standard 1 1 Specialized 3 3 Bespoke 5 5 An approach such as this cannot ~~take~~ account of every circumstance or ~~factor~~ but should give a better indication of the attack potential. Other …

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 parts required None 0 0 Standard 1 1 Specialized 3 3 Bespoke 5 5 An approach such as this cannot account for every circumstance or factor, but should give a better indication of the attack potential. Other factors, …

Modified p. 153 → 139

First Attack Example The attack aims to penetrate through the casing of the HSM to expose and bypass casing switches. Once bypassed, the casing is removed and an internal mesh covering the HSM processing circuitry is abraded and shorted out, allowing for access to the bus carrying ~~clear-text~~ cryptographic keys.

First Attack Example The attack aims to penetrate through the casing of the HSM to expose and bypass casing switches. Once bypassed, the casing is removed and an internal mesh covering the HSM processing circuitry is abraded and shorted out, allowing for access to the bus carrying cleartext cryptographic keys.

Modified p. 154 → 140

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

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

Modified p. 154 → 140

Expertise Equipment Knowledge Parts Samples Time needed Expert Specialized Public None 2 functional 200 hours 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 Specialized Public None 2 functional 200 hours Exploitation The attacker uses a functional sample with keys and implements the attack. Several steps are necessary to perform the attack:

Modified p. 155 → 141

2. Once inside, the attack needs to reach sensitive signals⎯e.g., ~~clear-text cryptographic key~~ signals⎯located behind tamper meshes within the device. The meshes need to be bypassed and disabled such that sufficient access is obtained to the internal memory subsystems.

2. Once inside, the attack needs to reach sensitive signals⎯e.g., cleartext cryptographic-key signals⎯located behind tamper meshes within the device. The meshes need to be bypassed and disabled such that sufficient access is obtained to the internal memory subsystems.

Modified p. 155 → 141

Expertise Equipment Knowledge Parts Samples Time needed Expert Standard (reused) Public None 1 working with ~~keys 4 hours~~

Expertise Equipment Knowledge Parts Samples Time needed Expert Standard (reused) Public None 1 working with

Modified p. 155 → 141

3. Once the previous step is successfully achieved, the attacker will now attach the specialized equipment used to capture the cryptographic tamper key as the system is booted, and test the device. With the tamper key, no further use of the HSM is ~~required~~ and other keys can be retrieved and decrypted from the installed environment as required (or as previously captured).

3. Once the previous step is successfully achieved, the attacker will now attach the specialized equipment used to capture the cryptographic tamper key as the system is booted, and test the device. With the tamper key, no further use of the HSM is required, and other keys can be retrieved and decrypted from the installed environment as required (or as previously captured).

Modified p. 155 → 141

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:

Expertise Equipment Knowledge Parts Samples Time needed Proficient Specialized (reused) Public None 1 working with As a summary for the exploitation phase, the following would apply:

Modified p. 156 → 141

• A function of the HSM is ~~used~~ which requires PIN translations using the cryptographic key under attack;

• A function of the HSM is used, which requires PIN translations using the cryptographic key under attack;

Modified p. 156 → 141

• The data used for DPA can be acquired at an external interface of the HSM module, e.g., the HSM ~~needs~~ not be further physically attacked to get the required test data; and that

• The data used for DPA can be acquired at an external interface of the HSM module, e.g., the HSM need not be further physically attacked to get the required test data; and that

Modified p. 156 → 142

2. Develop the attack ~~set-up~~ including the control to run the HSM in an automated way. Since a large number of PIN translations are required. This is bespoke equipment, developed specially for this attack, which will be reused at Identification time.

2. Develop the attack setup, including the control to run the HSM in an automated way. Since a large number of PIN translations are required. This is bespoke equipment, developed specially for this attack, which will be reused at Identification time.

Modified p. 156 → 142

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.

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-life environment, it must be possible to run the device offline with a simulated host.

Modified p. 157 → 143

• Screwdrivers of any type

•including custom tips, as they can be cut from another type of screwdriver ~~simply~~ enough if not able to be purchased

• Screwdrivers of any type

•including custom tips, as they can be cut from another type of screwdriver easily enough if not able to be purchased

Modified p. 157 → 143

• Simple side-channel software (capable of performing time-displacement alignment, correlation analysis, basic time-frequency ~~conversion~~ and filtering, etc., and having a basic functioning user interface)

• Simple side-channel software (capable of performing time-displacement alignment, correlation analysis, basic time-frequency conversion, and filtering, etc., and having a basic functioning user interface)

Modified p. 157 → 143

• Acid of most types used for attacks, including for etching of chips

• Acid of most types used for attacks, including for the etching of chips

Modified p. 157 → 143

• Soldering irons of any type, including ~~with~~ heated rework tweezers or temperature-controlled hot-air guns for SMT (re)work

• Soldering irons of any type, including heated rework tweezers or temperature-controlled hot-air guns for SMT (re)work

Modified p. 157 → 143

• Environmental chamber or equivalent heating/cooling tools (approximate range ~~-80 C~~ to ~~200 C)~~

• Environmental chamber or equivalent heating/cooling tools (approximate range -80°C to 200°C)

Modified p. 157 → 143

• Current probes up to ~~1Ghz~~

• Current probes up to 1GHz

Modified p. 157 → 143

• Simple EM probes (for ~~example~~ wire coils, ~~antennas)~~

• Simple EM probes (for example, wire coils, antennas, etc.)

Modified p. 158 → 144

Specialized ~~equipment~~ “Rule of thumb” followed: If it can be obtained for between approximately US$1,000 and US$50,000, it falls under this category. Specialized equipment would be expected for any side-channel work on a modern CPU (for example, 32/64 bits, clock frequency ~~>100Mhz)~~ or hardware implementation. The values stated below are indicative only.

Specialized Equipment “Rule of thumb” followed: If it can be obtained for between approximately US$1,000 and US$50,000, it falls under this category. Specialized equipment would be expected for any side-channel work on a modern CPU (for example, 32/64 bits, clock frequency >100MHz) or hardware implementation. The values stated below are indicative only.

Modified p. 158 → 144

• Laser abrading/cutting Bespoke ~~equipment~~ “Rule of thumb” followed: If it cannot be obtained for less than US$50000 or extensive customization is required for such an attack, it falls under this category. Bespoke equipment is expected to be required only in very rare circumstances.

• Laser abrading/cutting Bespoke Equipment “Rule of thumb” followed: If it cannot be obtained for less than US$50000 or extensive customization is required for such an attack, it falls under this category. Bespoke equipment is expected to be required only in very rare circumstances.

Modified p. 158 → 144

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

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

Modified p. 160 → 146

[7] For the Approximate Entropy (ApEn) test, SP800-22r1a Section 2.12.7 requires the block length to be less than [log2 n] - 5. Other analysis [Hill 2004] has shown that for n=1,000,000, block lengths greater than 8 can cause failures more often than expected for ~~large scale~~ testing.

[7] For the Approximate Entropy (ApEn) test, SP800-22r1a Section 2.12.7 requires the block length to be less than [log2 n] - 5. Other analysis [Hill 2004] has shown that for n=1,000,000, block lengths greater than 8 can cause failures more often than expected for large-scale testing.

Modified p. 162 → 148

• Hash functions: Only algorithms from the SHA2 and SHA3 family are allowed, with output size ~~> 255.~~

• Hash functions: Only algorithms from the SHA2 and SHA3 family are allowed, with output size >255.

Modified p. 162 → 148

• Symmetric-key algorithms used for encryption and decryption: AES must be used, with key size ~~>= 128 bits~~ or TDES with keys size ~~>= 112 bits.~~

• Symmetric-key algorithms used for encryption and decryption: AES must be used, with key size >=128 bits; or where TDES is used in addition to AES, TDES keys must use keys with size >=112 bits. TDES keys of any size must not be used for device security purposes (such as firmware authenticity, device-level key storage, etc.). This does not apply to the tamper/storage key if it is the same as the HSM MFK/LMK. The MFK/LMK must be either an AES …

Modified p. 162 → 148

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

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

Modified p. 162 → 148

• Signature algorithms: ~~DSA,~~ RSA (with PKCS1-v1.5 or PSS) and ~~ECDSA~~ with key sizes specified below.

• Signature algorithms: RSA (with PKCS1-v1.5 or PSS) and ECDSA, ECSDSA and EdDSA with key sizes specified below. DSA is no longer allowed for use in signature generation. It continues to be allowed for legacy use in signature verification.

Modified p. 162 → 148

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

• Approved key-establishment schemes are described in NIST SP800-56A (ECC/FFC 2-based key agreement) and NIST SP800-56B (IFC-based key agreement).

Modified p. 162 → 148

SHA-2 or higher is recommended for other usages, but SHA-1 may be used in conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key-derivation functions (i.e., ~~KDFs)~~ and ~~random number~~ generation. Where applicable, appropriate key-length minimums as delineated in the Derived Test Requirements are also required.

SHA-2 or higher is recommended for other usages, but SHA-1 may be used in conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key-derivation functions (i.e., KDFs), for RSA OAEP key wrapping and for random-number generation. Where applicable, appropriate key-length minimums as delineated in the Derived Test Requirements are also required.

Removed p. 163

• 3072 256 3072/256 128

• 7680 384 7680/384 192

• 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. 163 → 150

• Each private key must be statistically unique, unpredictable, and created using an approved ~~random number~~ generator as described in this document.

• Each private key must be statistically unique, unpredictable, and created using an approved random-number generator as described in this document.

Modified p. 163 → 150

• Entities must authenticate the FFC or ECC public keys using ~~DSA,~~ ECDSA, a certificate, or a MAC. (If using a MAC, see ISO 16609

• Entities must authenticate the FFC or ECC public keys using ECDSA, a certificate, or a MAC. (If using a MAC, see ISO 16609

Modified p. 164 → 152

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. 164 → 152

This appendix defines baseline expectations for PTS-recognized Laboratory competencies on side- channel analysis. The PCI PTS standard assigns the highest rating level for attack calculations for the protection of PIN-security-related keys; side-channel analysis is often a ~~feasible~~ method to compromise these assets. This appendix shall be used to provide consistency so that for all evaluations, all laboratories assess the effort of the side-channel component of an attack on any device similarly. The summary information below outlines expectations of PTS-recognized laboratories’ …

This appendix defines baseline expectations for PTS-recognized Laboratory competencies on side- channel analysis. The PCI PTS standard assigns the highest rating level for attack calculations for the protection of PIN-security-related keys; side-channel analysis is often a practical method to compromise these assets. This appendix shall be used to provide consistency so that for all evaluations, all laboratories assess the effort of the side-channel component of an attack on any device similarly. The summary information below outlines expectations of PTS-recognized laboratories’ …

Modified p. 164 → 152

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.

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, distinct from any physical penetration/modification.

Modified p. 165 → 153

Laboratories’ SCA resources must be maintained at levels consistent with industry “state-of-the-art,” capabilities, including (but not restricted to): cryptanalysis of all relevant algorithms, higher-order DPA, and template attacks. Laboratories’ resources must be improved regularly to reflect updates to the PCI PTS ~~program, for example~~ as version changes occur and/or as new attacks are published. Labs must have available a sufficient volume of personnel and equipment resources to be capable of performing SCA at any capacity of evaluations the lab undertakes.

Laboratories’ SCA resources must be maintained at levels consistent with industry “state-of-the-art,” capabilities, including (but not restricted to): cryptanalysis of all relevant algorithms, higher-order DPA, and template attacks. Laboratories’ resources must be improved regularly to reflect updates to the PCI PTS program•for example, as version changes occur and/or as new attacks are published. Labs must have available a sufficient volume of personnel and equipment resources to be capable of performing SCA at any capacity of evaluations the lab undertakes.

Modified p. 165 → 153

Minimum ~~expectations~~ for ~~evaluators~~

Minimum Expectations for Evaluators

Modified p. 165 → 153

• Personnel performing SCA have a proven track record of being able to defeat devices, including successful removal of SCA countermeasures to extract unknown cryptographic keys.

• Personnel performing SCA have a proven track record of being able to defeat devices, including the successful removal of SCA countermeasures to extract unknown cryptographic keys.

Modified p. 165 → 153

PCI SSC expects laboratory hardware equipment and software tools to be fit for purpose for performing SCA. These resources must be sufficiently well developed to enable testers to determine devices’ strengths and/or vulnerabilities, and to be able produce evidence of this. The following list outlines minimum expectations for test resources.

PCI SSC expects laboratory hardware equipment and software tools to be fit for purpose for performing SCA. These resources must be sufficiently well developed to enable testers to determine devices’ strengths and/or vulnerabilities, and to be able to produce evidence of this. The following list outlines minimum expectations for test resources.

Modified p. 165 → 153

Minimum ~~expectations~~ for ~~test resources~~

Minimum Expectations for Test Resources

Modified p. 166 → 154

Principles and ~~methods~~ for ~~testing~~

Principles and Methods for Testing

Modified p. 166 → 154

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

• Notwithstanding physical protections (such as those validated by DTR A1), approved devices must not contain cryptographic implementations that, under analysis, can be straightforwardly compromised through SCA.

Modified p. 166 → 154

Factors ~~related~~ to ~~testing expectations~~

• ~~examples~~

Factors Related to Testing Expectations

• Examples

Modified p. 166 → 154

• Signal-processing capabilities to identify and overcome obstacles to ~~SCA~~ such as timing variation or other characteristics of recorded or derived waveforms, including deliberate countermeasures or other noise that may obscure information. *

• Signal-processing capabilities to identify and overcome obstacles to SCA, such as timing variation or other characteristics of recorded or derived waveforms, including deliberate countermeasures or other noise that may obscure information.*

Modified p. 167 → 155

* Examples of specific attributes of SCA toolsets satisfying these expectations are listed below Critical ~~steps~~ in SCA ~~scenarios~~ Even in straightforward scenarios

•for example, in the absence of SCA countermeasures

•several fundamental activities are necessary for SCA to succeed. Critical steps that should occur in most SCA scenarios are identified below.

* Examples of specific attributes of SCA toolsets satisfying these expectations are listed below Critical Steps in SCA Scenarios Even in straightforward scenarios

•for example, in the absence of SCA countermeasures

•several fundamental activities are necessary for SCA to succeed. Critical steps that should occur in most SCA scenarios are identified below.

Modified p. 167 → 155

• 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. 167 → 155

• Acquiring stable (well-triggered) recordings at an optimum sampling rate for a particular analysis task: The sampling rate should not be too low as to introduce aliasing, particularly if recording waveforms to input to attacks such as DPA/DEMA. Acquisitions should be set up to optimize SNR, amplitude, and time resolution. The evaluation should aim for well-timed, low-noise, high-resolution acquisitions appropriate to a particular task and commensurate to resources and techniques available to expert attackers.

• Acquiring stable (well-triggered) recordings at an optimum sampling rate for a particular analysis task: The sampling rate should not be too low as to introduce aliasing, particularly if recording waveforms to input to attacks such as DPA/DEMA. Acquisitions should be set up to optimize SNR, amplitude, and time resolution. The evaluation should aim for well-timed, low-noise, high-resolution acquisitions appropriate to a particular task and commensurate with resources and techniques available to expert attackers.

Modified p. 167 → 155

• Characterizing side-channel behavior through approaches such as SPA/SEMA: A critical goal of this phase is to identify events in the algorithm under attack, to localize sensitive operations. Specific checks are necessary for certain test methods

•for example, for ~~EMA~~ the relative location of the EM probe to the device’s components is a ~~highly sensitive~~ variable factor. In many ~~situations~~ no useful features can be determined upon first inspection. In this case, it is necessary to explore either whether there are …

• Characterizing side-channel behavior through approaches such as SPA/SEMA: A critical goal of this phase is to identify events in the algorithm under attack, to localize sensitive operations. Specific checks are necessary for certain test methods

•for example, for EMA, the relative location of the EM probe to the device’s components is a highly-sensitive variable factor. In many situations, no useful features can be determined upon first inspection. In this case, it is necessary to explore either whether there are obstructions …

Modified p. 168 → 156

• Correlation: Computations such as (but not restricted to) the Pearson product-moment coefficient are a crucial element in a test’s capability to achieve alignment. Effective correlation capabilities are also crucial for identification of leakage that may often be ~~obscured, for example~~ to identify ~~security- significant~~ patterns in waveforms, test a device’s relative susceptibility to leak ~~internally~~ processed data, localize sensitive operations for making well-targeted attacks, launch and develop attacks to infer secret data values. The evaluation should use correlation-analysis techniques …

• Correlation: Computations such as (but not restricted to) the Pearson product-moment coefficient are a crucial element in a test’s capability to achieve alignment. Effective correlation capabilities are also crucial for identification of leakage that may often be obscured

•for example, to identify security-significant patterns in waveforms, test a device’s relative susceptibility to leak internally- processed data, localize sensitive operations for making well-targeted attacks, and launch and develop attacks to infer secret data values. The evaluation should use correlation-analysis techniques equivalent …

Modified p. 168 → 156

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.

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.

Modified p. 168 → 156

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

Modified p. 168 → 156

• 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. 169 → 157

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

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

Modified p. 169 → 157

• Validation: It is necessary for evaluations to check that critical steps performed in tests have the potential to succeed. It is often difficult to distinguish between a device’s apparently robust resistance to attacks versus results deriving from a flawed or naive testing approach. For example, the absence of significant correlation leakage may be due to several situations that produce similar outcomes: errors in correlation calculations, bugs in analysis tools, inappropriate choice of analysis parameters, poor alignment, under-sampling or poor …

Modified p. 169 → 157

Testing ~~rationale~~ and ~~reporting~~ The outline information above defines many important aspects of testing. This should not be interpreted as an exhaustive list or as a definitive formula. PCI SSC expects SCA to be ~~well targeted;~~ that is, focused analysis considering the device’s characteristics and making best use of adequate evaluation resources. It is not expected that all of these examples of techniques should be applied in any particular evaluation. More exactly, evaluations should demonstrably produce results deriving from well-balanced …

Testing Rationale and Reporting The outline information above defines many important aspects of testing. This should not be interpreted as an exhaustive list or as a definitive formula. PCI SSC expects SCA to be well-targeted; that is, focused analysis considering the device’s characteristics and making best use of adequate evaluation resources. It is not expected that all of these examples of techniques should be applied in any particular evaluation. More exactly, evaluations should demonstrably produce results deriving from well-balanced decisions …

Modified p. 169 → 157

In some ~~situations~~ it is likely that testing from one evaluation can be reused straightforwardly in another evaluation. This situation occurs commonly when two devices having similar characteristics are evaluated by the same laboratory in parallel or in close succession. Other situations exist where SCA-test reuse, or partial reuse, is appropriate, including reuse of third-party testing. PCI SSC encourages optimized reuse of SCA by incrementally extending tests on similar devices evaluated sequentially. In these cases, enhancements and improvements in each …

In some situations, it is likely that testing from one evaluation can be reused straightforwardly in another evaluation. This situation occurs commonly when two devices having similar characteristics are evaluated by the same laboratory in parallel or in close succession. Other situations exist where SCA-test reuse, or partial reuse, is appropriate, including reuse of third-party testing. PCI SSC encourages optimized reuse of SCA by incrementally extending tests on similar devices evaluated sequentially. In these cases, enhancements and improvements in each …

Modified p. 169 → 157

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 …

The outcome for an evaluation’s SCA testing is to either defeat the device by 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 …

Modified p. 170 → 158

• Presentation of ~~results~~ including details of the testing performed and the device’s behavior under test.

• Presentation of results, including details of the testing performed and the device’s behavior under test.

Modified p. 170 → 158

Overall ~~scope~~ of SCA ~~testing~~ Generally, all the following secret and private keys, and related algorithms, are to be considered in scope of SCA testing:

Overall Scope of SCA Testing Generally, all the following secret and private keys, and related algorithms, are to be considered in scope of SCA testing:

Modified p. 170 → 158

Determining ~~test applicability~~ Valid statements of compliance cannot be made based on documentation/source code alone; applied testing is needed. Therefore, in principle, all algorithms used for protecting the assets listed above must be analyzed using SCA to some extent. At a minimum, this means recording the algorithms’ side-channel profiles and validating that the profiles agree with the algorithms’ expected characteristics.

Determining Test Applicability Valid statements of compliance cannot be made based on documentation/source code alone; applied testing is needed. Therefore, in principle, all algorithms used for protecting the assets listed above must be analyzed using SCA to some extent. At a minimum, this means recording the algorithms’ side-channel profiles and validating that the profiles agree with the algorithms’ expected characteristics.

Modified p. 170 → 158

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 practical 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. 170 → 158

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 …

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 …

Removed p. 171

A good test may discover total, partial, or zero key leakage, feasible in a field attack scenario, and/or feasible in the white-box context of the evaluation. In situations where a feasible attack is known to be capable of exposing the key, the evaluation shall explain definitively the effort needed to extract the key and how compliance is assessed considering obstacles to key-leakage attacks. In assessing this, the evaluation must consider and justify how any degree of key leakage is acceptable considering that successful attacks may require a lower degree of effort than the effort discovered through testing.

Modified p. 171 → 159

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 …

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., v4.x work can be reused if appropriate as part of a v5.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 …

Modified p. 171 → 159

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 transferability of results, the following points have to be considered:

Reusing Results Tests identifying little or no correlation and/or algorithmic structure are generally insufficient for reuse. Since multiple devices commonly use the 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 transferability of results, the following points have to be considered:

Modified p. 171 → 159

• The measurement setup of the reused analysis has to be described in a way that it can be justified that this setup also applies ~~for~~ the device under evaluation.

• The measurement setup of the reused analysis has to be described in a way that it can be justified that this setup also applies to the device under evaluation.

Modified p. 171 → 159

• If results from third parties are reused, these third parties have to be approved PCI-labs. It is mandatory that the reports, ~~respectively~~ the SCA part of the reports, are provided to the evaluation lab that wants to reuse the results.

• If results from third parties are reused, these third parties have to be approved PCI-labs. It is mandatory that the reports, respectively, the SCA part of the reports, are provided to the evaluation lab that wants to reuse the results.

Modified p. 171 → 159

• It has to be justified that the results remain valid. For example, no new attacks or measurement techniques are known ~~which~~ could impact on compliance.

• It has to be justified that the results remain valid. For example, no new attacks or measurement techniques are known that could impact compliance.

Modified p. 172 → 160

• Automation and control for x-y-z positioning and ~~scanning~~ and configuration where EMA is being investigated.

• Automation and control for x-y-z positioning and scanning, and configuration where EMA is being investigated.

Modified p. 172 → 160

• Scripting capabilities for waveforms’ acquisition, analysis, processing, cryptanalysis, including factors such as command/response I/O, storage, and data editing.

• Scripting capabilities for waveforms’ acquisition, analysis, processing, and cryptanalysis, including factors such as command/response I/O, storage, and data editing.

Modified p. 172 → 160

• Alignment functions capable of adapting/modifying waveforms in situations where straightforward matching and displacement is ineffective.

• Alignment functions capable of adapting/modifying waveforms in situations where straightforward matching and displacement are ineffective.

Modified p. 172 → 160

• Multiple cryptanalysis ~~libraries~~ such as first-order and higher-order DPA time-series sets and spectra ~~sets, applicable~~ to various algorithms used by evaluated devices, including configurable parameters to model different selection functions and discriminants, and capable of producing, analyzing, and graphing results.

• Multiple cryptanalysis libraries, such as first-order and higher-order DPA time-series sets and spectra sets

•applicable to various algorithms used by evaluated devices, including configurable parameters to model different selection functions and discriminants, and capable of producing, analyzing, and graphing results.

Modified p. 172 → 160

• Waveform and spectrum filters capable of calculating and plotting statistical analysis of data set, such as variance, standard deviation, average, absolute or values, etc.

• Waveform and spectrum filters capable of calculating and plotting statistical analysis of a data set, such as variance, standard deviation, average, absolute values, etc.

Modified p. 172 → 160

• Ability for the user to output information, including graphical information, of sufficient detail and quality to demonstrate analysis findings, for ~~example~~ in evaluation test reports.

• Ability for the user to output information, including graphical information, of sufficient detail and quality to demonstrate analysis findings, for example, in evaluation test reports.

Modified p. 174 → 162

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

It is therefore expected that the laboratory will generate an Asset Flow Diagram or Diagrams for the device.

Modified p. 174 → 162

The PCI HSM criteria defines various assets with corresponding protection requirements. Assets are defined by data and which kind of access it shall be protected against. Integrity means that any modification to the asset, whether spurious or induced, shall prohibit its being processed any longer. Confidentiality means that ~~clear text~~ of the data must not be disclosed. In Table F1 below, four Security Domains are defined from higher-protection requirements to lesser requirements:

The PCI HSM criteria defines various assets with corresponding protection requirements. Assets are defined by data and which kind of access it shall be protected against. Integrity means that any modification to the asset, whether spurious or induced, shall prohibit its being processed any longer. Confidentiality means that cleartext of the data must not be disclosed. In Table F-1 below, four Security Domains are defined from higher-protection requirements to lesser requirements:

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

Modified p. 175 → 163

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.

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.

Modified p. 175 → 163

Protection Data • This class covers all other transaction data⎯e.g., ~~PAN⎯ The~~ DTRs protect these assets at 20 points or less.

Protection Data This class covers all other transaction data⎯e.g., PAN⎯The DTRs protect these assets at 20 points or less.

Modified p. 175 → 163

For example, it is valid to store keys in a domain of lesser security⎯if the keys are encrypted and MAC’d, the MAC contains the key name, and the keys and algorithms used for encryption and MAC are adequately strong. The modules and components performing the cryptography and processing the validated or ~~clear-text~~ assets necessarily belong to the Key domain. This represents the idea of firmware in previous PCI HSM requirements.

For example, it is valid to store keys in a domain of lesser security⎯if the keys are encrypted and MAC’d, the MAC contains the key name, and the keys and algorithms used for encryption and MAC are adequately strong. The modules and components performing the cryptography and processing the validated or cleartext assets necessarily belong to the Key domain. This represents the idea of firmware in previous PCI HSM requirements.

Modified p. 175 → 163

Asset data that is properly protected by encryption and/or validation ~~token,~~ will be called an “asset container” in the remainder of this appendix.

Asset data that is properly protected by encryption and/or validation token will be called an “asset container” in the remainder of this appendix.

Modified p. 176 → 164

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 …

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 …

Modified p. 176 → 164

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 place cannot affect processing in another place. There are three established methods to segregate process spaces:

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 place cannot affect processing in another place. There are three established methods to segregate process spaces:

Modified p. 176 → 164

Standard concepts comprise ~~separated~~ processors or ~~CPU~~ with memory management and execution modes of graded privileges. The proper configuration of the segregation hardware may not be overly simple, but in ~~general~~ it should be ~~feasible~~ to verify its effectiveness.

Standard concepts comprise separate processors or CPUs with memory management and execution modes of graded privileges. The proper configuration of the segregation hardware may not be overly simple, but in general, it should be practical to verify its effectiveness.

Modified p. 176 → 164

2. Segregation of ~~process~~ by simulation leads to a virtual hardware support. Standard concepts are interpreted programs like Java. Since such solutions often allow calls to native ~~libraries, i.e.,~~ which are not interpreted, and the interpreter itself may be quite ~~complex, in general~~ it is much harder to verify that such segregation is actually effective.

2. Segregation of processes by simulation leads to virtual hardware support. Standard concepts are interpreted in programs like Java. Since such solutions often allow calls to native libraries

•i.e., which are not interpreted, and the interpreter itself may be quite complex

•in general, it is much harder to verify that such segregation is actually effective.

Modified p. 176 → 164

Obviously, this implies that any loaders or managers for process spaces are effectively executed in the same process space as their children. ~~Eventually~~ any initial boot loader is the parent of all process spaces on the same hardware.

Obviously, this implies that any loaders or managers for process spaces are effectively executed in the same process space as their children. Eventually, any initial boot loader is the parent of all process spaces on the same hardware.

Removed p. 177

A description of this analysis should be in the hardware architecture delivered by the vendor. It should make clear on implementation level where the assets are produced, transferred, stored, and destroyed, giving a focused design description.

Modified p. 177 → 165

A description of this analysis should be in the software architecture delivered by the vendor. It should make clear on the implementation level where the assets are produced, transferred, stored, and destroyed, giving a focused design description. It should furthermore provide a rationale how the process spaces in Step 2 are segregated. It will describe the authentication data required for code management and naturally describe the boot stack of the system.

A description of this analysis should be in the software architecture delivered by the vendor. It should make clear on the implementation level where the assets are produced, transferred, stored, and destroyed, giving a focused design description. It should furthermore provide a rationale of how the process spaces in Step 2 are segregated. It will describe the authentication data required for code management and naturally describe the boot stack of the system.

Modified p. 177 → 165

Tag Coherence Verification Identify which hardware components execute the modules tagged during software tagging. Tag the hardware with the highest domain tagged to any module executed. During the ~~analysis~~ it may happen that some hardware components have a lower domain assigned by initial hardware tagging than by software tagging. Identify the relevant assets that showed up in software tagging but were invisible during hardware tagging. Then do hardware tagging for these assets.

Tag Coherence Verification Identify which hardware components execute the modules tagged during software tagging. Tag the hardware with the highest domain tagged to any module executed. During the analysis, it may happen that some hardware components have a lower domain assigned by initial hardware tagging than by software tagging. Identify the relevant assets that showed up in software tagging but were invisible during hardware tagging. Then do hardware tagging for these assets.

Modified p. 177 → 165

If both hardware and software tagging have been performed correctly, the effective domain for each hardware component should be identical. As a result, the domain of each hardware component, down to PCB ~~tracks~~ and for each piece of code⎯and even what is considered code in the first place⎯should be clear to the developer and the testers.

If both hardware and software tagging have been performed correctly, the effective domain for each hardware component should be identical. As a result, the domain of each hardware component, down to PCB tracks, and for each piece of code⎯and even what is considered code in the first place⎯should be clear to the developer and the testers.

Modified p. 178 → 166

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.

PCI HSM may allow applications in the Data domain and the Vendor domain. Applications, therefore, can never handle cleartext PIN or keys of the Key domain. The installation and use of applications for Cloud HSM Processing elements is not permitted.

Modified p. 178 → 166

~~Asset Tagging~~ Guidance In this section, an incomplete list of typical assets and their respective domain is presented. Assets not listed here should be assigned similarly.

Asset-Tagging Guidance In this section, an incomplete list of typical assets and their respective domain is presented. Assets not listed here should be assigned similarly.

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

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

Modified p. 181 → 166

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

• 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 practical. Furthermore, it defines which components should be investigated for side channels.

Modified p. 182 → 167

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 Cryptographic Accelerators store and process cleartext 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. Cleartext cryptographic keys and components can be output from the Cryptographic Accelerator(s) via the serial connection only (cleartext key output is provided on this system for key-loading purposes). A communications switch, under the …

Document Comparison

From Revision History

Content Changes