Document Diff - PCI Watch

Added p. 3

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

Added p. 6

“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 HSM 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 HSM, such that it becomes infeasible to recover the sensitive data.

For those devices that do not contain secret information, device disablement may be used in lieu of “immediate erasure of all secret information”.

The attack must take greater than 10 hours during the exploitation phase.

TA1.4 If a cover is part of the tamper-detection mechanism, the tester shall attempt to remove the cover by disabling or defeating the tamper-detection mechanisms. To remove the cover, the …

Added p. 8

If the device is restricted to deployment in Controlled Environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.

Added p. 9

If the HSM relies on strength of the enclosure as part of its tamper prevention measures, the enclosure is strong such that attempts to penetrate the enclosure will have a high probability of causing serious damage to the module.

Added p. 10

Areas of the HSM that contain sensitive information persistently or during the normal operation of the device must be protected via tamper-detection mechanisms. Areas where plaintext sensitive information is only present when a human operator is present may be protected solely by tamper evidence mechanisms if the vendor documentation describes an inspection process that must be performed prior to entering sensitive information.

“Immediate” is defined as fast enough to ensure that erasure occurs before tamper- detection mechanisms can be disabled.

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 sensitive data and therefore do not need to be erased e.g., where the device uses a chip set that automatically generates keys at initialization but the keys are not subsequently used by the device.

TA3.1 The tester shall examine the response to Section A2 of the PCI …

Added p. 11

TA3.8 The tester shall examine vendor-supplied documentation to determine whether the components employ active or passive (i.e., removal of power) erasure. If the components employ passive erasure, the tester shall verify that it 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 all or in part to verify the theory.

Added p. 12

In order to minimize the destructive testing required, the tester may use the following to generate the assessment: review test results provided by the vendor, utilize subsections of the module for destructive testing (e.g. an epoxy sample), or analyze individual components apart from the HSM.

The vendor must either provide substantive data to support the security of the product outside normal operating conditions (if test results and/or testing on subsections/components are used to verify the security), or show that the product uses sensors that will trigger a tamper response.

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

TA4.1 The tester shall examine the vendor’s response to Section A4 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement A4 of the PCI PTS HSM Security Requirements for consistency. The vendor responses should clearly state …

Added p. 13

Public keys used for functions that impact security requirements, such as firmware updates or remote key-distribution schemes, must be protected against modification or substitution. Secret and private keys used for functions that impact security requirements must be protected against modification, substitution, or disclosure.

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

TA5.1 The tester shall examine the response to Section A5 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement A5 of the PCI PTS HSM Security Requirements manual for consistency relevant to Requirement A5. The vendor responses should clearly indicate what sensitive information and functions exist; that sensitive functions or information are only used in the protected area(s) of the HSM; and that sensitive information and functions dealing with sensitive information are protected from modification or substitution.

TA5.2 The tester shall examine any additional relevant documentation submitted …

Added p. 15

The vendor may need to supply specific test software to the evaluation laboratory to enable rigorous side channel attack analysis to be performed.

Keys resident in the device or its components means plaintext 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 C, 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.

TA7.3 The tester shall develop attack scenarios to determine any PCI HSM-related cryptographic key resident in the device, either by penetration or by monitoring emanations from the device. The tester is not required to perform the attack but may perform all or part of the attack to verify its validity. The calculation shall be based on the …

Added p. 16

Firmware integrity tests may include techniques such as SHA-2 or equivalent. The hash must either be cryptographically protected using a key (e.g., HMAC-SHA-2) or physically protected equivalent to a secret key. Authenticity testing must use cryptographic methods (MACs, digital signatures, or encryption). LRC, CRC, and other non-cryptographic methods and weak cryptographic methods (e.g., SHA-1, MD5) are not allowed as the primary mechanism for either authentication or integrity checking.

Internal generation of a cryptographic signature is valid right after firmware update, assuming it complies with Requirement B4; it is also valid for devices that do not allow for software updates outside of the factory.

Failing in a secure manner involves at least disabling any functionality of the device related to PIN handling and processing, including PIN entry and PIN encryption. More specifically, no sensitive data breach can occur as a consequence of device failure.

A device does not require authenticity checking when self-testing its …

Added p. 17

Power-up self-tests shall be performed when the cryptographic module is powered up. Conditional self-tests shall be performed when an applicable security function or operation is invoked (i.e., security functions for which self-tests are required). A cryptographic module may perform other power-up or conditional self-tests in addition to the tests specified below.

TB1.1 The tester shall examine the vendor’s response to Section B1 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B1 of the PCI PTS HSM Security Requirements to verify that the device performs a self-test upon start-up and at least once per day to check the firmware of the device, the software of the device controller, the security mechanisms for signs of tampering, and whether the device is in a compromised state; and that in the event of a failure, the relevant component‘s functionality fails in a secure manner.

TB1.3 The tester will verify that the …

Added p. 18

b) Software/firmware authenticity and integrity test A software/firmware integrity test using an error detection code (EDC) or approved authentication technique (e.g., an approved message authentication code or digital signature algorithm) shall be applied to all validated software and firmware components within a cryptographic module when the module is powered up.

If the calculated result does not equal the previously generated result, the software/firmware test shall fail.

If an EDC is used, the EDC shall be at least 16 bits in length.

c) Critical functions tests (e.g., RAM test) Other security functions critical to the secure operation of a cryptographic module shall be tested when the module is powered up as part of the power-up tests.

Documentation shall specify all security functions critical to the secure operation of a cryptographic module and shall identify the applicable power-up tests performed by the module.

TB1.6 The tester shall induce the power up self-tests and, if applicable, view any …

Added p. 19

 If the keys are used to perform key agreement, the arithmetic validity of the keys shall be tested by verifying the correct mathematical relationship between the public key and private key values.

b) Manual key-entry test If cryptographic keys or key components are manually entered into a cryptographic module, or if error on the part of the human operator could result in the incorrect entry of the intended key, the following manual key entry tests shall be performed:

 The cryptographic key or key components shall have an error-detection code (EDC) applied, or shall be entered using duplicate entries.

 If an EDC is used, the EDC shall be at least 16 bits in length.

 If the EDC cannot be verified, or the duplicate entries do not match, the test shall fail.

c) Software/firmware load test If software or firmware components can be externally loaded into a cryptographic module, the following software/firmware load …

Added p. 20

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

 A cryptographic module shall test for the correct operation of the services providing cryptographic processing when a switch takes place between an exclusive bypass service and an exclusive cryptographic service.

 If a cryptographic module can automatically alternate between a bypass service and a cryptographic service, providing some services with cryptographic processing and some services without cryptographic processing, the module shall test for the correct operation of the services providing cryptographic processing when the mechanism governing the switching procedure is modified (e.g., an IP address source/destination table).

 Documentation shall specify the mechanism or logic governing the switching …

Added p. 21

TB2.1 The tester shall examine the vendor’s response to Section B2 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B2 of the PCI PTS HSM Security Requirements to verify that the HSM’s functionality shall not be influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode and supplying wrong parameters or data.

TB2.2 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide, the specification of the HSM’s logical structure, the HSM interface specification, the software design rules and specifications, or the software implementation, to verify that it supports the vendor responses.

TB2.3 The tester shall analyze the vendor’s measures that ensure that the HSM’s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and …

Added p. 22

TB3.2 The tester shall examine the support documentation submitted by the HSM vendor. The documents should be representative of a Configuration Control process that can be audited. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; authorized access lists, and other materials that show clear evidence that the firmware is under an auditable Configuration Control procedure.

TB3.3 The tester shall examine details provided by the vendor that the documented process explicitly addresses how testing/auditing has been carried out to check for unauthorized and undocumented functions.

TB3.4 The tester will verify that the device displays or otherwise makes available the firmware revision number.

Added p. 23

TB4.2 The tester shall examine any additional documentation (i.e., specifications, schematics, block diagrams, etc.) that contains information that relates to firmware updates to determine whether it supports the assertions made by the vendor.

TB4.3 The tester shall verify that the HSM cryptographically authenticates the firmware integrity. This will be accomplished, for example, by performing a simulated firmware update.

TB4.4 The tester shall verify that the HSM rejects unauthorized firmware. This will be accomplished, for example, by performing a simulated firmware update with inadequate or modified authentication information.

TB4.5 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 are stated in Appendix C.

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

 Data input interface

• All data (except control data …

Added p. 25

 The transaction is completed, or  The HSM has timed out or  The HSM recovers from an error state.

This applies to sensitive data, such as passwords, plaintext cryptographic keys outside of the crypto-processor, and clear PIN values.

TB6.1 The tester shall examine the vendor’s response to Section B6 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B6 of the PCI PTS HSM Security Requirements to verify:

 That sensitive information shall not be present any longer or used more often than strictly necessary; and  That the HSM automatically clears its internal buffers when the transaction is completed, the HSM has timed out, or the HSM recovers from an error state.

TB6.2 The tester shall examine any relevant documentation submitted by the vendor, including vendor test results for inspections of internal buffers, the user guide, the software specification, or the software implementation, to verify that it …

Added p. 26

Authentication shall use dual-control techniques when manually entering unprotected sensitive information into the HSM through a secure user interface, or cryptographic techniques when electronically transferring protected data into the HSM. The use of other techniques to access sensitive services results in the device being unable to use previously existing keying material. The HSM requires the cooperation of at least two separately authenticated operators for administration services not normally available, such as plaintext or split knowledge of manual CSP loading or CSP output, enabling or disabling HSM security functions, or the modification of authentication data. The manual entry or output of CSPs in enciphered form requires at least one authenticated operator. The HSM limits the number of function calls (services) and the time limit on these services. If the limits are exceeded, re-authentication is required.

A sensitive service (state) allows the execution of functions that are not available during normal use•e.g., load …

Added p. 27

TB7.4 The tester shall verify from vendor documentation and from functional testing that sensitive services require authentication.

TB7.5 The tester shall verify from vendor documentation and from functional testing that entering and exiting sensitive services does not reveal or otherwise affect sensitive information.

TB7.6 The tester shall verify from vendor documentation that sensitive services are entered, used, and exited securely and that mode transitions (e.g., from operational to maintenance) do not reveal or otherwise affect sensitive information.

TB7.7 The tester shall determine that for each authentication attempt, the probability is less than one in one million that random attempts for authenticating both operators will succeed. For multiple consecutive attempts in a one-minute period, the probability is less than one in one hundred thousand that a random attempt will succeed.

TB7.8 The tester shall attempt to perform any other services listed in this section and verify that each service requires the cooperation of at least …

Added p. 28

 Sensitive data is cleared from internal buffers upon exiting the sensitive mode.

 Entering data while accessing sensitive services.

TB7.14 If mode transitions require input by a separate interface device, such as a key loader or other vendor-supplied interface device, document the mechanism(s) and methodology used.

Added p. 29

Key Form Manual Direct Network Plaintext keys No Yes No Plaintext key components Yes Yes No Enciphered keys Yes Yes Yes

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.

External SCDs (secure key loaders or other interface devices) used for loading plaintext secret or private keys or their components must either be approved against the PCI PTS HSM Security Requirements or be compliant to the requirements for devices with key- transfer and loading functionality as described in ISO 13491-2. The vendor must either provide or describe a specific, existing device that can be used for this functionality.

TB8.1 The tester shall examine the vendor’s response to Section B8 of the PCI PTS HSM …

Added p. 30

 Plaintext key entry requires dual authentication OR zeroization of pre-existing secret keys within the associated key hierarchy prior to loading of the new key.

TB8.4 The tester shall verify that the HSM does not allow entry of plaintext keys using manual or network techniques.

TB8.5 The tester shall verify that an audit log is kept by the HSM and/or the device used to perform the electronic key loading; additionally, it is procedurally specified in the vendor security policy where necessary to track actions to the specific individuals involved (i.e., automated authentication mechanisms are role based and not identity- based). In either case, the electronic log must implement cryptographic mechanisms as specified in B16. The audit log must be able to be used to track the individuals who perform plaintext key entry.

Plaintext Key Components Entry:

TB8.6 For plaintext key components, the tester shall verify the following:

 Key components are directly entered without traveling …

Added p. 31

TB8.9 The tester shall verify that any enciphered key input or output from the HSM is enciphered using an acceptable cryptographic algorithm and key size. KEKs must be at least as strong as the keys they protect.

Examples of appropriate algorithms and minimum key sizes are stated in Appendix C.

The tester shall verify that if asymmetric keys are used for entry or output, they are used in accordance with Annex A of the PCI PIN Security Requirements and Requirement B11.

TB8.10 The tester shall verify that an audit log is kept by the HSM, the device used to perform electronic key loading, or procedurally specified in the vendor security policy. Enforce the keeping of an audit log that can be used to track the individuals who perform enciphered key entry.

Added p. 32

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

Random numbers generated for use in the creation of cryptographic keys require a strong source of entropy in order to prevent predictability. Other uses, such as the generation of random nonces for the prevention of replay attacks when using asymmetric techniques to distribute symmetric keys, may only require the guarantee of uniqueness.

Source code may be required to validate this requirement.

TB9.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes each implemented RNG(s) and/or PRNG(s) to determine whether it supports the assertions made by the vendor.

TB9.3 The tester shall examine data output from all implemented RNGs and PRNGs to verify that they are capable of passing accepted statistical tests for …

Added p. 33

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

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.

TB10.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the implemented cryptographic algorithms to determine whether it supports the assertions made by the vendor.

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

 Key loading  Log data protection  Data authentication  User authentication  Key …

Added p. 34

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

TB10.6 For each of the accepted cryptographic algorithms implemented within the HSM, the tester shall verify the correct implementation of the algorithms through any of the following means:

The device must provide support for Master File Keys, whether loaded from components or internally generated, that are equivalent to or greater in strength than triple length TDES keys. The device may optionally provide support for backwards compatibility for double length TDES Master File Keys An HSM may include other key-management schemes not specified below, such as country-specific techniques when operating in PCI mode, as long as their use cannot in any way compromise the security of the PCI-compliant methods. Performing simulated transactions is not required for these key-management techniques.

Similar key-management techniques should be …

Added p. 36

Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods, including the use of algorithms and key sizes stipulated in Appendix C. Any binding or unbinding of key-usage information from the key must take place within the secure cryptographic boundary of the device.

AES keys can only be:

 Loaded using asymmetric keys of equivalent or greater strength.

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

 Manually loaded using dual-control techniques.

 Internally generated using a random number generator compliant with B9.

HSMs are allowed to have keys that are not unique per device if these keys are used for load-balancing purposes.

TB11.5 The tester shall determine from vendor documentation that the device provides support for a configuration option using TR-31 or an equivalent key-bundling methodology for symmetric key distribution and, optionally, key storage. The tester shall determine that the TR-31 or equivalent configuration …

Added p. 39

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

TB12.3 The tester shall force the HSM to erase its cryptographic keys (e.g. via a command, removal of power, tamper event). The tester shall verify that the HSM fails in a secure manner (e.g., reverts to an un-initialized state and not a normal operational state).

A secret key used to encrypt a PIN must never be used for any other cryptographic purpose. A key used to protect the PIN-encrypting key must never be used for any other cryptographic purpose. However, variants of the same key may be used for different purposes, as may keys derived from the original key. Any variant of the PEK or a key used to protect the PEK must be protected in the same manner (i.e., under the principles of dual control and split knowledge).

Key variants are …

Added p. 42

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.

Components (shares) of secret and private keys may be output in the clear to key mailers or key-transfer devices.

Clear-text PINs may be output in issuer environments. Clear-text PINs are not allowed to be output under the security policy (see C1 and B15) for HSMs used for PIN processing by an acquirer or its agent.

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.

 Translation of PIN block formats that include the PAN to PIN block formats that do not include the PAN, shall not be supported. In particular, ISO PIN …

Added p. 44

Translation Translation to ISO Format 0 ISO Format 1 ISO Format 2 ISO Format 3 ISO Format 0 Permitted anywhere without change of PAN Change of PAN only permitted in sensitive state for card issuance Not permitted Permitted for submission to an IC Permitted anywhere without change of PAN Change of PAN only permitted in sensitive state for card issuance ISO Format 1 Permitted Permitted Permitted for submission to an IC ISO Format 2 Not permitted Not permitted Permitted for submission to an IC Not permitted ISO Format 3 Permitted anywhere without change of PAN Change of PAN only permitted in sensitive state for card issuance Not permitted Permitted for submission to an IC Permitted anywhere without change of PAN Change of PAN only permitted in sensitive state for card issuance TB15.4 The tester shall verify the following (as applicable):

 The HSM supports the standard PIN block formats.

 Journaled transaction …

Added p. 46

HSMs may allow customers or integrators to install additional applications where the vendor can show that by permitting this:

a) It cannot adversely affect the security features of the product that are relevant to the

PCI HSM certification.

b) It cannot modify any of the cryptographic functionality of the HSM or introduce new primitive cryptographic functionality.

c) The application is strongly authenticated to the HSM by digital signature.

d) The application does not have access to sensitive keys.

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.

Applications, in this context, are functional entities that execute within the boundary of the HSM and may or may not provide services external to the HSM. Applications are typically processes or tasks that …

Added p. 47

TB17.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 protocols maintain the separation of applications with security impact from those without security impacts.

B17.5 If the HSM allows customers or integrators to install additional applications, the tester will verify that the HSM’s design prevents the embedded application from:

 Having access to the top-level master keys that protect the working keys•i.e., the application cannot extract or modify the top-level master key.

 Having access to operator or security officer functions, and so …

Added p. 48

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

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.

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 start- up. Additionally, only software necessary for the intended purpose of the HSM shall be present.

TB18.3 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 …

Added p. 50

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.

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.

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

Authentication data must include at least five characters.

The mode indication may be either permanent (e.g., an indicator on the HSM 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 …

Added p. 51

Devices evaluated in Section A

• Physical Derived Security Requirements where the device will be restricted to deployment in Controlled Environments as defined in ISO 13491-2 must stipulate those deployment restrictions in the device’s security policy.

The policy must include all configuration settings necessary to meet these security requirements.

HSMs may include unapproved functionality. When such functions are in use, the HSM is considered to be operating in an unapproved mode and must provide a mode indication as described in B20.

The policy must include 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. Procedures may differentiate between temporary and permanent removal.

Also see B15 for validation of allowed PIN translations.

TC1.2 The tester shall examine the security policy to verify that it defines all CSPs or classes of CSPs stored or used in …

Added p. 52

TC1.5 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.6 The tester shall examine the security policy to verify that instructions are provided with regard to tamper evidence, inspection frequency and procedures.

TC1.7 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 B16, any restrictions on operator access to logs, and procedures for accessing and deleting logs.

TC1.8 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.9 The tester shall examine the security policy and relevant vendor documentation to verify that documentation includes …

Added p. 53

 Standard PIN block formats (e.g. ISO format 0, 1, 2 and 3) shall not be translated into non-standard PIN block formats.

 Use of format 2 PIN blocks shall be constrained to offline PIN verification and PIN change operations in ICC environments only.

 Translation of PIN block formats that include the PAN to PIN block formats that do not include the PAN shall not be supported. In particular, ISO PIN block formats 0 and 3 shall not be translated into ISO PIN block format 1  When performing translations between PIN block formats that both include the PAN, a change of PAN shall not be supported except in the following case: where introduction of a new PAN is required to support account number changes for card issuance, support for change of PAN shall only be provided whilst the host security modules are in a sensitive state and under dual control …

Added p. 54

TC1.19 The tester shall examine the security policy to verify that instructions are provided for the secure decommissioning of the device, including the removal of all keying material that could be used to decrypt any sensitive data processed by the device.

Added p. 55

Identification and Exploitation For an attacker wanting to exploit a vulnerability, the vulnerability must first be identified. This may appear to be a trivial separation, but it is an important one. To illustrate this, first consider a vulnerability that is uncovered following months of analysis by an expert, and a simple attack method published on the Internet. Compare this to a vulnerability that is well known but requires enormous expenditure of time and resources to exploit. Of course, factors such as time need to be treated differently in these cases.

In this document, “exploitation” and “initial exploitation” are alternatively used to designate “initial exploitation.” Factors to be Considered The following factors should be considered for the analysis of the attack potentials required to exploit a vulnerability:

d) Equipment required such as instruments, components, IT hardware and software required for the

a) Attack time for the various levels of expertise;

d) Equipment required like instruments, …

Added p. 56

b) Proficient persons are knowledgeable in that they are familiar with the security behavior of the product. For the purposes of exploitation, proficient persons qualify when specific skills are required to conduct an attack successfully.

c) Laymen are unknowledgeable compared to experts or proficient persons, with no particular expertise. For the purpose of exploitation, they can implement an attack based on a script or a written procedure, without requiring any particular skill.

Knowledge of the HSM refers to obtaining specific expertise in relation to the HSM. This is different from generic expertise but not unrelated to it. Identified levels are as follows:

Care should be taken here to distinguish between information required to identify the vulnerability and the information required to exploit it, especially in the area of sensitive information. Requiring sensitive information for exploitation would be unusual.

Specialist expertise and knowledge of the HSM are concerned with the information required for persons to …

Added p. 57

a) Mechanical samples are non-functional and are used merely to study the mechanical design or for supplying spare parts.

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.

c) Functional samples with working keys are fully functional devices, which might be used to verify an attack method or to actually perform an attack.

If more than one sample is needed in any category, instead of multiplying the points by the number of samples, the following factors must be used:

Table 1: Multiple Samples Factors Number of Devices Factor In the case that more than one sample is accounted for, strong justification must be provided for …

Added p. 58

Rating Exploitation It is important to note that only initial exploitation is considered, as further exploitations can reuse equipment and knowledge and are subject to optimization, which cannot be easily assessed through laboratory evaluations.

The following items in calculation are typically subject to reuse in further exploitation phases:

 Equipment  Knowledge If several attack scenarios lead to the same potential in total and exploitation, then the one that has the lowest cost in exploitation, exclusive of the items above, must be considered.

Rating Success of an Attack If the difficulty of implementing an attack is sufficiently high, resulting in the attack being likely to succeed on a limited number of targets, multiple devices can be considered, given the following limitations.

To reflect this matter of fact, the number of target devices (i.e. functional samples with working keys in the exploitation phase) can be multiplied using the following factors:

Table 2: Success Rate Multiplying Factor …

Added p. 60

1. Reverse-engineer the device to understand its design, including the tamper-detecting sensors and keypad signal. Expert level in electronics is required to understand the routing of security signals, as well as to understand the keyboard scanning method. Locations of tamper mechanisms are determined and methods devised to bypass/deactivate them. It is therefore determined that 60 working hours, expert skills, standard equipment and one mechanical sample are required.

Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Public None 1 mechanical 60 hours 2. A bug is customized to monitor the keypad signals and record keypad entries. In this example, the scanning technique is simple, therefore the following levels apply: Expert, 30 hours’ work, standard parts, standard equipment, and reusing the same mechanical sample.

Expertise Equipment Knowledge Parts Samples Time needed Expert Standard Public Standard None 30 hours

3. The attack is exercised on a functional device with test keys. Injecting test keys as …

Added p. 61

2. Once inside, the attack needs to reach sensitive signals (e.g., key-scanning signals) located within a deeper layer of the device, protected by other, harder to defeat, tamper-detection mechanisms.

Expertise Equipment Knowledge Parts Samples Time needed Expert Standard (reused) Public None 1 working with keys P(success) = 0.8

3. Once the previous step is successfully achieved, the attacker will now attach the keypad signal- disclosing bug to the keyboard lines, replace the housing, and test the device. The device is ready to be placed back at the target location. Specialized equipment is required to implant the bug, due to the limited access obtained from previous step.

Expertise Equipment Knowledge Parts Samples Time needed Proficient Specialized Public Standard (bug) 1 working with keys P(success) = 1 As a summary for the exploitation phase, the following would apply:

Expertise Equipment Knowledge Parts Samples Time needed Expert Specialized Public Standard 1 working with keys P(success)  0.52 …

Added p. 62

3. Get a HSM and perform the measurement. We expect that at least 20,000 PIN translations and the associated decryptions/encryptions have to be observed. In the identification phase, this may have to be repeated several times. Since such an amount of translation operations cannot be performed surreptitiously in a real live environment, it must be possible to run the device off-line with a simulated host.

Added p. 65

Minimum key size in number of bits: 112 2048 224 2048/224 128 Key-encipherment keys shall be at least of equal or greater strength than any key that they are protecting. This applies to any key-encipherment keys used for the protection of secret or private keys that are stored or for keys used to encrypt any secret or private keys for loading or transport. For purposes of this requirement, the following algorithms and keys sizes by row are considered equivalent.

DSA/D-H AES Minimum key size in number of bits: 112 1024 160 1024/160

• Minimum key size in number of bits: 168 2048 224 2048/224

• Minimum key size in number of bits:

• 3072 256 3072/256 128 Minimum key size in number of bits:

• 7680 384 7680/384 192 Minimum key size in number of bits:

• 15360 512 15360/512 256 As an exception to the aforementioned, double-length Triple-DES key-encipherment keys may be used to encrypt …

Removed p. 1

Payment Card Industry (PCI) Hardware Security Module (HSM) Derived Test Requirements Version 1.0

Removed p. 3

October 2004 0.6 InfoGard Modifications from vendor feedback

February 2006 0.7 InfoGard Modifications from benchmark evaluation

February 2006 0.8 InfoGard Modifications from lab meeting

March 2008 0.85 Visa Harmonize with PCI PED

November 2008 0.86 PCI Modifications from lab meeting

Modified p. 3

~~September 2003 0.5 InfoGard~~ Initial ~~Draft~~

April 2009 1.0 PCI Initial release

Removed p. 5

For example, the first component under the section for DTR A.1.1 is:

For example, the first DTR under A1.1.1 is:

• The HSM components that were evaluated;

• The security level of the evaluation;

Modified p. 5

Physical Security Derived Test ~~Requirements, ~~ Logical Security Derived Test ~~Requirements,~~ Each PCI requirement as stated in the PCI Hardware Security Module (HSM) Security Requirements manual is represented by a subsection. For example, Requirement A1.1 is represented in this document as:

 Physical Security Derived Test Requirements  Logical Security Derived Test Requirements  Policy and Procedures Derived Test Requirements Each PCI requirement as stated in the PCI Hardware Security Module (HSM) Security Requirements manual is represented by a subsection. For example, Requirement A1.1 is represented in this document as:

Modified p. 5

DTR ~~A1.1~~ Tamper-Detection Mechanisms ~~When appropriate, each~~ PCI requirement has been divided into component parts. These parts are identified by the corresponding PCI requirement number and a number distinguishing it from other components of the same requirement.

DTR A1 Tamper-Detection Mechanisms Each PCI requirement has been divided into component parts. These parts are identified by the corresponding PCI requirement number and a number distinguishing it from other components of the same requirement. These components parts are DTRs.

Modified p. 5

~~DTRs are provided under each of these components.~~ These are identified by a “T,” followed by the component identification ~~number, which is followed by a~~ number ~~that distinguishes it from~~ the ~~other DTRs of the same component.~~

These are identified by a “T,” followed by the component identification number For example, the first DTR under A1 is:

Modified p. 5

Because many FIPS 140-2 evaluations only cover a subsection of the HSM and with a number of possible security levels, existing evaluation evidence for an HSM certified against FIPS 140-2 will be assessed as follows.

Because many FIPS 140-2 evaluations only cover a subsection of the HSM and with a number of possible security levels, existing evaluation evidence for a HSM certified against FIPS 140-2 will be assessed as follows.

Modified p. 5

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

 The HSM components that were evaluated;  The security level of the evaluation;  That the existing FIPS certification covers the full HSM functionality for all the related requirements.

Modified p. 6

“Immediate” is defined as fast enough to ensure erasure occurs before the tamper- detection mechanisms can be disabled using attack methods described in A1.1.

“Immediate” is defined as fast enough to ensure that erasure occurs before the tamper- detection mechanisms can be disabled using attack methods described in A1.1.

Modified p. 6

~~For those devices that do not contain secret information, device disablement may be used in lieu of “immediate erasure of all secret information”~~ “Secret information” is any private or secret cryptographic keys or passwords that the HSM relies on to maintain security characteristics governed by PCI requirements. If any of this secret information is not zeroized, ~~then~~ other mechanisms must exist to disable the device.

“Secret information” is any private or secret cryptographic keys or passwords that the HSM 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.

Modified p. 6

~~Vendor~~ shall provide documentation of test results for inspections of internal buffers.

The vendor shall provide documentation of test results for inspections of internal buffers.

Modified p. 6

~~TA1.1.1~~ The tester shall inspect the tamper-detect mechanism to verify the assertions provided by the vendor in response to Section A1.1 of the PCI HSM Evaluation Vendor Questionnaire relating to the tamper-detection mechanism.

TA1.1 The tester shall inspect the tamper-detect mechanism to verify the assertions provided by the vendor in response to Section A1.1 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the tamper-detection mechanism.

Modified p. 6

~~TA1.1.2~~ The tester shall examine additional relevant ~~documentation,~~ such as schematics and assembly drawings, ~~submitted by the vendor~~ to verify that it supports the vendor responses.

TA1.2 The tester shall examine additional relevant documentation submitted by the vendor, such as schematics and assembly drawings, to verify that it supports the vendor responses.

Modified p. 6 → 7

~~¿ Derived from Federal Information Processing Standard 140-2 (FIPS 140-2) TA1.1.4~~ If ~~a cover~~ is ~~part of~~ the ~~tamper-detection mechanism, the tester shall attempt to remove the cover by disabling or defeating the tamper-detection mechanisms.~~ To remove the cover, the tester may open, pry, or disassemble the HSM 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 …

If the device is restricted to deployment in Controlled Environments, the following applies: To remove the cover, the tester may open, pry, or disassemble the HSM 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.

Removed p. 7

TA1.1.7 The tester shall examine the response to Section A1.1 of the PCI HSM Evaluation Vendor Questionnaire relating to response of the HSM 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 under DTR B12.

Modified p. 7

~~TA1.1.5 The~~ tester shall verify that attempts to remove the cover by removing fasteners, plates, connectors, etc., or by creating a gap between the covers or cover and housing do not allow access to probe critical security circuitry without triggering the tamper-detection mechanisms.

TA1.5 If a cover is part of the tamper detection mechanism, the tester shall verify that attempts to remove the cover by removing fasteners, plates, connectors, etc., or by creating a gap between the covers or cover and housing do not allow access to probe critical security circuitry without triggering the tamper-detection mechanisms.

Modified p. 7

~~TA1.1.6~~ The tester shall verify that attempts to probe critical security circuitry through any means other than opening the case (such as through vents, fans, or holes) do not allow probing access without triggering the tamper-detection mechanisms.

TA1.6 The tester shall verify that attempts to probe critical security circuitry through any means other than opening the case (such as through vents, fans, or holes) do not allow probing access without triggering the tamper-detection mechanisms.

Modified p. 7

~~TA1.1.8~~ The tester shall examine vendor-supplied documentation to determine if the HSM employs active or passive (i.e., removal of power) erasure. If the HSM employs passive erasure, the tester shall verify that erasure occurs rapidly enough to prevent an attacker from opening the HSM 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.8 The tester shall examine vendor-supplied documentation to determine whether the HSM employs active or passive (i.e., removal of power) erasure. If the HSM employs passive erasure, the tester shall verify that erasure occurs rapidly enough to prevent an attacker from opening the HSM 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. 7

~~TA1.1.9~~ The tester shall examine any relevant ~~documentation,~~ including vendor test results for inspections of internal ~~buffers submitted by the vendor~~ to verify that it supports the vendor responses.

TA1.9 The tester shall examine any relevant documentation submitted by the vendor, including vendor test results for inspections of internal buffers, to verify that it supports the vendor responses.

Removed p. 8

If the HSM is contained within another device, such that it is not visible in its intended environment, the HSM must meet A1.1.

The enclosure is strong such that penetration attempts of the enclosure will have a high probability of causing serious damage to the module.

Modified p. 8 → 9

In general, techniques may include any combination of tamper-detection methods. Security mechanisms must not rely on insecure services or characteristics provided by the ~~HSM~~ such as (but not limited to) its power supply and unprotected wires. Tamper-evident labels and similar methods involving tamper evidence are not considered a security mechanism.

In general, techniques may include any combination of tamper-detection methods. Security mechanisms must not rely on insecure services or characteristics provided by the HSM, such as (but not limited to) its power supply and unprotected wires. Tamper-evident labels and similar methods involving tamper evidence are not considered a security mechanism.

Modified p. 8 → 9

This requirement does not imply the need for redundant security ~~mechanisms.~~

This requirement does not imply the need for redundant security mechanisms, but rather separate mechanisms of a different nature.

Modified p. 8 → 9

~~TA1.2.1~~ The tester shall examine the response to Section ~~A1.2~~ of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement ~~A1.2~~ of the PCI HSM Security Requirements manual for consistency relevant to DTR ~~A1.2.~~ The vendor responses should clearly indicate that the failure of a single security mechanism does not compromise HSM security.

TA2.1 The tester shall examine the response to Section A2 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement A2 of the PCI PTS HSM Security Requirements manual for consistency relevant to DTR A2. The vendor responses should clearly indicate that the failure of a single security mechanism does not compromise HSM security.

Modified p. 8 → 9

~~TA1.2.2~~ The tester shall examine any additional relevant ~~documentation,~~ such as assembly drawings, ~~submitted by the vendor~~ to verify that it supports the vendor responses.

TA2.2 The tester shall examine any additional relevant documentation submitted by the vendor, such as assembly drawings, to verify that it supports the vendor responses.

Modified p. 8 → 9

~~TA1.2.3~~ The tester shall verify that protection against a threat is based on a combination of at least two independent security mechanisms.

TA2.3 The tester shall verify that protection against a threat is based on a combination of at least two independent security mechanisms.

Modified p. 8 → 9

~~TA1.2.4~~ The tester shall examine the device to verify that the asserted protections exist and conform to the descriptions provided by the vendor in documentation. This will include disassembly of the test unit when necessary.

TA2.4 The tester shall examine the device to verify that the asserted protections exist and conform to the descriptions provided by the vendor in documentation. This will include disassembly of the test unit when necessary.

Modified p. 8 → 9

~~TA1.2.5~~ The tester shall perform tests to verify that the protections of the device are such that penetration cannot occur without damaging the device so severely that the damage has a high probability of being detected by a knowledgeable ~~observer.~~

TA2.5 The tester shall perform tests to verify that the protections of the device are such that penetration cannot occur without damaging the device so severely that the damage has a high probability of being detected by a knowledgeable observer, or else the module detects the tampering attempt and zeroizes critical secrets.

Modified p. 9 → 14

~~TA2.1~~ The tester shall examine the response to Section A2 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement A2 of PCI HSM Security Requirements for consistency relevant to ~~A2.~~

TA6.1 The tester shall examine the response to Section A6 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement A6 of PCI PTS HSM Security Requirements for consistency relevant to A6.

Modified p. 9 → 14

~~TA2.2~~ The tester shall examine any relevant ~~documentation,~~ such as schematics and assembly drawings, ~~submitted by the vendor~~ to verify that it supports the vendor responses to the PCI HSM Evaluation Vendor Questionnaire.

TA6.2 The tester shall examine any relevant documentation submitted by the vendor, such as schematics and assembly drawings, to verify that it supports the vendor responses to the PCI PTS HSM Evaluation Vendor Questionnaire.

Modified p. 9 → 14

~~TA2.3~~ The tester shall visually inspect the HSM to verify the assertions provided by the vendor in the PCI HSM Evaluation Vendor Questionnaire relating to protections against the monitoring of electro-magnetic emissions, power ~~consumption~~ or any other internal or external characteristic available for monitoring. This could include verifying that any components that provide protection are as stated by the vendor.

TA6.3 The tester shall visually inspect the HSM to verify the assertions provided by the vendor in the PCI PTS HSM Evaluation Vendor Questionnaire relating to protections against the monitoring of electro-magnetic emissions, power consumption, or any other internal or external characteristic available for monitoring. This could include verifying that any components that provide protection are as stated by the vendor.

Modified p. 9 → 14

~~TA2.4~~ The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms against the monitoring of electro-magnetic emissions, power ~~consumption~~ or any other internal or external characteristic available for monitoring, using attack scenarios which require an attack potential of ~~<25~~ per HSM for identification and initial exploitation. The attack potential calculation shall be based on the scheme depicted in Appendix A.

TA6.4 The tester shall develop attack scenarios to defeat or circumvent the protection mechanisms against the monitoring of electro-magnetic emissions, power consumption, or any other internal or external characteristic available for monitoring, using attack scenarios which require an attack potential of <26 per HSM for identification and initial exploitation or <13 for initial exploitation. The attack potential calculation shall be based on the scheme depicted in Appendix A.

Modified p. 9 → 14

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 Controlled Environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However, removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.

Removed p. 10

HSMs that can be uniquely identified through acceptable cryptographic methods as defined below may not require unique enclosures.

Examples of appropriate algorithms and minimum key sizes are:

Algorithm DES RSA Elliptic Curve DSA Minimum key size in number of bits 112 1024 160 1024/160 DES refers to 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. 10 → 15

~~TA3.1~~ The tester shall examine the response to Section A3 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement A3 of the PCI HSM Security Requirements ~~manual~~ for consistency relevant to ~~A3.~~

TA7.1 The tester shall examine the vendor’s response to Section A7 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement A7 of the PCI PTS HSM Security Requirements for consistency relevant to A7.

Modified p. 10 → 15

~~TA3.2~~ The tester shall examine any ~~additional~~ relevant documentation submitted by the ~~vendor~~ to verify that it supports vendor responses. ~~This could be documentation such as parts lists that indicate that HSM is housed in a custom or semi-custom enclosure.~~

TA7.2 The tester shall examine any relevant documentation submitted by the vendor, such as assembly drawings, test data, etc., to verify that it supports the vendor responses.

Removed p. 11

Public keys used for functions that impact security requirements, such as firmware updates or remote key distribution schemes must be protected against modification or substitution. Secret and private keys used for functions that impact security requirements must be protected against modification, substitution or disclosure.

TA4.1 The tester shall examine the response to Section A4 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement A4 of the PCI HSM Security Requirements manual for consistency relevant to Requirement A4. The vendor responses should clearly indicate what sensitive information and functions exists; and that sensitive functions or information are only used in the protected area(s) of the HSM; and that sensitive information and functions dealing with sensitive information are protected from modification or substitution, and that additionally secret and private keys are protected from disclosure.

TA4.3 Verify the completeness of the information regarding sensitive information and functions presented by the vendor.

TA4.4 The …

Modified p. 11 → 15

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 Controlled Environments, the following applies: The tester may drill out visible fasteners (e.g., screws, rivets, press-fittings, etc.) to remove the cover or to create a gap between the covers or cover and housing to insert probes. However removal shall not consist of drilling, milling, burning, melting, grinding, or dissolving the cover or enclosure.

Modified p. 11 → 17

~~TA4.2~~ The tester shall examine any ~~additional~~ relevant documentation, such as ~~assembly drawings and functional specifications~~ submitted by the vendor to verify that it supports the vendor ~~responses.~~

TB1.2 The tester shall examine any relevant documentation, such as the user guide or the software specification, submitted by the vendor to verify that it supports the vendor responses, including evidence of testing that confirms the relevant component fails securely in the event of self-test failure.

Removed p. 12

Areas of the HSM that contain sensitive information persistently or during the normal operation of the device must be protected via tamper-detection mechanisms. Areas where plain-text sensitive information is only present when a human operator is present may be protected solely by tamper evidence mechanisms if the vendor documentation describes an inspection process that must be performed prior to entering sensitive information.

“Immediate” is defined as fast enough to ensure erasure occurs before tamper-detection mechanisms can be disabled. Cryptographic keys that are never used to encrypt or decrypt data, or are not used for authentication, do not need to be considered sensitive data and therefore do not need to be erased.

TA5.2 The tester shall examine any relevant documentation, such as assembly drawings, submitted by the vendor to verify that it supports the vendor responses.

TA5.3 The tester shall verify the existence and design of any mechanisms asserted by the vendor to protect …

Modified p. 12 → 23

~~TA5.1~~ The tester shall examine the response to Section A5 of the PCI HSM Evaluation Vendor Questionnaire ~~and~~ the ~~response to Requirement A5 of PCI HSM Security Requirements~~ for consistency.

TB4.1 The tester shall examine the response to Section B4 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the authentication procedures for remote firmware updates, for consistency.

Removed p. 13

HSMs may include unapproved functionality. When such functions are in use, the HSM is considered to be operating in an unapproved mode. Also see B13 for validation of allowed PIN translations.

TA6.2 The tester shall examine the security policy to verify that it 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.

TA6.3 The tester shall examine the security policy to verify that it lists all cryptographic algorithms (e.g., TDES, SHA-1) and key management techniques (e.g., DUKPT) supported by the HSM.

TA6.4 The tester shall examine the security policy to verify that it states keys should be replaced with new keys whenever the compromise of the original key …

Modified p. 13 → 22

~~TA6.1~~ The tester shall examine the ~~vendor’s~~ response to Section A6 of the PCI HSM Evaluation Vendor Questionnaire and ~~the response to Requirement A6 of the PCI HSM Security Requirements~~ for consistency.

TB3.1 The tester shall examine the response to Section B3 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the firmware documentation and certification process, for consistency.

Removed p. 14

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

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

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

TA6.12 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 tests are executed (e.g., power up, periodic, conditional, on operator demand).

TA6.13 The tester shall examine the security …

Removed p. 15

Only ISO formats 0 and 3 can be used for calculating values derived from the PIN and PAN such as PIN Offsets and PIN Verification Values (PVV).

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 then the calculated value shall not be returned. Where introduction of a new PAN is required to support account number changes for card issuance then support shall only be provided whilst the host security modules are in a sensitive state and under dual control.

Any integrity checks performed on the deciphered PIN block shall rely only on the first byte of the PIN block (control field and PIN length field) and fill digits (to ensure that each digit is a permitted value).

The following illustrates translations from formats 0, 1 and 3:

TRANSLATION …

Removed p. 16

In order to minimize the destructive testing required, the tester may use the following to generate the assessment: review test results provided by the vendor, utilize subsections of the module for destructive testing (e.g. an epoxy sample), or analysis on individual components apart from the HSM.

The vendor must either provide substantive data to support the security of the product outside normal operating conditions, or show that the product uses sensors that will trigger a tamper response.

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

TA7.1 The tester shall examine the vendor’s response to Section A7 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement A7 of the PCI HSM Security Requirements for consistency. The vendor responses should clearly state that the security of the HSM is not compromised by altering environmental conditions or operational conditions.

TA7.2 The …

Removed p. 17

¿ Derived from Federal Information Processing Standard 140-2 (FIPS 140-2) DTR B2 Clear-Text Key Security There is no mechanism in the HSM that would allow the outputting of existing private or secret clear-text keys, the encryption of a key or PIN under a key that might itself be disclosed, or the transfer of a clear-text key from a component of high security into a component of lesser security. All cryptographic functions implemented shall not output clear-text CSPs to components that could negatively impact security.

Modified p. 17 → 24

~~ Data input interface Data output interface Control input interface Status output interface TB1.1~~ The tester shall examine the vendor’s response to Section B1 of the HSM Evaluation Vendor Questionnaire and the response to Requirement B1 of the HSM Security Requirements manual for consistency.

TB5.1 The tester shall examine the vendor’s response to Section B5 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B5 of the PCI PTS HSM Security Requirements manual for consistency.

Modified p. 17 → 24

~~TB1.2~~ The tester shall examine any additional documentation (e.g., API reference, design documentation, ~~key management~~ specification) that describes the logical interfaces to determine if it supports the assertions made by the vendor. Documentation should indicate that the device is designed to distinguish between commands and data input, and status and data output.

TB5.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the logical interfaces to determine whether it supports the assertions made by the vendor. Documentation should indicate that the device is designed to distinguish between commands and data input, and status and data output.

Modified p. 17 → 24

~~TB1.3~~ The tester shall review vendor documentation to verify that the HSM distinguishes between data and control for inputs and also between data and status for outputs. To provide evidence that the HSM distinguishes between commands and data inputs, the tester shall verify that the HSM responds with error messages or ignores inputs when erroneous commands and data are input.

TB5.3 The tester shall review vendor documentation to verify that the HSM distinguishes between data and control for inputs and also between data and status for outputs. To provide evidence that the HSM distinguishes between commands and data inputs, the tester shall verify that the HSM responds with error messages or ignores inputs when erroneous commands and data are input.

Removed p. 18

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.

Components (shares) of secret and private keys may be output in the clear to key mailers or key transfer devices Clear-text PINs may be output in issuer environments. Clear-text PINs are not allowed to be output under the security policy (see A6 and B13) for HSMs used for PIN processing by an acquirer or its agent.

TB2.4 The tester shall examine any additional documentation (i.e., API Programmer’s guide, specifications, block diagrams, etc.) that contains information that relates to any of the aforementioned to determine if it supports the assertions made by the vendor.

Modified p. 18 → 26

~~TB2.1~~ The tester shall examine the response to Section B2 of the PCI HSM Evaluation Vendor Questionnaire ~~relating~~ to the ~~output of clear-text keys and protection of PINs~~ for consistency.

TB7.1 The tester shall examine the vendor’s response to Section B7 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B7 of the PCI PTS HSM Security Requirements for consistency.

Modified p. 18 → 32

~~TB2.2~~ The tester shall examine the response to Section B2 of the PCI HSM Evaluation Vendor Questionnaire ~~relating~~ to ~~encryption~~ of ~~a key or PIN under a key that might itself be disclosed,~~ for consistency.

TB9.1 The tester shall examine the vendor’s response to Section B9 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B9 of the PCI PTS HSM Security Requirements for consistency.

Modified p. 18 → 33

~~TB2.3~~ The tester shall examine the response to Section B2 of the PCI HSM Evaluation Vendor Questionnaire ~~relating~~ to the ~~transfer of a key from a high-security component to a lower-security component,~~ for consistency.

TB10.1 The tester shall examine the response to Section B10 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B10 of the PCI PTS HSM Security Requirements manual for consistency.

Removed p. 19

An HSM may include other key management schemes not specified below, such as country specific techniques. Performing simulated transactions is not required for these key management techniques. Similar key management techniques should be used for other services like card personalization and data protection.

Modified p. 19 → 35

For all TDEA modes of operation, the three cryptographic keys (K1, K2, K3) define a TDEA key bundle (see ~~X9.52).~~ The bundle and the individual keys must:

For all TDEA modes of operation, the three cryptographic keys (K1, K2, K3) define a TDEA key bundle (see X9.24). The bundle and the individual keys must:

Modified p. 19 → 35

Be secret; Be generated randomly or pseudo-randomly; Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source; Be used in the appropriate order as specified by the particular mode; Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and Cannot be unbundled for any …

 Be secret;  Be generated randomly or pseudo-randomly;  Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source;  Be used in the appropriate order as specified by the particular mode;  Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and  Cannot be unbundled for any …

Modified p. 19 → 36

~~Documentation must be provided demonstrating how the methodology meets these criteria. TB3.1~~ The tester shall examine the response to Section B3 of the PCI HSM Evaluation Vendor Questionnaire relating to the method of key management in use in the HSM, for consistency.

TB11.1 The tester shall examine the response to Section B11 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the method of key management in use in the HSM, for consistency.

Modified p. 19 → 36

~~TB3.2~~ The tester shall examine any relevant documentation such as a user guide, ~~submitted by the vendor~~ to verify that it supports vendor responses.

TB11.2 The tester shall examine any relevant documentation submitted by the vendor, such as a user guide or the API programmer’s guide, to verify that it supports vendor responses.

Modified p. 19 → 36

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

TB11.3 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. 19 → 36

~~TB3.4~~ 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 if it supports the assertions made by the vendor.

TB11.4 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. 20

TB3.7 If used for online PIN translation, the tester shall verify that the HSM supports TDES for online PIN translation. The tester shall perform simulated transactions for each accepted combination of key management technique and cryptographic algorithm supported by the HSM (e.g., DUKPT & TDES; MK/SK & TDES).

Modified p. 20 → 36

~~TB3.6~~ The tester shall verify that the loading of private and secret keys uses one or more of the following methods:

TB11.6 The tester shall verify that the loading of private and secret keys uses one or more of the following methods:

Modified p. 20 → 37

b) For injecting ~~plain-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 HSM or both must require two or more PINs/passwords before injecting the ~~plain-text~~ key into the HSM. (Note: This may be the entire key•if components, each component requires a separate password). These passwords are entered directly through the keypad of the applicable device or are conveyed encrypted into the device and must …

b) For injecting plaintext secret or private keys from a key loader (which has to be some type of secure cryptographic device), either the key loader or the HSM or both must require two or more PINs/passwords before injecting the plaintext key into the HSM. (Note: This may be the entire key•if components, each component requires a separate password). These passwords are entered directly through the keypad of the applicable device or are conveyed encrypted into the device and must …

Modified p. 20 → 37

c) For encrypted values injected into the HSM, either from a key loader or from a network host, or via a secure interface device, the ability of the HSM to successfully decrypt the value and use it is sufficient. In this case, the ~~loading of the key~~ encipherment key ~~would have been done~~ under dual ~~control, e.g.,~~ in examples a) and b) ~~above.~~

c) For encrypted values injected into the HSM, either from a key loader or from a network host, or via a secure interface device, the ability of the HSM to successfully decrypt the value and use it is sufficient. In this case, the key- encipherment key is trusted because it was previously loaded under dual control•e.g., in examples a) and b) above or using another secure and trusted method, e.g., loaded encrypted as part of a key hierarchy.

Removed p. 21

TB3.10 The tester shall determine from vendor documentation how (e.g., active or passive erasure) each key is destroyed for all device states (power-on, power-off, sleep mode) and list the details in a key summary table.

Modified p. 21 → 38

Form Factor Loaded to Device In Number of Available Key Slots (Registers) Unique per device/acquirer/ vendor-specific/ other (describe) Master Key Encryption of working keys (PEK, MAC) for local storage TDES 128 Acquirer 2 or 3 ~~plain- text~~ components One Device Manufacturer Authentication Root Public Key Authentication of firmware updates RSA 2048 Manufacturer ~~Self signed~~ Public Key Certificate One Vendor-specific Manufacturer Authentication Private Root Private Key Signing firmware updates RSA 2048 Manufacturer Managed at ~~manufacturer’ s~~ secure facility under dual control …

Form Factor Loaded to Device In Number of Available Key Slots (Registers) Unique per device/acquirer/ vendor-specific/ other (describe) Master Key Encryption of working keys (PEK, MAC) for local storage TDES 128 Acquirer 2 or 3 plaintext components One Device Manufacturer Authentication Root Public Key Authentication of firmware updates RSA 2048 Manufacturer Self-signed Public Key Certificate One Vendor-specific Manufacturer Authentication Private Root Private Key Signing firmware updates RSA 2048 Manufacturer Managed at manufacturer’s secure facility under dual control One Vendor-specific KDH …

Modified p. 21 → 38

~~TB3.9~~ The tester shall determine from vendor documentation all storage and usage locations for each key ~~e.g.,~~ ROM, external RAM, EPROM, processor chip, ~~etc~~ and list the details in a key summary table.

TB11.10 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 HSM and list the details in a key summary table.

Removed p. 22

Key Form Manual Direct Network Plain-text Keys No Yes No Plain-text Key Components Yes Yes No Enciphered Keys Yes Yes Yes

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) See ISO 11568 for further information.

Plain-text key entry:

TB4.3 The tester shall verify the following:

Any plain-text keys entered use direct techniques.

Any plain-text keys are directly entered without traveling through any enclosing or intervening systems.

Vendor documentation indicates that the device used to load keys is a secure cryptographic device including physical protections.

Plain-text key entry requires dual authentication OR zeroization of pre-existing secret keys within the associated key hierarchy prior to loading of the new key.

TB4.4 The tester shall verify that the HSM does not allow entry of plain-text keys using manual or network techniques.

¿ Derived from Federal Information …

Modified p. 22 → 39

~~TB4.1~~ The tester shall examine the vendor’s response to Section B4 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement B4 of the PCI HSM Security Requirements for ~~consistency relevant to B4.~~

TB12.1 The tester shall examine the vendor’s response to Section B12 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B12 of the PCI PTS HSM Security Requirements for consistency.

Modified p. 22 → 39

~~TB4.2~~ The tester shall examine any additional documentation (e.g., API reference, design documentation, ~~key management~~ specification) that describes the ~~entry of key components~~ to determine if it supports the assertions made by the vendor.

TB12.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the HSM’s behavior when cryptographic keys are lost to determine whether it supports the assertions made by the vendor.

Removed p. 23

Examples of appropriate algorithms and minimum key sizes are:

Plain-text key components entry:

TB4.6 For plain-text key components, the tester shall verify the following:

Key components are directly entered without traveling through enclosing or intervening systems.

A minimum of two components is required to reconstruct the original key.

If knowledge of n components is required to reconstruct the key, then knowledge of any n-1 components provides no information about the original key other than the length.

Plain-text key component entry requires dual authentication OR zeroization of pre-existing secret keys within the associated key hierarchy prior to loading of the new key.

TB4.7 The tester shall verify that the HSM does not allow entry of plain-text key components using network techniques.

TB4.8 The tester shall verify that an audit log is kept by the HSM, the device used to perform electronic key loading, or procedurally specified in the vendor security policy. The audit log must …

Removed p. 24

TB5.1 The tester shall examine the vendor’s response to Section B5 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement B5 of the PCI HSM Security Requirements for consistency.

TB5.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key management specification) that describes dual control procedures to determine if it supports the assertions made by the vendor.

TB5.3 The tester shall determine that for each authentication attempt, the probability is less than one in one million that random attempts for authenticating both operators will succeed. For multiple consecutive attempts in a one-minute period, the probability is less than one in one hundred thousand that a random attempt will succeed.

TB5.4 The tester shall attempt to manually enter and output CSPs in enciphered form to verify that the process requires at least one authenticated operator. The tester shall enter incorrect authentication data into the HSM and attempt …

Removed p. 25

KEKs designated for specific purposes, e.g., to encipher specific key types, cannot be used for other purposes.

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

¿ Derived from Federal Information Processing Standard 140-2 (FIPS 140-2) DTR B7 Cryptographic Key Loss The HSM ensures that if cryptographic keys within the secure HSM boundary are unintentionally rendered invalid for any reason (e.g., tamper or long-term absence of applied power), the HSM will fail in a secure manner.

Modified p. 25 → 40

~~Key usage~~ information may be changed where the usage is made more ~~restrictive, e.g.,~~ made ~~non-exportable.~~

Key-usage information may be changed where the usage is made more restrictive (e.g., made non-exportable).

Modified p. 25 → 40

~~TB6.1~~ The tester shall examine the response to Section B6 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement B6 of the HSM Security Requirements manual for consistency.

TB13.1 The tester shall examine the response to Section B13 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B13 of the PCI PTS HSM Security Requirements manual for consistency.

Modified p. 25 → 40

~~TB6.2~~ 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 if it supports the assertions made by the vendor. Examples of “cryptographic function” are: DES and AES.

TB13.2 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. Examples of “cryptographic function” are: DES and AES.

Modified p. 25 → 40

~~TB6.3~~ 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 if it supports the assertions made by the vendor. For example: a public key shall not be used by the HSM for both signature authentication and encryption. Examples of a key’s “cryptographic purpose” are: Data encryption, ~~Key Encryption,~~ and MAC.

TB13.3 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 HSM for both signature authentication and encryption. Examples of a key’s “cryptographic purpose” are: Data encryption, key encryption, and MAC.

Modified p. 25 → 41

Physical segregation Storing keys enciphered under a KEK dedicated to encipherment of a specific type of key Modifying or appending information to a key as a function of its intended purpose, prior to encipherment of the key for storage, e.g., key tags ~~TB6.5~~ The tester shall verify the following:

 Physical segregation  Storing keys enciphered under a KEK dedicated to encipherment of a specific type of key  Modifying or appending information to a key as a function of its intended purpose, prior to encipherment of the key for storage, e.g., key tags TB13.5 The tester shall verify the following:

Removed p. 26

TB7.3 The tester shall force the HSM to erase its cryptographic keys (e.g. via a command, removal of power, tamper event). The tester shall verify that the HSM fails in a secure manner, e.g., revert to an un-initialized state and not a normal operational state. .

Modified p. 26 → 49

~~TB7.2~~ The tester shall examine any additional documentation (e.g., API reference, design documentation, ~~key management~~ specification) that describes the ~~HSM’s behavior when cryptographic keys are lost~~ to determine if it supports the assertions made by the vendor.

TB19.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes the unique device ID to determine whether it supports the assertions made by the vendor.

Modified p. 26 → 51

~~TB7.1~~ The tester shall examine the vendor’s response to Section B7 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement B7 of the PCI HSM Security Requirements for consistency.

TC1.1 The tester shall examine the vendor’s response to Section C1 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement C1 of the PCI PTS HSM Security Requirements for consistency.

Removed p. 27

TB8.3 The tester shall examine data output from all implemented RNGs and PRNGs to verify that they are capable of passing accepted statistical tests for randomness The tester shall use a suitable test method (for example, those listed in NIST PUB 800- 22). See Appendix B.

TB8.4 The tester shall examine the design specification of the RNG and determine how the RNG is used to protect or produce sensitive data.

¿ Derived from Federal Information Processing Standard 140-2 (FIPS 140-2) DTR B9 Logical Anomalies The HSM’s functionality shall not be influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode and supplying wrong parameters or data which could result in the HSM outputting the clear-text PIN or other sensitive information.

Modified p. 27 → 43

~~TB8.2~~ The tester shall examine any additional documentation (e.g., API reference, design documentation, ~~key management~~ specification) that describes ~~each implemented RNG(s) and/or PRNG(s)~~ to determine if it supports the assertions made by the vendor.

TB15.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes PIN management to determine whether it supports the assertions made by the vendor.

Modified p. 27 → 45

~~TB8.1~~ The tester shall examine the vendor’s response to Section B8 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement B8 of the PCI HSM Security Requirements for consistency.

TB16.1 The tester shall examine the vendor’s response to Section B16 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B16 of the PCI PTS HSM Security Requirements manual for consistency.

Removed p. 28

TB9.3 The tester shall analyze the vendor’s measures that ensure that the HSM’s functionality is not influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.

TB9.4 The tester may perform tests needed to validate the device’s properties in conformance with this requirement. The evaluator should use his or her own judgment in determining appropriate tests. Test support shall be provided by the vendor as needed to access and use the interfaces under test.

Modified p. 28 → 48

Vendors should provide software ~~design rules and~~ specifications to support answers.

Vendors should provide configuration lists and software specifications to support their answers.

Modified p. 28 → 48

~~TB9.2~~ The tester shall examine any relevant documentation, such as a user guide, the specification of the ~~HSM’s~~ logical structure, the ~~HSM~~ interface specification, ~~the software design rules and specifications,~~ or the software implementation submitted by the vendor to verify that it supports the vendor responses.

TB18.2 The tester shall examine any relevant documentation, such as a user guide, the specification of the device’s logical structure, the device interface specification, or the software implementation submitted by the vendor to verify that it supports the vendor responses.

Modified p. 28 → 49

~~TB9.1~~ The tester shall examine the vendor’s response to Section B9 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement B9 of the PCI HSM Security Requirements to verify that the HSM’s functionality shall not be influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode, and supplying wrong parameters or data.

TB19.1 The tester shall examine the vendor’s response to Section B19 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B19 of the PCI PTS HSM Security Requirements manual for consistency.

Removed p. 29

TB10.2 The tester shall examine the support documentation submitted by the HSM vendor. The documents should be representative of a Configuration Control process that can be audited. The documentation could include firmware revision lists with updates documented, current source code check-in, checkout, and control procedures; authorized access lists, and other materials that show clear evidence that the firmware is under an auditable Configuration Control procedure.

TB10.3 The tester shall examine details provided by the vendor that the documented process explicitly addresses how testing/auditing has been carried out to check for unauthorized and undocumented functions.

TB10.4 The tester will verify that the device displays or otherwise makes available the revision number.

Modified p. 29 → 42

~~TB10.1~~ The tester shall examine the response to Section ~~B10~~ of the PCI HSM Evaluation Vendor Questionnaire relating to the ~~firmware documentation~~ and ~~certification process,~~ for consistency.

TB14.1 The tester shall examine the response to Section B14 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the output of clear-text keys and protection of PINs for consistency.

Removed p. 30

The transaction is completed, or The HSM has timed out or The HSM recovers from an error state.

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

• That sensitive information shall not be present any longer or used more often than strictly necessary; and

• That the HSM automatically clears its internal buffers when either the transaction is completed or the HSM has timed out.

TB11.3 The tester will verify that the vendor has identified all data that is automatically cleared when the transaction is completed or the HSM has timed out or the HSM recovers from an error state, and that all sensitive data is included. Passwords, plain-text cryptographic keys,and PIN values are considered sensitive data.

TB11.4 The tester will verify that all sensitive data is automatically cleared when the transaction is completed or the HSM has timed out or …

Modified p. 30 → 43

~~TB11.1~~ The tester shall examine the ~~vendor’s~~ response to Section ~~B11~~ of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement ~~B11~~ of the PCI HSM Security Requirements ~~to verify:~~

TB15.1 The tester shall examine the response to Section B15 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B15 of the PCI PTS HSM Security Requirements manual for consistency.

Modified p. 30 → 50

~~TB11.2~~ The tester shall examine any relevant ~~documentation, including vendor test results for inspections of internal buffers, the user guide, the software specification, or the software implementation~~ submitted by the ~~vendor~~ to verify that it supports ~~the~~ vendor responses.

TB20.2 The tester shall examine any additional relevant documentation submitted by the vendor, such as user guides or an API, to verify that it supports vendor responses.

Removed p. 31

Algorithm DES RSA Minimum key size in number of bits 112 1024 160 1024/160 DES refers to 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.

Key loading Log data protection Data authentication User authentication Key encryption Software/firmware updates PIN management All security protocols Examples of appropriate algorithms and minimum key sizes are:

Key encryption keys must be of equal or greater length than keys they are used to protect. Examples of acceptable hashing algorithms include SHA-1, SHA-256, SHA-384 and SHA-512. MD5 is not allowed for use for protocols impacting the HSM’s security, …

Modified p. 31 → 45

~~TB12.2~~ The tester shall examine any additional documentation (e.g., API reference, design documentation, ~~key management~~ specification) that describes ~~the implemented cryptographic algorithms~~ to determine if it supports the assertions made by the vendor.

TB16.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key-management specification) that describes secure logging to determine whether it supports the assertions made by the vendor.

Modified p. 31 → 48

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

TB18.4 The tester shall verify that the operating system/firmware is enforcing least privilege.

Modified p. 31 → 50

~~TB12.1~~ The tester shall examine the response to Section ~~B12~~ of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement ~~B12~~ of the PCI HSM Security Requirements manual for consistency.

TB20.1 The tester shall examine the response to Section 20 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement 20 of the PCI PTS HSM Security Requirements manual for consistency.

Removed p. 32

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

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

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

Testing performed by the evaluator.

Removed p. 33

Translation of PIN block formats that include the PAN, to PIN block formats that do not include the PAN, shall not be supported. In particular, ISO PIN block formats 0 and 3 shall not be translated into ISO PIN block format 1.

TB13.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key management specification) that describes PIN Management to determine if it supports the assertions made by the vendor.

Translations between PIN block formats that both include the PAN shall not support a change in the PAN. The PIN translation capabilities between ISO formats 0 and 3 (including translations from ISO 0 formats to ISO 0 format, or from ISO 3 format to ISO 3 format) do not allow a change of PAN. Where introduction of a new PAN is required to support account number changes for card issuance then support shall only be provided whilst …

Modified p. 33 → 43

Note: If supporting online PIN processing, the HSM must support at least one of the following key-management techniques using TDES as described in ANSI X9.24 and ~~ANSI X9.52:~~

Note: If supporting online PIN processing, the HSM must support at least one of the following key-management techniques using TDES as described in ANSI X9.24 and ISO/IEC 18033-3:

Modified p. 33 → 43

~~ DUKPT Fixed ~~ Master/Session The HSM must also support at least one of the following PIN ~~Block Formats~~ if supporting online PIN processing:

 Master/Session The HSM must also support at least one of the following PIN block formats if supporting online PIN processing:

Modified p. 33 → 43

ISO Format 0 ISO Format 1 ISO Format 3 ~~TB13.3~~ The tester shall verify that the security policy configuration examined in A6 only allows the following translations when the policy is implemented:

 ISO Format 0  ISO Format 1  ISO Format 3 TB15.3 The tester shall verify that the security policy configuration examined in C1 only allows the following translations when the policy is implemented:

Modified p. 33 → 43

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

 Standard PIN block formats (e.g. ISO format 0, 1, 2 and 3) shall not be translated into non-standard PIN block formats.

Modified p. 33 → 43

~~ Format~~ 2 PIN blocks shall be constrained to offline PIN verification and PIN change operations in ICC environments only.

 Use of format 2 PIN blocks shall be constrained to offline PIN verification and PIN change operations in ICC environments only.

Modified p. 33 → 48

~~TB13.1~~ The tester shall examine the response to Section ~~B13~~ of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement ~~B13~~ of the PCI HSM Security Requirements ~~manual~~ for ~~consistency.~~

TB18.1 The tester shall examine the vendor’s response to Section B18 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B18 of the PCI PTS HSM Security Requirements to verify that the operating system and the related software of the device contain only the components and the services necessary for the intended operation.

Modified p. 33 → 53

Only ISO formats 0 and 3 ~~can~~ be used for ~~calculating values~~ derived from the PIN and ~~PAN such as~~ PIN ~~Offsets~~ and PIN ~~Verification Values~~ (PVV).

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

Removed p. 34

TRANSLATION To È From È ISO Format 0 ISO Format 1 ISO Format 3 ISO Format 0 Change of PAN only permitted in sensitive state for card issuance Not permitted Change of PAN only permitted in sensitive state for card issuance ISO Format 1 PAN input Permitted PAN input ISO Format 3 Change of PAN only permitted in sensitive state for card issuance Not permitted Change of PAN only permitted in sensitive state for card issuance TB13.4 The tester shall verify the following (as applicable):

a) The HSM supports the standard PIN block formats. b) Journaled transaction messages do not contain a PIN. c) All key encryption keys must have an appropriate length and are used with an accepted algorithm. d) The system cannot be used to determine a PIN by exhaustive trial and error. If the HSM itself does not provide limits to prevent exhaustive searches, documentation must be provided …

Modified p. 34 → 44

Any integrity checks performed on the deciphered PIN block shall rely only on the first byte of the PIN block (control field and PIN length field) and fill digits (to ensure that each digit is a permitted value).

 Any integrity checks performed on the deciphered PIN block shall rely only on the first byte of the PIN block (control field and PIN length field) and fill digits (to ensure that each digit is a permitted value).

Modified p. 34 → 44

The following illustrates translations from formats 0, 1 and 3:

The following illustrates translations from formats 0, 1, 2 and 3:

Removed p. 35

The device must perform an internal self-test including firmware integrity check (such as a SHA-1 hash or CRS) automatically at least once every day, in addition to at power-up. It is acceptable to perform firmware integrity checks before each transaction as opposed to performing them at least once every 24 hours. Self-tests after several minutes of inactivity may also be used, rather than once every 24 hours, in addition to power-up self-tests.

If the periodic tests are not automatically initiated, the security policy must specify guidance for the operator to run these tests. The HSM should record the self-test execution and record the result in an audit log.

TB14.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key management specification) that describes power-up self-tests to determine if it supports the assertions made by the vendor.

a) Cryptographic algorithm known answer tests b) Software/firmware integrity test c) Critical functions tests …

Modified p. 35 → 42

~~TB14.1~~ The tester shall examine the ~~vendor’s~~ response to Section B14 of the PCI HSM Evaluation Vendor Questionnaire ~~and the response~~ to ~~Requirement B14~~ of ~~the PCI HSM Security Requirements manual~~ for consistency.

TB14.2 The tester shall examine the response to Section B14 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to encryption of a key or PIN under a key that might itself be disclosed, for consistency.

Modified p. 35 → 45

~~TB14.3~~ The tester shall verify that the HSM ~~performs the following power up self-tests:~~

TB16.4 The tester shall verify that the HSM supports secure logging, including time stamps, of security sensitive commands such as:

Removed p. 36

a) Pairwise consistency tests b) Manual key-entry test c) Software/firmware load test d) Continuous random number generator test e) Bypass test TB14.8 The tester shall induce the conditional self-tests and if applicable, view any status provided by the HSM to verify that self-tests executed successfully.

Removed p. 37

TB15.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key management specification) that describes secure logging to determine if it supports the assertions made by the vendor.

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

Modified p. 37 → 42

~~TB15.1~~ The tester shall examine the ~~vendor’s~~ response to Section ~~B15~~ of the PCI HSM Evaluation Vendor Questionnaire ~~and~~ the ~~response~~ to ~~Requirement B15 of the PCI HSM Security Requirements manual~~ for consistency.

TB14.3 The tester shall examine the response to Section B14 of the PCI PTS HSM Evaluation Vendor Questionnaire relating to the transfer of a key from a high- security component to a lower-security component, for consistency.

Modified p. 37 → 45

Logs shall not contain clear-text sensitive data.

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

Modified p. 37 → 45

~~TB15.3~~ The tester shall verify that the HSM provides cryptographic mechanisms that allow log data stored within the HSM 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.

TB16.3 The tester shall verify that the HSM provides mechanisms that allow log data stored within the HSM to be protected•e.g., using cryptographic mechanisms that allow log data stored within the HSM 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. 37 → 45

~~a) Key management b) Modification of authentication data c) Software/firmware updates~~ d) Enabling and disabling HSM security functions ~~TB15.5~~ The tester shall verify that the HSM requires dual control to delete secure logs stored internally.

d) Enabling and disabling HSM security functions TB16.5 The tester shall verify that the HSM requires dual control to delete secure logs stored internally.

Removed p. 38

TB16.1 The tester shall examine the vendor’s response to Section B16 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement B16 of the PCI HSM Security Requirements manual for consistency.

TB16.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key management specification) that describes the unique device ID to determine if it supports the assertions made by the vendor.

Modified p. 38 → 49

~~TB16.3~~ The tester shall obtain the unique device ID from the HSM using the methods described in vendor documentation.

TB19.3 The tester shall obtain the unique device ID from the HSM using the methods described in vendor documentation.

Removed p. 39

The authority to execute functions that are not available during normal use•e.g., load a master key, delete stored transactions, alter device configuration, etc.- is controlled through use of a sensitive state or other special authorization that controls the ability to execute these functions.

Key components entered manually constitute sensitive data during entry and the device shall not differentiate via sound or display the entry of different values. The following operations are only permitted when the device performs sensitive services such as:

Disablement/enablement of device functionality Changing of passwords or data that enable the device to enter a sensitive state Configuring or modifying the Security Policy examined in A6 and B13.

TB17.2 The tester shall examine any additional documentation (e.g., API reference, design documentation, key management specification) that describes authentication to determine if it supports the assertions made by the vendor.

TB17.3 The tester shall verify from vendor documentation that the vendor …

Modified p. 39 → 46

TB17.1 The tester shall examine the vendor’s response to Section B17 of the PCI HSM Evaluation Vendor Questionnaire and the response to Requirement B17 of the PCI HSM Security Requirements ~~for consistency.~~

TB17.1 The tester shall examine the vendor’s response to Section B17 of the PCI PTS HSM Evaluation Vendor Questionnaire and the response to Requirement B17 of the PCI PTS HSM Security Requirements to verify that if the device supports multiple applications, it enforces the separation between applications with security impact from those without security impacts. Furthermore, the tester shall examine which part of the firmware is considered OS, and which part is considered as application with security impact.

Removed p. 40

Data inputs cannot be discerned from any displayed characters. Data inputs cannot be discerned by monitoring audible or electro-magnetic emissions. Sensitive data is cleared from internal buffers upon exiting the sensitive mode.

Entering data while accessing sensitive services. Document review.

TB17.8 If mode transitions require input by a separate interface device, such as a key loader or other vendor-supplied interface device, document the mechanism(s) and methodology used.

Removed p. 41

TB18.1 The tester shall examine the response to Section B18 of the PCI HSM Evaluation Vendor Questionnaire relating to the authentication procedures for remote firmware updates, for consistency.

TB18.3 The tester shall verify that the HSM cryptographically authenticates the firmware integrity. This will be accomplished, for example, by performing a simulated firmware update.

TB18.4 The tester shall verify that the HSM rejects unauthorized Firmware. This will be accomplished, for example, by performing a simulated firmware update with inadequate or modified authentication information.

TB18.5 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 are:

Minimum key size in number of bits 112 1024 160 1024/160 DES refers to non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum …

Modified p. 41 → 42

~~TB18.2~~ The tester shall examine any additional documentation (i.e., specifications, ~~schematics,~~ block diagrams, etc.) that contains information that relates to ~~firmware updates~~ to determine if it supports the assertions made by the vendor.

TB14.4 The tester shall examine any additional documentation (i.e., API Programmer’s guide, specifications, block diagrams, etc.) that contains information that relates to any of the aforementioned to determine whether it supports the assertions made by the vendor.

Removed p. 42

2. Exploitation s levels of expe a) Attack time for the variou

Modified p. 42 → 55

a) Attack time for the ~~variou~~

a) Attack time for the various levels of expertise;

Modified p. 42 → 55

b) Potential to acquire the required knowledge of the HS

b) Potential to acquire the required knowledge of the HSM’s design and operation;

Modified p. 42 → 55

b) Potential to acquire the required knowledge of the HS

b) Potential to acquire the required knowledge of the HSM’s design and operation;

Modified p. 42 → 55

c) Potential for the access to the HSM; ~~mponents, IT hardware, software require d) Equipment required like instruments, co analysis;~~

c) Potential for the access to the HSM;

Modified p. 42 → 55

c) Potential for the access to the HSM; ~~mponents, IT hardware, software require d) Equipment required like instruments, co analysis;~~

c) Potential for the access to the HSM;

Modified p. 42 → 55

In many cases these factors don’t depend on ea varying degrees. For example, expertise o of these factors follows.

In many cases these factors don’t depend on each other but might be substituted for each other in varying degrees. For example, expertise or hardware/software can be a substitute for time. A discussion of these factors follows.

Removed p. 43

c) Sensitive information about the HSM (e.g., knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse engineering). ould be take rmation required to exploit it, especially in the area of sensitive information. Requiring sen rmation for exploitation would be unusual. ist expertise and knowledge of the HSM are concerned wi ons to be able to attack an HSM. There is an implicit relationship between an attacker’s expertise and abil ty to effectively make use of equipment in an attack. The weaker the attacker’s expertise, the e potential to effectively use equipment. Likewise, the greater the expe potential for equipment to be used in the attack. Although implicit, this relationship between expertise and the use of equipment does not always apply•for instance, when environmental measures prevent a expert attacker’s use of equipment; or when, thr expertise for effective use are created and freely distributed …

Modified p. 43 → 56

a) Experts are familiar with the underlying algorithms, protocols, hardware, structures, etc. implemented in the product or system type and the principles and concepts of security employe ient persons are knowledgeable in that they are familiar with the security behavior of the If pr enginee Kno generic but not unrelated to it. Identified levels are as follows: can tained by anyone (e.g., from the Internet) or if it is provided by the vendor to any ndor technical Care sh n …

a) Experts are familiar with the underlying algorithms, protocols, hardware, structures, etc. implemented in the product or system type and the principles and concepts of security employed;

Modified p. 43 → 56

~~c) Laymen are unknowledgeable compared to experts or~~ proficient ~~persons, with no particular expertise. oficient~~ expertise on various areas of technology is required for an attack, e.g., on electrical ~~ring~~ and cryptography, an expert level of expertise can be assumed. ~~wledge of the HSM refers to obtaining specific expertise in relation to the HSM. This is different from expertise~~

If proficient expertise on various areas of technology is required for an attack, e.g., on electrical engineering and cryptography, an expert level of expertise can be assumed.

Modified p. 43 → 56

a) Public information about the HSM (or no information): Information is considered public if it be easily ob customer.

a) Public information about the HSM (or no information): Information is considered public if it can be easily obtained by anyone (e.g., from the Internet) or if it is provided by the vendor to any customer.

Modified p. 43 → 56

b) Restricted information concerning the HSM (e.g., as gained from ve specifications): Information is considered restricted if it is distributed on request and the distribution is registered (e.g., like the PCI HSM DTRs).

b) Restricted information concerning the HSM (e.g., as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered (e.g., like the PCI PTS HSM DTRs).

Modified p. 44 → 57

~~Table 1: Multiple Samples Factors Number of Devices Factor~~ Equipment refers to the equipment that is required to identify or exploit vulnerability.

Equipment refers to the equipment that is required to identify or exploit vulnerability.

Modified p. 44 → 57

a) Standard equipment is equipment that is readily available to the attacker, either for the identification of vulnerability or for an attack. This equipment can be readily obtained•e.g., at a ~~simple attack ower h, protocol analyzers, oscilloscopes, microprobe y at its restricted. Alternatively, the equipment may be very or y be used for but could be acquired without undue r a~~ nearby store or downloaded from the Internet. The equipment might consist of scripts, personal computers, card readers, pattern generators, …

a) Standard equipment is equipment that is readily available to the attacker, either for the identification of vulnerability or for an attack. This equipment can be readily obtained•e.g., at a nearby store or downloaded from the Internet. The equipment might consist of simple attack scripts, personal computers, card readers, pattern generators, simple optical microscopes, power supplies, or simple mechanical tools.

Modified p. 44 → 57

b) Specialized equipment isn’t readily available to the attacker, but could be acquired without undue effort. This could include purchase of moderate amounts of equipment (e.g., dedicated electronic cards, specialized test ~~benc~~ workstation, chemical workbench, precise milling machines, etc.) or development of more extensive attack scripts or programs.

b) Specialized equipment isn’t readily available to the attacker, but could be acquired without undue effort. This could include purchase of moderate amounts of equipment (e.g., dedicated electronic cards, specialized test bench, protocol analyzers, oscilloscopes, microprobe workstation, chemical workbench, precise milling machines, etc.) or development of more extensive attack scripts or programs.

Modified p. 44 → 57

c) Bespoke equipment is not readily available to the ~~public~~ as it might need to be ~~speciall~~ produced (e.g., very sophisticated software), or because the equipment is so specialized th distribution is controlled, possibly even ~~expensive (e.g., Focused Ion Beam, Scanning Electron Microscope, and Abrasive Laser Equipment).~~ Bespoke equipment, which can be rented, ~~can~~ be treated as specialized equipment. Software that has been developed during the identification phase is considered as bespoke equipment; it must not additionally be considered ~~for~~ …

c) Bespoke equipment is not readily available to the public, as it might need to be specially produced (e.g., very sophisticated software), or because the equipment is so specialized that its distribution is controlled, possibly even restricted. Bespoke equipment, which can be rented, might have to be treated as specialized equipment. Software that has been developed during the identification phase is considered as bespoke equipment; it must not additionally be considered in the exploitation phase.

Modified p. 44 → 58

Parts refer to components required to hide the signs of an attack; to otherwise replace components that have been broken during an attack, like a case part, a display or a printer; to ~~created~~ data-monitoring communicating bug; or otherwise are needed to perform the attack. If the same part ma identification and exploitation, it must only be accounted for once.

Parts refer to components required to hide the signs of an attack; to otherwise replace components that have been broken during an attack, like a case part, a display or a printer; to create a data-monitoring or communicating bug; or otherwise are needed to perform the attack. If the same part may be used for identification and exploitation, it must only be accounted for once.

Modified p. 44 → 58

b) Specialized parts are not readily available to the attacker effort. These might be parts that can be ordered from the stock but require long delivery time o 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 can be ordered from the stock but require long delivery time or a certain minimum component count for purchase.

Removed p. 45

Table 2: Attack Potential Factors Identification Exploitation < 1 hour 0 0 ≤ 1 day 1 2 ≤ 1 week 2 3 ≤ 1 month 3 4 Attack time > 1 month 5 7 Layman 0 0 Proficient 1 1 Expert 2 3 Multiple Expert 5 6 Public 0 0 Restricted 2 2 Knowledge of the HSM Sensitive 3 4 Mechanical sample 1 1 Functional samples without working keys Access to the HSM per unit required for the attack.

Removed p. 46

First Attack Example The attack aims to insert a PIN-disclosing bug into an HSM. The bug is placed at a position in the device where the PIN is handled in clear, for instance at the keypad or at the ICC reader interface. It is assumed that such an attack is possible. A generic attack consists of the following steps:

1. Reverse-engineer the device and develop the attack models. This step requires professional knowledge of electronic engineering and the capability to perform the mechanical and electronic test required. The modules will break during that phase. It is assumed that the device is protected by tamper-response circuits, which prevent undetected opening of the device, but the points of interest are not covered by a tamper-responsive envelope.

2. The tamper-detection measures have to be deactivated.

3. A PIN-disclosing bug is placed into the HSM (Exploitation Phase).

4. The sensitive data is collected from the HSM.

We assume that …

Removed p. 47

3. Get a HSM and perform the measurement. We expect that at least 20,000 PIN-entry steps and the following encryption have to be observed. In the identification phase, this may have to be repeated several times. Due to the exhaustive PIN search countermeasure, 20,000 PIN entries need at least seven days. Since such an amount of transactions cannot be performed in a real live environment, it must be possible to run the device off-line with a simulated host.

Table 4: Attack Potentials Example for DPA Analysis Aspect Identifying Value Exploiting Value Attack time > 1 month 5 < 1 month 3 Expertise Expert 2 Expert 3 Knowledge of the device Restricted 2 Public 0 Access to HSM Functional sample with trial keys 2 Functional sample with working keys Equipment Bespoke 5 Specialized 4 Specific parts Standard 1 No further parts required Attack Potential per Phase 17 14 As can be seen …

Modified p. 47 → 62

A function of the HSM is used which requires a PIN ~~to be entered for every execution of~~ the cryptographic ~~action with the~~ key under attack; 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 HSM does not have effective countermeasures against DPA.

 A function of the HSM is used which requires PIN translations using the cryptographic key under attack;  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 HSM does not have effective countermeasures against DPA.

Modified p. 47 → 62

2. Develop the attack set-up including the control to run the HSM in an automated way. Since a large number of PIN ~~entries~~ are ~~required, which can hardly be performed manually, special mechanics must be developed to perform the PIN entries.~~ This is bespoke equipment, developed specially for this attack, which will be reused at Identification time.

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.

Modified p. 48 → 63

The sts tool should be configured as per guidance provided in ~~SP800-22,~~ which is summarized below.

The sts tool should be configured as per guidance provided in SP 800-22, which is summarized below.

Modified p. 48 → 63

The following settings are consistent with the ~~SP800-22~~ document:

The following settings are consistent with the SP 800-22 document:

Modified p. 49 → 64

[1] n must be selected to be consistent with the requirements all of the tests to be run. The Overlapping Templates, Linear Complexity, Random Excursions, and Random Excursions Variant tests all require n to be greater than or equal to 106 in order to produce meaningful results. The Non-Overlapping Templates test requires n to equal 106. (See ~~SP800-22~~ Sections 2.7.7, 2.8.7, 2.10.7, 2.11.7, 2.15.7, and 2.16.7) [2] The number of bit sequences (sample size) must be 1,000 or greater in …

[1] n must be selected to be consistent with the requirements all of the tests to be run. The Overlapping Templates, Linear Complexity, Random Excursions, and Random Excursions Variant tests all require n to be greater than or equal to 106 in order to produce meaningful results. The Non-Overlapping Templates test requires n to equal 106. (See SP 800-22 Sections 2.7.7, 2.8.7, 2.10.7, 2.11.7, 2.15.7, and 2.16.7) [2] The number of bit sequences (sample size) must be 1,000 or greater …

Modified p. 49 → 64

[3] For the Block Frequency Test, if n=106, the test block size should be set between 104 and 106. (See ~~SP800-22~~ Section 2.2.7.) [4] The two template tests (Non-Overlapping and Overlapping tests) both require selection of a template length of 9 or 10 in order to produce meaningful results. (See ~~SP800-22~~ Sections 2.7.7 and 2.8.7.) [5] The Universal test block length (L) and initialization steps (Q) must be consistent with the table in ~~SP800-22~~ Section 2.9.7. For n=106, the only …

[3] For the Block Frequency Test, if n=106, the test block size should be set between 104 and 106. (See SP 800-22 Section 2.2.7.) [4] The two template tests (Non-Overlapping and Overlapping tests) both require selection of a template length of 9 or 10 in order to produce meaningful results. (See SP 800-22 Sections 2.7.7 and 2.8.7.) [5] The Universal test block length (L) and initialization steps (Q) must be consistent with the table in SP 800-22 Section 2.9.7. For …

Modified p. 49 → 64

[6] For the Approximate Entropy (ApEn) test, ~~SP800-22~~ Section 2.13.7 requires the block length to be less than , however the sts tool warns if the block size is greater than ~~2 log 2~~ n ~~− ⎢ ⎥ ⎣ ⎦ 2 log~~ 5 ~~n − ⎢ ⎥ ⎣ ⎦~~ (which is consistent with the information in Section 4.3 f). Other analysis [Hill 2004] has shown that for n=1,000,000 values block lengths greater than 8 can cause failures more often than …

[6] For the Approximate Entropy (ApEn) test, SP 800-22 Section 2.13.7 requires the block length to be less than  log2 n  - 2, however the sts tool warns if the block size is greater than  log2 n - 5 (which is consistent with the information in Section 4.3 f). Other analysis [Hill 2004] has shown that for n=1,000,000 values block lengths greater than 8 can cause failures more often than expected for large scale testing.

Modified p. 49 → 64

~~[7] The Serial Test block length is also set based on n. If n=106, the block length must be less than 17.~~ (See ~~SP800-22~~ Section 2.12.7) [8] The Linear Complexity Test block length is required to be set to between 500 and 5,000 (inclusive), and requires that 200 ≥ M n . (See ~~SP800-22~~ Section 2.11.7.) References [Rukhin 2001] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications", NIST ~~SP800-22,~~ revisions dated …

(See SP 800-22 Section 2.12.7) [8] The Linear Complexity Test block length is required to be set to between 500 and 5,000 (inclusive), and requires that 200  M n . (See SP 800-22 Section 2.11.7.) References [Rukhin 2001] Rukhin, Andrew, et al., "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications", NIST SP 800-22, revisions dated May 15, 2001.

Document Comparison

From Revision History

Content Changes