Document Diff - PCI Watch

Added p. 2

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

• Multi-tenant Usage Security Requirements.”

Added p. 2

Note to Assessors When protecting this document for use as a form, leave Section 9, “Device-Specification Sheet” (final page of this document) unprotected to allow for insertion of a device-specification sheet. Under “Review,” select “Restrict Editing,” then “Select sections” (under “Editing restrictions” / “Filling in forms),” and de- select Section 9, as illustrated below.

Added p. 5

• Complete restructure of requirements and applicability matrix.

• Cryptography used for device security purposes implements an effective key strength of 128 bits or stronger.

• Specified additional requirements that must be met in both PCI and non-PCI mode.

• Added new Section D regarding key transfer.

• Added new Section E regarding remote administration.

Added p. 6

Operational considerations are described in the Key Management and Operations Security and Test Requirements.

Added p. 8

• Security techniques

• Part 1: General ISO/IEC 18033-1 Information Technology

Application Version Number: (if applicable) For HSMs and HSM Solutions, designate whether restricted to deployment in an environment meeting at least the security requirements of a controlled environment as defined in the Key Management and Operations Security and Test Requirements.

At the end of this document, under “Device-Specification Sheet,” attach a sheet highlighting device characteristics, including photos. These photos are to include both external and internal pictures of the device. The internal pictures are to be sufficient to show the various components of the device.

Added p. 13

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

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

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

Added p. 14

B7 If random numbers are generated by the device in connection with the security of sensitive data, the random-number generator has been assessed to ensure that it is generating sufficiently unpredictable numbers.

B8 The device uses accepted cryptographic algorithms, modes, and key sizes as enumerated in the PCI HSM DTR document, “Appendix D: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.” B9 The key-management techniques implemented in the device conform to ISO 11568 and/or ANSI X9.24.

B11 The device ensures that each cryptographic key is only used for a single cryptographic function. The device does not permit any of the key-usage information to be changed in any way that allows the key to be used in ways that were not possible before the change.

Added p. 15

B19 The device shall be designed to be delivered in a secure state to the end customer unless explicitly authorized by the target customer ahead of delivery. The device must support the ability to erase all sensitive data and configuration settings at its end-of-life or prior to transfer and re-deployment.

B20 Devices that support direct connection to switched networks support the use of a logical secure channel across that interface. Direct wireless connections are not supported by the HSM.

Added p. 17

Manual Direct Network Cleartext keys No Yes No Cleartext key components Yes Yes No Enciphered keys/components Yes Yes Yes Signed under a trusted key (Public keys only) Yes Yes Yes D2 Where keys are manually entered or manually exported:

• Cleartext keys can only be manually entered as components.

• Cleartext keys can only be manually exported as components.

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

• Keypads, ICCRs, and other interfaces provided by the HSM vendor for use in the entry of key components are protected by the tamper-detection mechanisms that have been assessed in DTR A1.

D3 Where the device is designed to send or receive keys electronically over direct connections:

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

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

• The device supports …

Added p. 18

• The signed message or certificate must include key-usage attributes or equivalent techniques to limit the potential misuse of the imported key.

• The verification key shall be loaded only using one of the allowable techniques in D1.

Added p. 19

E2 The device is designed in such a way that it cannot be used for or with remote administration until the device has been provisioned. Provisioning includes all initial keys, configuration settings, and other relevant material required to establish secure remote communications. The device can also be decommissioned if required (e.g., lost or stolen), which prevents it from performing remote administration.

E3 The target device and remote terminal must include support for:

• Identification of the target device with cryptographic authentication,

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

• Retrieval of logs useful for reconstructing security incidents.

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

E4 Cryptography used for remote administration must provide at least 128 bits of security. The protocol used shall provide forward secrecy and mutual authenticity. Random numbers used for security purposes shall have been assessed in B7 or use …

Added p. 20

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

Added p. 22

Number Description of Requirement Yes No N/A G1 Change-control procedures are in place so that any intended change to the physical or functional capabilities of the device causes a re- certification of the device under the impacted security requirements of this document. Immediate recertification is not required for changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality.

G2 The firmware and any changes thereafter have been inspected and reviewed using a documented and auditable process and verified by the vendor as being free from hidden, unauthorized, or undocumented functions.

G3 The certified firmware is protected and stored in such a manner as to preclude unauthorized modification during its entire manufacturing life cycle•e.g., using dual-control or standardized cryptographic authentication procedures.

G4 The device is assembled in a manner that the hardware components used in the manufacturing process …

Added p. 23

G8 Security measures are taken during the development and maintenance of device’s security-related components. The manufacturer must maintain development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of the design and implementation of the device’s security-related components in their development environment. The development-security documentation shall provide evidence that these security measures are followed during the development and maintenance of the device’s security- related components. The evidence shall justify that the security measures provide the necessary level of protection to maintain the integrity of the device’s security-related components.

G9 Controls exist over the repair process and the subsequent inspection/testing process to ensure that the device has not been subject to unauthorized modification.

G10 Cryptographic keys used in connection with the establishment of remote administration for use by HSM users are protected and stored in such a manner as to preclude unauthorized modification or …

Added p. 26

Functionality Description Direct Key Loading Functionality allowing for key loading using a directly connected cable.

HSM Cluster Functionality that allows a group of physical HSMs to appear as a single device.

Partitioned HSM An HSM that can be partitioned and appears to users as multiple separate HSMs.

PIN Processing Functionality related to the handling of PINs in transaction processing.

Processes Operational Keys Functionality that must be met by all devices that handle cryptographic keys used for payment operations.

Remote Administration Functionality related to remote administration applies to HSMs that can be remotely administered, as well as Remote Administration Platforms.

For the following approval classes, the functionalities listed below are required or optionally supported.

Added p. 30

Account Data Account data consists of cardholder data and/or sensitive authentication data.

Added p. 32

Derivation keys are normally used in a transaction-receiving⎯e.g., acquirer⎯SCD in a one-to-many relationship. These keys are used to derive or decrypt the Transaction Keys (the derived keys) used by a large number of originating SCDs⎯e.g., terminals.

Added p. 33

Dual Control A process of utilizing two or more separate individuals operating in concert to protect sensitive functions or information, whereby no single individual is able to use the function or access all the information alone⎯e.g., a cryptographic key.

Added p. 34

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

• Fixed Key A key-management system where an operational key is loaded into a system and cannot be

• replaced without physical access to the system. The definition of

• fixed key does not include implementations where it is possible to replace a key but operationally the key is not replaced. The definition of

• fixed key also does not include systems that load a

Added p. 35

1. Smart cards used for components, or that share transport or storage.

2. Smart cards containing public/private key pair(s) used to facilitate management of HSMs.

3. Devices used to authorize or enable key-management functions.

Hash-based Message Authentication Code (HMAC) An authentication code that is produced using hash algorithms rather than a symmetric cryptographic algorithm. Defined in FIPS 198-1. See message authentication code (MAC).

HSM Cluster A group of HSMs interconnected for the purposes of load sharing, fault tolerance, and scalability.

HSM Processing Solution The sum of the HSM processing element and HSM virtualization system, which is exposed to the user as the “Cloud HSM” to which they interface.

HSM-as-a-Service (HaaS) A service provided by an external entity, which provides access to HSM systems, and functionality to multiple HSM tenants.

Added p. 37

Key Check Value (KCV) A value cryptographically related to the key (or key constituent material) that is used to identify that key (or key constituent material) without directly revealing any bits of the actual key (or key constituent material) itself. Also known as key verification check (KVC).

Key Hierarchy A multi-level structure where keys at higher levels of the structure are used to encrypt or derive other keys at lower levels of the structure. A key hierarchy will often have a single key at the highest level of the key hierarchy, to which all other keys are subordinate. Keys at the lowest level of the hierarchy are often used for cryptographic operations on specific data (PINs, PAN, etc.), and may be called “working keys” or “operational keys.” Key Loading Process by which a key is manually or electronically transferred into a secure cryptographic device.

Added p. 39

Mode of Operation The method by which a cryptographic algorithm is applied to a set of data, such as Electronic Code Book (ECB) or Cipher Block Chaining (CBC). Many different modes of operation exist for each encryption algorithm.

Partitioned HSM A single hardware device that supports functionality allowing it to appear as multiple independent logical devices. Each HSM partition includes, at a minimum, independent storage for cryptographic key/s, configuration settings, and access controls. HSM partitions are strongly isolated such that compromise or misbehavior in one partition does not affect the security of other partitions, and are therefore suitable for use in multi- tenant environments.

Added p. 40

PCI Mode Restricted mode of operation where constraints on operations exist to comply with requirements in PCI-HSM. These are enforced for all or part of a system (i.e., key hierarchy). In PCI mode, restrictions in functionality apply, including cryptographic algorithms and protocols that meet these HSM Security Requirements. PCI mode is the mode of HSM operation that was used by the laboratory during the validation of PCI HSM requirements. HSMs not configured to be operated in PCI mode are not guaranteed to meet any of the PCI HSM requirements, except for those specifically noted as applying to both PCI mode and non-PCI mode.

Post Quantum Cryptography (PQC) Cryptographic methods that are deemed to be secure against attacks by both classical and quantum computers. Often refers to algorithms developed exclusively for this purpose.

Added p. 41

Random The process of generating values with a high level of entropy and that satisfy various qualifications, using cryptographic and hardware-based “noise” mechanisms. This results in a value in a set that has equal probability of being selected from the total population of possibilities, hence is unpredictable.

Added p. 42

Secure Channel A physically or logically protected connection between two points.

Added p. 43

Storage Key A key maintained by an HSM for the purposes of securing other keys through the use of encryption. Storage keys are usually maintained inside the tamper-responsive boundary of the HSM. Storage keys are sometimes referred to as Master File Keys (MFKs).

Added p. 44

Tamper Key The key used to protect through encryption all or some subset of working keys. This key may be known as the “storage master,” “local master,” “master file,” or “housekeeping” key, or by many other potential names.

Unique-Key-Per Transaction (UKPT) A key-management method that ensures each session key is unique and uncorrelated with any previous sessions. The key-management method defined in ANSI X9.24 as Derived Unique Key Per Transaction (DUKPT) is an example of UKPT key management.

Removed p. 1

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

Removed p. 2

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

• Multi-tenant Usage Security Requirements.” Note to Assessors When protecting this document for use as a form, leave Section 12 (final page of this document) unprotected to allow for insertion of a device-specification sheet. Under “Tools / Protect Document,” select “Forms” then “Sections,” and un-check Section 12 as illustrated below.

Modified p. 2

April 2009 1.0 ~~PCI~~ Initial ~~Release~~

April 2009 1.0 Initial release

Modified p. 2

February 2012 2.x ~~PCI~~ RFC version - Modifications for consistency with PCI POI requirements.

February 2012 2.x RFC version • Modifications for consistency with PCI POI requirements.

Modified p. 2

May 2012 2.0 ~~PCI~~ Public release

May 2012 2.0 Public release

Modified p. 2

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

February 2016 3.x RFC version

Removed p. 3

• General Information

Modified p. 5 → 4

This document provides vendors with a list of all the security requirements against which their products will be evaluated in order to obtain Payment Card Industry (PCI) PIN Transaction Security (PTS) Hardware Security Module (HSM) device approval.

This document provides vendors with a list of all the security requirements against which their products will be evaluated in order to obtain Payment Card Industry (PCI) PIN Transaction Security (PTS) Hardware Security Module (HSM) device approval. This document is used in conjunction with the PCI PTS Modular Derived Security Requirements, which provides specific direction to vendors on methods the laboratories may apply when testing against the Security Requirements.

Modified p. 5 → 4

• Key injection There are many other applications and processes that may utilize general-purpose HSMs, and which may necessitate the adoption of ~~all~~ or a subset of the requirements listed in this document. However, this document does not aim to develop a standard for general-purpose HSMs for use outside of applications such as those listed above that are in support of a variety of payment-processing and cardholder- authentication applications and processes for the financial payments industry.

• Key injection There are many other applications and processes that may utilize general-purpose HSMs, and which may necessitate the adoption of all, or a subset of, the requirements listed in this document. However, this document does not aim to develop a standard for general-purpose HSMs for use outside of applications such as those listed above that are in support of a variety of payment-processing and cardholder- authentication applications and processes for the financial payments industry.

Modified p. 7 → 6

These HSM security requirements were derived from existing ISO, ANSI, and NIST ~~standards;~~ and ~~accepted/known good practice~~ recognized by the financial payments industry.

These HSM security requirements were derived from existing ISO, ANSI, and NIST standards, and accepted/known-good practices recognized by the financial payments industry.

Modified p. 7 → 6

Evaluation Domains Device characteristics are those attributes of the device that define its physical and ~~its~~ logical (functional) characteristics. The physical security characteristics of the device are those attributes that deter a physical attack on the device, for example, the penetration of the device to determine its key(s) or to plant a sensitive data-disclosing “bug” within it. Logical security characteristics include those functional capabilities that preclude, for example, allowing the device to output a ~~clear-text PIN- encryption~~ key.

Evaluation Domains Device characteristics are those attributes of the device that define its physical and logical (functional) characteristics. The physical security characteristics of the device are those attributes that deter a physical attack on the device, for example, the penetration of the device to determine its key(s) or to plant a sensitive data-disclosing “bug” within it. Logical security characteristics include those functional capabilities that preclude, for example, allowing the device to output a cleartext PIN-encryption key.

Modified p. 7 → 6

This document is concerned with the device management for HSM devices only up to receipt at the point of deployment. Subsequent to receipt of the device at the point of deployment, the responsibility for the device falls to the acquiring financial institution and its agents⎯e.g., merchants and processors⎯and is covered by the operating rules of the participating PCI ~~Payment Brands~~ and other security requirements, such as the PCI ~~PIN~~ Security Requirements.

This document is concerned with the device management for HSM devices only up to receipt at the point of deployment. Subsequent to receipt of the device at the point of deployment, the responsibility for the device falls to the acquiring financial institution and its agents⎯e.g., merchants and processors⎯and is covered by the operating rules of the participating PCI payment brands and other security requirements, such as the PCI Key Management and Operations Security and Test Requirements.

Modified p. 8 → 7

Publication Title Reference Retail Financial Services - Symmetric Key Management ANSI X9.24 Public-key Cryptography for the Financial Service Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography ANSI X9.42 Key Establishment Using Integer Factorization Cryptography ANSI X9.44 Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography Symmetric Key Cryptography for the Financial Services Industry•Wrapping of Keys and Associated Data ANSI X9.102 Public Key Cryptography: The Elliptical Curve Digital Signature Algorithm (EDCSA) ANSI …

Publication Title Reference Retail Financial Services - Symmetric Key Management ANSI X9.24 Public-key Cryptography for the Financial Service Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography ANSI X9.42 Key Establishment Using Integer Factorization Cryptography ANSI X9.44 Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography ANSI X9.63 Symmetric Key Cryptography for the Financial Services Industry•Wrapping of Keys and Associated Data ANSI X9.102 Public Key Cryptography: The Elliptical Curve Digital Signature Algorithm …

Modified p. 9 → 8

• Part 5: Identity Based Ciphers ISO/IEC 18033-5 Guidelines on Triple DES Modes of Operation ISO TR 19038 Banking and related financial services -- Key wrap using AES ISO 20038 A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications NIST SP 800-22 Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication NIST SP 800-38B Recommendations for Key Management: Part 1

• General NIST SP 800-57 Recommendation for the Triple Data Encryption Algorithm (TDEA) Block …

Removed p. 10

December 2021 HSM Identifier Device Manufacturer:

Application Version Number: (if applicable) Designed for deployment only in an environment meeting at least the security requirements of a controlled environment as defined in ISO 13491-2? At the end of this form under “Device Specification Sheet,” attach documentation highlighting device characteristics, including photos. These photos are to include both external and internal pictures of the device. The internal pictures are to be sufficient to show the various components of the device.

Modified p. 10 → 9

Use of “x” represents a request for field to be a variable.

Hardware Version NumberA: Use of “x” represents a request for the field to be a variable.

Modified p. 10 → 9

Use of “x” represents a request for field to be a variable.

Firmware Version NumberA: Use of “x” represents a request for the field to be a variable.

Modified p. 10 → 9

A See “Optional Use of Variables in the Identifier,” following page.

A See “Optional Use of Variables in the Device Identifier,” following page.

Removed p. 12

A5 Emanations from the device (including power fluctuations and timing) cannot be feasibly used to recover PIN and/or account data or other PCI security-related cryptographic keys resident in the device.

Modified p. 12 → 11

Number Description of Requirement Yes No N/A A1 The device uses tamper-detection and response mechanisms that cause it to become immediately inoperable and result in the automatic and immediate erasure of any sensitive data that may be stored in the device, such that it becomes ~~infeasible~~ to recover the sensitive data. These mechanisms protect against physical penetration of the ~~device.~~ There is no demonstrable way to disable or defeat the mechanisms and access internal areas containing sensitive information without requiring …

Number Description of Requirement Yes No N/A A1 The device uses tamper-detection and response mechanisms that cause it to become immediately inoperable and result in the automatic and immediate erasure of any sensitive data that may be stored in the device, such that it becomes impractical to recover the sensitive data. These mechanisms protect against physical penetration of the device by means of (but not limited to) drills, lasers, chemical solvents, opening covers, splitting the casing (seams), and use of …

Modified p. 12 → 11

A3 Sensitive functions or information are only used in the protected area(s) of the device. Sensitive information and functions dealing with sensitive information are protected from unauthorized modification or substitution, without requiring an attack potential of at least 26 per device for identification and initial exploitation, with a minimum of 13 for initial ~~exploitation B.~~

A3 Sensitive functions or information are only used in the protected area(s) of the device. Sensitive information and functions dealing with sensitive information are protected from unauthorized modification or substitution, without requiring an attack potential of at least 26 per device for identification and initial exploitation, with a minimum of 13 for initial exploitationB.

Modified p. 12 → 11

A4 Determination of any ~~PCI-related~~ secret or private cryptographic key resident in the device or used by the ~~device, by~~ penetration of the device ~~requires~~ an attack potential of at least 35 for identification and initial ~~exploitation~~ with a minimum of 15 for initial exploitationB.

A4 Determination that any PCI security-related secret or private cryptographic key resident in the device or used by the device

•by penetration of the device •requires an attack potential of at least 35 for identification and initial exploitation, with a minimum of 15 for initial exploitationB.

Removed p. 13

• The transaction is completed,

B6 Access to sensitive services requires authentication. Sensitive services provide access to the underlying sensitive functions. Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords/authentication codes. Entering or exiting sensitive services shall not reveal or otherwise affect sensitive data.

Modified p. 13

Number Description of Requirement Yes No N/A B1 To ensure that the device is operating as designed, the device runs self-tests (a) when pre-operational and at least once per day or (b) using continuous error checking, to check firmware (authenticity check), security mechanisms for signs of tampering, and whether the device is in a compromised state. When specific critical operations are performed, the device performs conditional tests. The techniques and actions of the device upon failure of a self-test are …

Modified p. 13

The device’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 device outputting sensitive information.

The device’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, or supplying wrong parameters or data that could result in the device outputting sensitive information.

Modified p. 13

B3.1 If the device supports applications, the firmware must ~~support~~ the authentication of applications loaded into the device consistent with B3.

B3.1 If the device supports applications, the firmware must enforce the authentication of applications loaded into the device consistent with B3.

Modified p. 13

B4 The device provides secure interfaces that are kept logically ~~separate~~ by distinguishing between data and control for ~~inputs~~ as well as between data and status for outputs.

B4 The device provides secure interfaces that are kept logically separated by distinguishing between data and control for inputs, as well as between data and status for outputs.

Modified p. 13

• The device has timed out, or

• The device has timed out,

Modified p. 13

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

• The device recovers from an error state,

Removed p. 14

Manual Direct Network Clear-text keys No Yes No Clear-text key components Yes Yes No Enciphered keys/components Yes Yes Yes B8 If random numbers are generated by the device in connection with security over sensitive data, the random number generator has been assessed to ensure that it is generating sufficiently unpredictable numbers.

B12 The device ensures that each cryptographic key is only used for a single cryptographic function. It is not possible to encrypt or decrypt any arbitrary data using any PIN-encrypting key, account-data encryption, data-encrypting key, or key-encrypting key contained in or protected by the device. The device does not permit any of the key- usage information to be changed in any way that allows the key to be used in ways that were not possible before the change.

Modified p. 14

B10 ~~The key-management techniques implemented in the device conform to ISO 11568 and/or ANSI X9.24. Key-management techniques must support key blocks as defined in DTR 77 B11~~ The device ensures that if cryptographic keys within the secure device boundary are rendered invalid for any reason⎯e.g., ~~tamper~~ or long-term absence of applied power⎯the device will fail in a secure manner.

B10 The device ensures that if cryptographic keys within the secure device boundary are rendered invalid for any reason⎯e.g., tampering or long-term absence of applied power⎯the device will fail in a secure manner.

Modified p. 14

~~B13~~ There is no mechanism in the device that would allow the outputting of 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~~ critical security parameters (CSPs) to components that could negatively impact security.

B12 There is no mechanism in the device that would allow the outputting of private or secret cleartext keys, the encryption of a key or PIN under a key that might itself be disclosed, or the transfer of a cleartext key from a component of high security into a component of lesser security. All cryptographic functions implemented shall not output cleartext critical security parameters (CSPs) to components that could negatively impact security.

Modified p. 14

~~B14~~ If the device is designed to be used for PIN management, the device shall meet the PIN-management requirements of ISO 9564. The PIN- encryption technique implemented in the device is a technique included in ISO 9564.

B13 If the device is designed to be used for PIN management, the device shall meet the PIN-management requirements of ISO 9564. The PIN- encryption technique implemented in the device is a technique included in ISO 9564.

Modified p. 14

~~B15~~ The device includes cryptographic mechanisms to support secure logging of transactions, data, and events, to enable auditing.

B14 The device includes cryptographic mechanisms to support secure logging of transactions, data, and events, in order to enable auditing.

Modified p. 14 → 18

~~B9 The device uses accepted cryptographic algorithms, modes,~~ and key sizes.

• Use only allowed algorithms and key sizes.

Modified p. 15

~~B17~~ The operating system/firmware of the device must contain only the software (components and services) necessary for the intended operation. The operating system/firmware must be configured securely and run with least privilege.

B16 The operating system/firmware of the device must contain only the software (components and services) necessary for the intended operation. The operating system/firmware must be configured securely and run with least privilege.

Modified p. 15

~~B18~~ The device has the ability to return its unique device ID.

B17 The device has the ability to return its unique device ID.

Modified p. 15

~~B19~~ Devices that are designed to include both a PCI mode and a non-PCI mode must not share secret or private keys between the two modes, must provide indication as to when the device is in PCI mode and not in PCI mode, and must require dual authentication when switching between the two modes.

B18 Devices that are designed to include both a PCI mode and a non-PCI mode must not share secret or private keys between the two modes, must provide indication as to when the device is in PCI mode and not in PCI mode, and must require dual authentication when switching between the two modes.

Removed p. 17

D2 If the device is capable of generating symmetric keys or asymmetric key pairs that are not used by the device, the key or key pair and all related secret and private seed elements are deleted immediately after the transfer process.

D3 The device retains no information that could disclose any key that the device has already transferred into another cryptographic device.

D4 If the device is composed of several components, it is not possible to move a secret or private key within the device from an asset domain of higher security to an asset domain providing lesser security.

D5 Once the device has been loaded with cryptographic keys, there is no feasible way in which the functional capabilities of the device can be modified without causing the automatic and immediate erasure of the cryptographic keys stored within the device or causing the modification to be otherwise detected before the device is next …

Removed p. 18

E2 The following operator functions that may influence the security of a device are permitted only when the device is in a sensitive state•i.e., under dual or multiple control:

• Disabling or enabling of device functions

• Change of passwords/authentication codes or data that enable the device to enter the sensitive state.

The secure operator interface is so designed that entry of more than one password/authentication code (or some equivalent mechanism for dual or multiple control) is required in order to enter this sensitive state and that it is highly unlikely that the device can inadvertently be left in the sensitive state.

Removed p. 19

F2 The length of the MAC being generated or verified is in accordance with ISO 16609.

F3 If the device uses two keys for MAC generation or verification, the technique utilized is in accordance with ISO 16609.

F4 If the message authentication device is designed to use unidirectional MAC keys, a MAC key is only used for one type of MAC function•i.e., verify the MAC of received text or generate and output a MAC for a text being transmitted.

Removed p. 20

• The device includes mechanisms such that the removal of the device from its operational location will cause the automatic erasure of the cryptographic keys contained within the device; or

• Removal of the device would be of no benefit because its tamper- resistance or tamper-responsive characteristics ensure that the extraction of cryptographic keys or other secret data is not feasible.

G2 The device will not output any clear-text key except under dual control. Such dual control is enforced by means such as the following:

• The device requires that at least two passwords/authentication codes be correctly entered within a period of no more than five minutes before the device will output a key.

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

G3 The following operator functions (if available) require the use of sensitive …

Removed p. 21

• The asymmetric private and public key pair is generated within the digital signature device; and

• The asymmetric private key is only exported outside the original digital signature device under dual control; and

• Mechanisms for the control of the use of the private key are provided.

H2 For audit and control purposes, the binding between the public key and the identity of the owner of the private key is readily determined by:

• Use of public key certificates, where the public key certificate was obtained from an authorized certificate authority⎯e.g., the vendor’s PKI; or

• Use of public key certificates and appropriate certificate management procedures; or

• Other equivalent mechanisms to irrefutably determine the identity of the owner of the corresponding private key.

Removed p. 22

I2 HSM virtualization systems must be either:

• Installed and operated in an environment meeting at least the security requirements of a controlled environment, or

I3 HSM virtualization systems that provide for switching/routing of secure channels between the HSM Solution Consumer and one or more HSM processing elements, must manage the cryptographic keys and operations used for these functions within a tamper-responsive system (to attack potential of at least 26 per HSM virtualization system for identification and initial exploitation, with a minimum of 13 for initial exploitationA.

Modified p. 22 → 20

~~• Protect the stored and processed~~ sensitive data to an attack potential of at least 26 per HSM ~~virtualization system~~ for identification and initial exploitation, with a minimum of 13 for initial ~~exploitationA.~~

Devices restricted to deployment in controlled (or higher) environments protect sensitive data to an attack potential of at least 26 per HSM processing element for identification and initial exploitation, with a minimum of 13 for initial exploitation.

Modified p. 22 → 20

I4 Where the HSM processing element and HSM virtualization system are contained in the same physical execution environment, the HSM virtualization system must meet all HSM processing element security requirements.

F2 Where the HSM processing element and HSM virtualization system are contained in the same physical execution environment, the HSM virtualization system must meet all HSM processing element security requirements.

Modified p. 22 → 20

I5 The HSM processing element must ensure that ~~clear-text~~ secret and private keys are processed in execution paths and memory areas that are isolated from keys of any other HSM ~~Solution Consumer~~ and/or code that is not included in the scope of the HSM processing element evaluation.

F3 The HSM processing element must ensure that cleartext secret and private keys are processed in execution paths and memory areas that are isolated from keys of any other HSM Tenant and/or code that is not included in the scope of the HSM processing element evaluation.

Modified p. 22 → 20

A As defined in Appendix A of the PCI HSM DTRs.

C As defined in Appendix A of the PCI HSM DTRs.

Removed p. 23

J2 Each HSM processing element must require the use of cryptographic methods for identification and authentication prior to the provisioning of secret keys, or establishment of any logical secure channel.

J3 Operations performed with the cryptographic keys of an HSM Solution Consumer must require a cryptographically verifiable approval or request from the key owner.

J4 Clear-text sensitive data, including PINs and secret/private cryptographic keys, must never be exposed outside of an HSM processing element. Clear-text cardholder data, including PAN data, must be managed within an HSM processing element or an environment compliant to PCI DSS.

J5 All key-management operations involving the cryptographic key of HSM Solution Consumers, including validation of key wrapping, must be performed within the HSM processing element.

J7 Each HSM Solution must be able to provide a cryptographically verifiable, unique ID that includes unique identification of the hardware and firmware versions of each HSM processing element and HSM virtualization system used …

Modified p. 23 → 20

J6 All HSM processing element storage areas, temporary or otherwise, must be cleared of sensitive data prior to allowing processing using a set of cryptographic keys belonging to another HSM ~~Solution Consumer. This includes but is not limited to registers, cache, scratchpad memory, etc.~~ Erasure must accommodate ~~for~~ any memory virtualization or wear-leveling implemented in the system.

All HSM processing element storage areas, temporary or otherwise, must be cleared of sensitive data prior to allowing processing using a set of cryptographic keys belonging to another HSM Tenant. Erasure must accommodate any memory virtualization or wear-leveling implemented in the system.

Modified p. 23 → 20

J8 Firmware updates for HSM processing elements must be signed using a dual-control process, using cryptographic keys maintained within a FIPS ~~140-2/3 level~~ 3 or higher HSM or a PCI-approved HSM. The firmware update method must prevent installation of any version of firmware older than the currently installed ~~version~~ unless ~~all cryptographic keys are erased from~~ the ~~HSM processing element.~~

F5 Firmware updates for HSM processing elements must be signed using a dual-control process, using cryptographic keys maintained within a FIPS 140-3 Level 3 or higher HSM or a PCI-approved HSM. The firmware update method must prevent installation of any version of firmware older than the currently installed version, unless the firmware downgrade occurs as a sensitive service compliant with DTR B6.

Removed p. 24

K2 Updates to the HSM Solution that may impact the configuration or operation of that solution must be approved by the HSM Solution Consumers prior to implementing the change. If the HSM Solution Consumer is able to update or configure the firmware and/or settings of the HSM Solution with which they interface, such configuration must be isolated from any other HSM Solution Consumers.

K3 Changes to HSM configuration options that may affect the compliance of an HSM Solution Customer must be cryptographically authenticated. Changes made by one HSM Solution Consumer must not affect the compliance status of any other HSM Solution Consumer.

K6 The HSM Solution must support the ability to disable or suspend access to cryptographic keys owned by an HSM Solution Consumer for any HSM processing element K7 It must be possible for an HSM Solution Consumer to maintain an external log of all HSM operations, indicating which HSM virtualization …

Modified p. 24 → 20

K4 The HSM processing element must establish a unique provisioning key for each HSM ~~Solution Consumer.~~ Key establishment must implement a key-agreement process, such as Diffie-Hellman, ~~which~~ provides perfect forward secrecy.

F6 The HSM processing element must securely establish a unique provisioning key for each HSM Tenant for any online-based provisioning. Key establishment must implement a key-agreement process, such as Diffie-Hellman, that provides perfect forward secrecy.

Modified p. 24 → 20

K5 HSM processing element tamper keys used to protect the keys of more than one HSM ~~Solution Consumer~~ must be unique per HSM processing element. This key must be generated within the HSM processing element using an approved ~~random number generation~~ process, and must not be exportable, or able to be disclosed, outside of the HSM by any means.

F7 HSM processing element tamper keys used to protect the keys of more than one HSM Tenant must be unique per HSM processing element. This key must be generated within the HSM processing element using an approved random-number-generation process, and must not be exportable, or able to be disclosed, outside of the HSM by any means.

Removed p. 25

K10 The HSM Solution must implement a public vulnerability management and disclosure policy. This must provide:

Modified p. 25 → 23

• Ranking and addressing vulnerabilities in a timely ~~matter, and~~

• Ranking and addressing vulnerabilities in a timely manner,

Modified p. 25 → 23

• Methods for any HSM ~~Solution Consumers of the HSM Solution~~ to be informed of the ~~vulnerabilities.~~

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

Removed p. 26

Number Description of Requirement Yes No N/A L1 Change-control procedures are in place so that any intended change to the physical or functional capabilities of the device causes a re- certification of the device under the impacted security requirements of this document. Immediate re-certification is not required for changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality.

L2 The firmware and any changes thereafter have been inspected and reviewed using a documented and auditable process and verified by the vendor as being free from hidden and unauthorized or undocumented functions.

L3 The certified firmware is protected and stored in such a manner as to preclude unauthorized modification during its entire manufacturing lifecycle•e.g., using dual control or standardized cryptographic authentication procedures.

L4 The device is assembled in a manner that the hardware components used in the manufacturing …

Removed p. 27

Authentication by secret information is mandatory in HSM v4.

L8 Security measures are taken during the development and maintenance of device’s security-related components. The manufacturer must maintain development-security documentation describing all the physical, procedural, personnel, and other security measures that are necessary to protect the integrity of the design and implementation of the device’s security-related components in their development environment. The development-security documentation shall provide evidence that these security measures are followed during the development and maintenance of the device’s security- related components. The evidence shall justify that the security measures provide the necessary level of protection to maintain the integrity of the device’s security-related components.

L9 Controls exist over the repair process and the subsequent inspection/testing process to ensure that the device has not been subject to unauthorized modification.

Modified p. 28 → 24

Number Description of Requirement Yes No N/A M1 The device should be protected from unauthorized modification with tamper-detection security features, and customers shall be provided with documentation ~~(both shipped~~ with the product ~~and~~ available securely online) that provides instruction on validating the authenticity and integrity of the device.

Number Description of Requirement Yes No N/A H1 The device should be protected from unauthorized modification with tamper-detection security features, and customers shall be provided with documentation (shipped with the product and/or available securely online) that provides instruction on validating the authenticity and integrity of the device.

Modified p. 28 → 24

Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing is compliant with this requirement.

Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing are compliant with this requirement.

Modified p. 28 → 24

M2 Procedures are in place to transfer accountability for the device from the manufacturer to the facility of initial deployment. Where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment. In the absence of defined agreements stipulating otherwise, the device vendor remains responsible.

H2 Procedures are in place to transfer accountability for the device from the manufacturer to the facility of initial deployment. Where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment. In the absence of defined agreements stipulating otherwise, the device vendor remains responsible.

Modified p. 28 → 24

M3 While in transit from the manufacturer’s facility to the facility of initial deployment, the device is:

H3 While in transit from the manufacturer’s facility to the facility of initial deployment, the device is:

Modified p. 28 → 24

M4 The device’s development-security documentation must provide means to the facility of initial deployment to assure the authenticity of the ~~TOE’s~~ security-relevant components.

H4 The device’s development-security documentation must provide means for the facility of initial deployment to assure the authenticity of the device’s security-relevant components.

Removed p. 29

M6 If the manufacturer is not in charge of initial key loading, the manufacturer must provide the means to the facility of initial deployment to assure the verification of the authenticity of the device’s security-related components.

Modified p. 29 → 25

M7 Each device shall have a unique visible identifier affixed to it

•i.e., model name and hardware version

•and shall be retrievable by a query using secure, cryptographically protected methods.

H7 Each device shall have a unique visible identifier affixed to it

•i.e., model name and hardware version

•and shall be retrievable by a query using secure, cryptographically protected methods.

Modified p. 29 → 25

M8 The vendor must maintain a manual that provides instructions for the operational management of the device. This includes instructions for recording the entire ~~lifecycle~~ of the device’s security-related components and the manner in which those components are integrated into a single device⎯e.g.:

H8 The vendor must maintain a manual that provides instructions for the operational management of the device. This includes instructions for recording the entire life cycle of the device’s security-related components and the manner in which those components are integrated into a single device⎯e.g.:

Removed p. 30

• General Information This form and the requested information are to be completed and returned along with the completed information in the applicable Evaluation Module forms.

Device Manufacturer Information Device Manufacturer:

City: State/Province:

Removed p. 31

Model Name and Number: I, (Name) Am an officer of the above company, authorized to verify compliance of the referenced equipment.

Am an officer of the designated laboratory, authorized by the manufacturer to verify compliance of the referenced equipment.

I hereby attest that the above-referenced model of device is:

In full compliance with the standards set forth above in this document Not in full compliance with the standards set forth above in this document as indicated in the attached Exception Form (Form C).

Signature  Date  Printed Name  Title  At the end of this form under “Device Specification Sheet,” attach a sheet highlighting device characteristics, including photos. These photos are to include both external and internal pictures of the device. The internal pictures are to be sufficient to show the various components of the device.

Removed p. 32

Model Name and Number:

Removed p. 33

Functionality Description HSM This is functionality that must be met by all HSM approval classes as delineated in Appendix B•i.e., Hardware Security Module, Key-Loading Device, Remote Administration Platform and Multi-tenant HSM.

Key-Loading Devices This is functionality that must be met by devices that perform key injection of either clear-text or enciphered keys or their components. The devices may perform other services such as key generation.

Remote Administration This is for platforms that are used for remote administration of HSMs. Such administration may include device configuration and key-loading services.

Multi-tenant HSM This is functionality that must be met by HSMs intended for multi-tenant usage•i.e., concurrent multi-organizational usage.

Remote-managed HSM This is functionality that must be met by HSMs that will be remotely managed and are dedicated for usage by a specific organization.

Requirement Key Loading Multi-tenant Remote-Man.

Modified p. 34 → 26

For compound devices, it is possible that these requirements are met or exceeded by the relevant module(s) if the corresponding requirements are fully covered; however, it remains up to the testing ~~house’s~~ judgment to evaluate on a case-by-case basis whether supplementary testing is required.

For compound devices, it is possible that these requirements are met or exceeded by the relevant module(s) if the corresponding requirements are fully covered; however, it remains up to the testing laboratory’s judgment to evaluate on a case-by-case basis whether supplementary testing is required.

Modified p. 38 → 30

Advanced Encryption ~~Algorithm~~ (AES) The Advanced Encryption Standard (AES), also known as Rijndael, is a block cipher adopted as an encryption standard by the U.S. government. It has been analyzed extensively and is now used worldwide, as was the case with its predecessor, the Data Encryption Standard (DES).

Advanced Encryption Standard (AES) The Advanced Encryption Standard (AES), also known as Rijndael, is a block cipher adopted as an encryption standard by the U.S. government. It has been analyzed extensively and is now used worldwide, as was the case with its predecessor, the Data Encryption Standard (DES).

Modified p. 39 → 31

Check values are computed by encrypting an all-zero block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). This method may be used for TDEA. TDEA may optionally ~~use,~~ and AES shall use a technique where the KCV is calculated by MACing an all-zero block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP ~~800- 38B).~~ The check …

Check values are computed by encrypting an all-zero block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). This method may be used for TDEA. TDEA may optionally be used, and AES shall use a technique where the KCV is calculated by MACing an all-zero block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The check …

Modified p. 39 → 31

~~Clear text~~ The intelligible form of an encrypted text or of its elements⎯e.g., components.

Cleartext The intelligible form of an encrypted text or its elements⎯e.g., components.

Modified p. 39 → 31

~~Clear-text~~ Key An unencrypted cryptographic key, used in its current form.

Cleartext Key An unencrypted cryptographic key, used in its current form.

Modified p. 39 → 31

A violation of the security of a ~~system~~ such that an unauthorized disclosure of sensitive information may have occurred. This includes the unauthorized disclosure, modification, substitution, or use of sensitive data (including ~~clear-text~~ cryptographic keys and other keying material).

A violation of the security of a system, such that an unauthorized disclosure of sensitive information may have occurred. This includes the unauthorized disclosure, modification, substitution, or use of sensitive data (including cleartext cryptographic keys and other keying material).

Modified p. 39 → 31

Conditional Test A test performed by a cryptographic module when the conditions specified for the test occur.

Conditional Test A test that is performed by a cryptographic module when the conditions specified for the test occur.

Modified p. 39 → 31

Critical Functions Those functions that, upon failure, could lead to the disclosure of CSPs. Examples of critical functions ~~include~~ but are not limited ~~to random~~ number generation, ~~cryptographic algorithm~~ operations, and cryptographic bypass.

Critical Functions Those functions that, upon failure, could lead to the disclosure of CSPs. Examples of critical functions include, but are not limited to, random- number generation, cryptographic-algorithm operations, and cryptographic bypass.

Removed p. 40

Data Encryption Algorithm (DEA) A published encryption algorithm used to protect critical information by enciphering data based upon a variable secret key. The Data Encryption Algorithm is defined in ANSI X3.92: Data Encryption Algorithm for encryption and decrypting data.

Modified p. 40 → 32

• The transformation of ~~clear-text~~ data into ciphertext data,

• The transformation of cleartext data into ciphertext data,

Modified p. 40 → 32

• The transformation of ciphertext data into ~~clear-text~~ data,

• The transformation of ciphertext data into cleartext data,

Modified p. 40 → 32

Cryptographic Key Component (Key Component) One of at least two parameters having the characteristics (for example, format, randomness) of a cryptographic key that is combined with one or more like parameters (for example, by means of modulo-2 addition), to form a cryptographic key. Throughout this document, ~~key component~~ may be used interchangeably with secret ~~share or key fragment.~~

Cryptographic Key Component (Key Component) One of at least two parameters having the characteristics (for example, format, randomness) of a cryptographic key that is combined with one or more like parameters (for example, by means of modulo-2 addition), to form a cryptographic key. Throughout this document, “key component” may be used interchangeably with “secret share” or “key fragment.” Data Encryption Algorithm (DEA) A published encryption algorithm used to protect critical information by enciphering data based upon a variable secret key. …

Modified p. 40 → 32

Decrypt A process of transforming ciphertext (unreadable) into ~~clear text~~ (readable).

Decrypt A process of transforming ciphertext (unreadable) into cleartext (readable).

Modified p. 40 → 32

Derivation Key A cryptographic ~~key, which~~ is used to cryptographically compute another key. A derivation key is normally associated with the Derived Unique Key Per Transaction key management method. Derivation keys are normally used in a transaction-receiving (e.g., acquirer) TRSM in a one-to-many relationship to derive or decrypt the Transaction (the derived keys) Keys used by a large number of originating TRSMs⎯e.g., terminals.

Derivation Key A cryptographic key that is used to cryptographically compute another key. A derivation key is normally associated with the Derived Unique Key Per Transaction key management method.

Removed p. 41

Dual Control A process of using two or more separate entities (usually persons), operating in concert to protect sensitive functions or information. Both entities are equally responsible for the physical protection of materials involved in vulnerable transactions. No single person must be able to access or to use the materials⎯e.g., cryptographic key. For manual key- generation, conveyance, loading, storage, and retrieval, dual control requires

• split knowledge of the key among the entities. Also see

Modified p. 41 → 33

DUKPT Derived Unique Key Per Transaction: A key-management method that uses a unique key for each transaction and prevents the disclosure of any past key used by the transaction originating TRSM. The unique transaction keys are derived from a base-derivation key using only ~~non-secret~~ data transmitted as part of each transaction.

DUKPT Derived Unique Key Per Transaction: A key-management method that uses a unique key for each transaction and prevents the disclosure of any past key used by the transaction originating TRSM. The unique transaction keys are derived from a base-derivation key using only non- secret data transmitted as part of each transaction.

Modified p. 41 → 33

EFTPOS ~~Electronic funds~~ transfer at ~~point of sale.~~

EFTPOS Electronic-funds transfer at point-of-sale.

Modified p. 41 → 33

Electronic Key Loading The entry of cryptographic keys into a ~~security~~ cryptographic device in electronic form using a key-loading device. The user entering the ~~key may~~ have no knowledge of the ~~value of the key~~ being entered.

Electronic Key Loading The entry of cryptographic keys into a secure cryptographic device in electronic form using a key-loading device. The user entering the keys does not have knowledge of the cryptographic keys being entered.

Modified p. 41 → 33

Elliptic-curve ~~cryptography~~ (ECC) ECC is an approach to public-key cryptography based on the algebraic structure of elliptic curves over finite fields. ECC allows smaller keys compared to non-EC cryptography (based on plain Galois fields) to provide equivalent security.

Elliptic-curve Cryptography (ECC) ECC is an approach to public-key cryptography based on the algebraic structure of elliptic curves over finite fields. ECC allows smaller keys compared to non-EC cryptography (based on plain Galois fields) to provide equivalent security.

Modified p. 41 → 33

Encrypt The (reversible) transformation of data by a cryptographic algorithm to produce ciphertext⎯i.e., to hide the information content of the data•i.e., the process of transforming ~~clear text~~ into ciphertext.

Encrypt The (reversible) transformation of data by a cryptographic algorithm in order to produce ciphertext⎯i.e., to hide the information content of the data•i.e., the process of transforming cleartext into ciphertext.

Modified p. 41 → 33

Encrypted Key (Ciphertext Key) A cryptographic key that has been encrypted with a key-encrypting key, a PIN, or a password/authentication code in order to disguise the value of the underlying ~~clear-text~~ key.

Encrypted Key (Ciphertext Key) A cryptographic key that has been encrypted with a key-encrypting key, a PIN, or a password/authentication code in order to disguise the value of the underlying cleartext key.

Modified p. 42 → 34

Error-detection Code (EDC) Value computed from data and comprised of redundant bits of information designed to detect, but not correct, unintentional changes in the data Error State A state when the cryptographic module has encountered an error ~~condition (e.g.,~~ failed a ~~self-test).~~ There may be one or more error conditions that result in a single module error state. Error states may include:

Error-detection Code (EDC) Value computed from data and comprised of redundant bits of information designed to detect, but not correct, unintentional changes in the data Error State A state when the cryptographic module has encountered an error condition⎯e.g., failed a self-test. There may be one or more error conditions that result in a single module error state. Error states may include:

Modified p. 42 → 34

Recovery from error states shall be ~~possible~~ except for those caused by hard errors requiring maintenance, service, or repair of the cryptographic module.

Recovery from error states shall be possible, except for those caused by hard errors requiring maintenance, service, or repair of the cryptographic module.

Modified p. 42 → 34

Evaluation Laboratory ~~Independent~~ entity that performs a security evaluation of the device against the PCI Security Requirements.

Evaluation Laboratory An independent entity that performs a security evaluation of the device against the PCI Security Requirements.

Modified p. 42 → 34

Exclusive-OR Binary addition with no carry, also known as modulo 2 ~~addition,~~ symbolized as “XOR” and defined as:

Exclusive-OR Binary addition with no carry, also known as modulo 2 additions; symbolized as “XOR” and defined as:

Removed p. 43

HSM Solution Consumer Individual or system authorized to interface with and use an HSM Solution. An HSM Solution Consumer may perform multiple roles such as administration and operations but not those involving the set-up and maintenance of the underlying HSM Solution.

Modified p. 43 → 35

HSM Processing Element ~~Physical~~ system that performs operations using user cryptographic keys (working keys) of an ~~HSM Solution Consumer.~~

HSM Processing Element A type of HSM.A physical system that performs operations using user cryptographic keys (working keys) of an HSM. This may be implemented for a Tenant within an HSM-as-a-Service implementation.

Modified p. 43 → 35

HSM Solution The sum of the HSM processing element and HSM virtualization system, which is exposed to the HSM ~~Solution Consumer~~ as the “Cloud HSM” to which they interface.

HSM Solution The sum of the HSM processing element and HSM virtualization system, which is exposed to the HSM Tenant as the “Cloud HSM” to which they interface.

Modified p. 43 → 36

HSM Virtualization System System that authenticates the HSM ~~Solution Consumer,~~ provides virtualization of functions and HSM API commands, and assigns one or more HSM processing elements to perform tasks as required. An ~~HSM processing~~ element and HSM Virtualization System may be a single physical element or implemented in virtualized/cloud environment elements.

HSM Virtualization System System that authenticates the HSM Tenant, provides virtualization of functions and HSM API commands, and assigns one or more HSM processing elements to perform tasks as required. An HSM-processing element and HSM Virtualization System may be a single physical element or implemented in virtualized/cloud environment elements.

Modified p. 43 → 36

Initialization Vector (IV) A binary vector used as the input to initialize the algorithm (a stream or block cipher) for the encryption of a ~~clear-text~~ block sequence to increase security by introducing additional cryptographic variance and to synchronize cryptographic equipment. The initialization vector need not be secret.

Initialization Vector (IV) A binary vector used as the input to initialize the algorithm (a stream or block cipher) for the encryption of a cleartext block sequence to increase security by introducing additional cryptographic variance and to synchronize cryptographic equipment. The initialization vector need not be secret.

Modified p. 43 → 36

Initial Key Loading Pertains to the loading of ~~payment transaction~~ keys used by the acquiring organization.

Initial Key Loading Pertains to the loading of payment-transaction keys used by the acquiring organization.

Modified p. 44 → 36

Key Agreement A ~~key establishment~~ protocol for establishing a shared secret key between entities in such a way that neither of them can predetermine the value of that key. That is, the secret key is a function of information contributed by two or more participants.

Key Agreement A key-establishment protocol for establishing a shared secret key between entities in such a way that neither of them can predetermine the value of that key. That is, the secret key is a function of information contributed by two or more participants.

Modified p. 44 → 37

Key-distribution ~~host~~ (KDH) A KDH is a processing ~~platform~~ used in conjunction with ~~HSM(s)~~ that generates keys and securely distributes those keys to the EPP or ~~PED~~ and the financial-processing platform communicating with those EPPs/PEDs. A KDH may be an application that operates on the same platform that is used for PIN translation and financial-transaction processing. The KDH may be used in conjunction with other processing activities. A KDH shall not be used for certificate issuance and must not be …

Key-distribution Host (KDH) A KDH is a processing platform, used in conjunction with HSM(s), that generates keys and securely distributes those keys to the EPP or PED, and the financial-processing platform communicating with those EPPs/PEDs. A KDH may be an application that operates on the same platform that is used for PIN translation and financial-transaction processing. The KDH may be used in conjunction with other processing activities. A KDH shall not be used for certificate issuance and must not be …

Removed p. 45

Key-Loading Device A self-contained unit that is capable of storing at least one clear-text or encrypted cryptographic key or key component that can be transferred, upon request, into a cryptographic module.

Modified p. 45 → 38

• Export of a key from one secure cryptographic device (SCD) to another SCD in ~~clear-text,~~ component, or enciphered form;

• Export of a key from one secure cryptographic device (SCD) to another SCD in cleartext, component, or enciphered form;

Modified p. 45 → 38

• Temporary storage of the key in ~~clear-text,~~ component, or enciphered form within an SCD during transfer.

• Temporary storage of the key in cleartext, component, or enciphered form within an SCD during transfer.

Modified p. 45 → 38

Key Transport A ~~key establishment~~ protocol under which the secret key is determined by the initiating party and transferred suitably protected.

Key Transport A key-establishment protocol under which the secret key is determined by the initiating party and transferred suitably protected.

Modified p. 46 → 39

Manual Key Distribution The distribution of cryptographic keys, often in a ~~clear-text~~ form requiring physical protection, but using a non-electronic means, such as a bonded courier.

Manual Key Distribution The distribution of cryptographic keys, often in a cleartext form requiring physical protection, but using a non-electronic means, such as a bonded courier.

Modified p. 46 → 39

Message Authentication Code (MAC) A cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications of data (example: a ~~Hash-Based~~ Message Authentication Code).

Message Authentication Code (MAC) A cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications of data (example: a Hash- Based Message Authentication Code).

Modified p. 46 → 39

~~Multi-tenant HSM These are HSMs intended for multi-tenant usage•i.e., concurrent multi- organizational usage. These would be typically implemented in connection with an HSM as a service provider~~ Non-invasive Attack Attack that can be performed on a cryptographic module without direct physical contact with components within the cryptographic boundary of the module.

Non-invasive Attack Attack that can be performed on a cryptographic module without direct physical contact with components within the cryptographic boundary of the module.

Modified p. 46 → 40

Personal Identification Number (PIN) A numeric personal identification code that authenticates a cardholder in an authorization request that originates at a terminal with ~~authorization~~ only or ~~data capture only~~ capability. A PIN consists only of decimal digits.

Perfect Forward Secrecy A protocol has Perfect Forward Secrecy if a compromise of long-term keys does not also compromise past session keys. Also known as “Forward Secrecy.” Personal Identification Number (PIN) A numeric personal identification code that authenticates a cardholder in an authorization request that originates at a terminal with authorization- only or data-captures-only capability. A PIN consists only of decimal digits.

Modified p. 47 → 40

PIN Entry Device (PED) A device for secure PIN entry and processing. The PED typically consists of a keypad for PIN entry, laid out in a prescribed format, a display for user interaction, a processor and storage for PIN processing sufficiently secure for the ~~key management~~ scheme used, and firmware. A PED has a clearly defined physical and logical boundary, and a tamper-resistant or tamper- evident shell.

PIN Entry Device (PED) A device for secure PIN entry and processing. The PED typically consists of a keypad for PIN entry, laid out in a prescribed format, a display for user interaction, a processor and storage for PIN processing sufficiently secure for the key-management scheme used, and firmware. A PED has a clearly defined physical and logical boundary, and a tamper-resistant or tamper- evident shell.

Modified p. 47 → 41

Public Key A cryptographic key, used with a public key cryptographic algorithm, uniquely associated with an entity, and ~~that~~ may be made public In the case of an asymmetric signature system, the public key defines the verification transformation. In the case of an asymmetric encipherment system, the public key defines the encipherment transformation. A key that is “publicly known” is not necessarily globally available. The key may only be available to all members of a pre-specified group.

Public Key A cryptographic key, used with a public key cryptographic algorithm, uniquely associated with an entity, and which may be made public.

Removed p. 48

Random The process of generating values with a high level of entropy and which satisfy various qualifications, using cryptographic and hardware based “noise” mechanisms. This results in a value in a set that has equal probability of being selected from the total population of possibilities, hence unpredictable.

Remote-managed HSM These are HSMs that are designed to support remote management⎯e.g., non-console⎯for device configuration and cryptographic key loading. These HSMs differ from Multi-tenant HSMs in that they are designed for usage dedicated to a specific organization. They may exist as HSMs owned and operated by a specific organization or HSMs provided by a third party as part of an HSM as a service implementation.

RNG Random number generator.

Modified p. 48 → 41

For example, public cryptographic keys, public key certificates, self-signed certificates, trust anchors, one-time passwords associated with a ~~counter~~ and internally held date and time.

For example, public cryptographic keys, public key certificates, self-signed certificates, trust anchors, one-time passwords associated with a counter, and internally held date and time.

Modified p. 48 → 42

Remote Administration Platform (RAP) Platforms that are used for remote administration of HSMs. Such administration may include device configuration and ~~cryptographic key-~~ loading services.

Remote Administration Platform (RAP) Platforms that are used for remote administration of HSMs. Such administration may include device configuration and cryptographic-key- loading services.

Removed p. 49

Sensitive (Secret) Data (Information) Data that must be protected against unauthorized disclosure, alteration or destruction, especially clear-text PINs, and secret and private cryptographic keys, and includes design characteristics, status information, and so forth.

Modified p. 49 → 42

Salt A random string that is concatenated with other data prior to being operated on by a one-way function. A salt should have a minimum length of ~~64-bits.~~

Salt A random string that is concatenated with other data prior to being operated on by a one-way function. A salt should have a minimum length of 64 bits.

Modified p. 49 → 42

Secret Key A cryptographic key, used with a secret key cryptographic algorithm that is uniquely associated with one or more entities and should not be made public. A secret key (symmetrical) cryptographic algorithm uses a single secret key for both encryption and decryption. The use of the term “secret” in this context does not imply a classification level; ~~rather~~ the term implies the need to protect the key from disclosure or substitution.

Secret Key A cryptographic key, used with a secret key cryptographic algorithm that is uniquely associated with one or more entities and should not be made public. A secret key (symmetrical) cryptographic algorithm uses a single secret key for both encryption and decryption. The use of the term “secret” in this context does not imply a classification level; rather, the term implies the need to protect the key from disclosure or substitution.

Modified p. 49 → 42

Secure Cryptographic Device A physically and logically protected hardware device that provides a secure set of cryptographic services. It includes the set of hardware, firmware, software, or some combination thereof that implements cryptographic logic, cryptographic ~~processes~~ or both, including cryptographic algorithms.

Secure Cryptographic Device A physically and logically protected hardware device that provides a secure set of cryptographic services. It includes the set of hardware, firmware, software, or some combination thereof that implements cryptographic logic, cryptographic processes, or both, including cryptographic algorithms.

Modified p. 49 → 42

Secure ~~Cryptoprocessor~~ A secure ~~cryptoprocessor~~ is a dedicated computer on a chip or microprocessor for carrying out cryptographic operations, embedded in a packaging with multiple physical security measures that give it a degree of tamper resistance.

Secure Crypto Processor A secure crypto processor is a dedicated computer on a chip or microprocessor for carrying out cryptographic operations, embedded in packaging with multiple physical security measures that give it a degree of tamper resistance.

Modified p. 49 → 42

Secure Key Loader A self-contained unit that is capable of storing at least one ~~clear-text~~ or encrypted cryptographic key or key component that can be transferred, upon request, into a cryptographic module.

Secure Key Loader A self-contained unit that is capable of storing at least one cleartext or encrypted cryptographic key or key component that can be transferred, upon request, into a cryptographic module.

Modified p. 49 → 42

Security Policy A description of how the specific module meets these security requirements, including the rules derived from this ~~standard~~ and additional rules imposed by the vendor.

Security Policy A description of how the specific module meets these security requirements, including the rules derived from this standard, and additional rules imposed by the vendor.

Modified p. 49 → 43

Sensitive Functions Sensitive functions are those functions that process sensitive data such as cryptographic keys, ~~PINs~~ and passwords.

Sensitive Functions Sensitive functions are those functions that process sensitive data such as cryptographic keys, PINs, and passwords.

Modified p. 50 → 43

SHA-2 A set of cryptographic hash functions (SHA-224, SHA-256, SHA-384, ~~SHA- 512).~~ SHA-2 consists of a set of four hash functions with digests that are 224, 256, ~~384~~ or 512 bits.

SHA-2 A set of cryptographic hash functions (SHA-224, SHA-256, SHA-384, SHA-512). SHA-2 consists of a set of four hash functions with digests that are 224, 256, 384, or 512 bits.

Modified p. 50 → 43

Single-Length Key A cryptographic key having a length of 56 active bits plus 8 parity ~~bits~~ used in conjunction with the DES cryptographic algorithm.

Single-Length Key A cryptographic key having a length of 56 active bits plus 8 parity bits, used in conjunction with the DES cryptographic algorithm.

Removed p. 51

Unprotected Memory Components, devices, and recording media that retain data for some interval of time that reside outside the cryptographic boundary of a secure cryptographic device.

Modified p. 51 → 44

User ~~Individual~~ or ~~(system)~~ process authorized to access an information ~~system~~ or that makes use of the trust model to obtain the public key of another user.

User An individual or system process authorized to access an information system, or that makes use of the trust model to obtain the public key of another user.

Modified p. 51 → 45

Zeroization (zeroize) The degaussing, erasing, or overwriting of ~~electronically stored~~ data so as to prevent recovery of the data.

Zeroization (zeroize) The degaussing, erasing, or overwriting of electronically-stored data so as to prevent recovery of the data.

Modified p. 52 → 46

1. A description of device ~~characteristics~~

1. A description of device characteristics.

Modified p. 52 → 46

3. Internal photos, sufficient to show the various components of the ~~device~~

3. Internal photos, sufficient to show the various components of the device.

Document Comparison

From Revision History

Content Changes