Document Comparison

PCI_HSM_Security_Requirements_v2.pdf PCI_HSM_Security_Requirements_v3_2016_TOC.pdf
79% similar
37 → 47 Pages
9824 → 12145 Words
80 Content Changes

Content Changes

80 content changes. 59 administrative changes (dates, page numbers) hidden.

Added p. 3
February 2016 3.x PCI RFC version
Added p. 3
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.

• General Information
Added p. 6
• Card production and personalization

• Cash-card reloading

• Chip-card transaction processing

• A companion PCI PTS Vendor Questionnaire (where technical details of the device are provided)
Added p. 7
1. The addition of approval classes for key-loading devices and for remote administration of HSMs
Added p. 14
B4.1 The firmware must support the authentication of applications loaded into the device consistent with B4. If the device allows software application and/or configuration updates, the device cryptographically authenticates updates consistent with B4.

• The transaction is completed,

• The device has timed out, or

• The device recovers from an error state.

B8 Private and secret key entry is performed using accepted techniques according to the table below.
Added p. 18
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 cryptographic key within the device from a component of higher security to a component 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 used to load a …
Added p. 19
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 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 (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.
Added p. 20
F2 The length of the MAC being generated or verified is in accordance with ISO 16609 and as agreed to by the sender and receiver.

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.
Added p. 21
• 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 plaintext key except under dual control. Such dual control is enforced by means such as the following:

• The device requires that at least two passwords 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 special “sensitive” …
Added p. 22
• 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 only for backup and archival purposes; 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.
Added p. 23
Note: In the following requirements, the device under evaluation is referred to as the “device.” The device manufacturer, subject to PCI payment brand site inspections, confirms the following. The PCI test laboratories will validate this information via documentation reviews. Any variances to these requirements will be reported to PCI for review. However, this information will only be used for analysis at this time and will not impact whether a device receives an approval.

I3 The device is assembled in a manner that the components used in the manufacturing process are those components that were certified by the Physical Security Requirements evaluation, and that unauthorized substitutions have not been made.

I7 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 …
Added p. 27
• 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.

City: State/Province:
Added p. 30
Functionality Description Core 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, and Remote Administration Platform.

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.
Added p. 31
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.

To determine which requirements apply to a device, the following steps must take place:

1. Identify which of the functionalities the device supports.

2. For each of the supported functionalities, report any marking “X” corresponding to the listed requirement. “X” stands for “applicable,” in which case the requirement must be considered for both the vendor questionnaire and evaluation. In all cases, if a security requirement is impacted, the device must be assessed against it.
Added p. 35
• The transformation of plaintext data into ciphertext data,

• The transformation of ciphertext data into plaintext data,

• A digital signature computed from data,

• The verification of a digital signature computed from data,

• An authentication code computed from data, or

• An exchange agreement of a shared secret.

ECB Electronic codebook.

EEPROM Electronically erasable programmable read-only memory.

EFP Environmental failure protection.

EFTPOS Electronic funds transfer at point of sale.

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

Key-Loading Device An SCD that may be used for securely receiving, storing, and transferring data between compatible cryptographic and communications equipment. Key- transfer and loading functions include the following:

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

• Export of a key component from an SCD into a tamper-evident package (e.g., blind mailer);

• Import of key components into an SCD from a tamper-evident …
Added p. 45
Unique Accountability Actions are attributable to a specific person or role.
Removed p. 5
A companion PCI PTS Vendor Questionnaire (where technical details of the device are provided) Product samples Technical support documentation Upon successful compliance testing by the laboratory and approval by the PCI SSC, the PCI PTS HSM device will be listed on the PCI SSC website. Commercial information to be included in the Council s approval must be provided by the vendor to the test laboratory using the forms in the Required Device Information section of this document.
Modified p. 5 → 6
PIN processing 3-D Secure Card verification Card production and personalization ATM interchange Cash-card reloading Data integrity Chip-card transaction processing 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 …
• 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.
Removed p. 6
The updating of attack methodologies that can be considered to reflect a more comprehensive approach; The updating of algorithms and key sizes to be consistent with those stipulated in PTS POI Security Requirements v3; The inclusion of criteria to support remote key-loading techniques using public-key methods to require compliance with PCI-defined criteria for key sizes and mutual authentication between host and device.

Furthermore, this document introduces a two-tier approval structure for HSMs. These tiers differentiate only in the Physical Derived Test Requirements
Modified p. 6 → 7
section as delineated in the PCI PTS HSM Derived Test Requirements. HSMs may be approved as designed for use in controlled environments as defined in ISO 13491-2: Banking Secure cryptographic devices (retail) or approved for use in any operational environment.
2. The validation of device management information submitted by vendors Furthermore, this document continues a two-tier approval structure for HSMs. These tiers differentiate only in the “Physical Derived Test Requirements” section as delineated in the PCI PTS HSM Derived Test Requirements. HSMs may be approved as designed for use in controlled environments as defined in ISO 13491-2: Banking Secure cryptographic devices (retail) or approved for use in any operational environment.
Modified p. 7 → 8
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 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.
Modified p. 8 → 9
The HSM components that were evaluated; The security level of the evaluation; That the existing FIPS certification covers the full HSM functionality for all the related requirements.
That the existing FIPS certification covers the full HSM functionality for all the related requirements.
Modified p. 10 → 12
Use of x represents a request for field to be a Variable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Firmware Version Number:
Use of “x” represents a request for field to be a Variable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Firmware Version Number:
Modified p. 10 → 12
Application Version Number: (if applicable) Designed for deployment only in controlled environments as defined in ISO 13491-2? Yes 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.
Application Version Number: (if applicable) Designed for deployment only in controlled environments 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 → 12
Optional Use of Variables in the HSM Identifier AHardware Version Number Request for Use of the Variable x
Optional Use of Variables in the Device Identifier AHardware Version Number Request for Use of the Variable “x”
Removed p. 11
A2 Failure of a single security mechanism does not compromise HSM security. Protection against a threat is based on a combination of at least two independent security mechanisms. If the HSM relies upon visible tamper evidence for protection, the HSM has characteristics such that penetration of the device results in visible tamper evidence that has a high probability of being detected.

A3 If the device permits access to internal areas (e.g., for service or maintenance), it is not possible using this area to access sensitive data. Immediate access to sensitive data, such as PIN or cryptographic data, is either prevented by the design of the internal areas (e.g., by enclosing components with sensitive data into tamper- resistant/responsive enclosures), and/or it has a mechanism so that accessing internal areas causes the immediate erasure of sensitive data.
Modified p. 11 → 13
Number Description of Requirement Yes No N/A The HSM 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 HSM, 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 an …
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 …
Modified p. 11 → 13
A4 The security of the HSM is not compromised by altering environmental conditions or operational conditions (for example, subjecting the HSM to temperatures or operating voltages outside the stated operating ranges).
A2 The security of the device is not compromised by altering environmental conditions or operational conditions (for example, subjecting the device to temperatures or operating voltages outside the stated operating ranges).
Modified p. 11 → 13
A5 Sensitive functions or information are only used in the protected area(s) of the HSM. Sensitive information and functions dealing with sensitive information are protected from modification or substitution, without requiring an attack potential of at least 26 per HSM for identification and initial exploitation, with a minimum of 13 for initial exploitationA.
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 exploitationA A4 There is no feasible way to determine any sensitive information by monitoring electro-magnetic emissions, power consumption, or any other internal or external characteristic without an …
Modified p. 12 → 13
A7 Determination of any PCI-related cryptographic key resident in the device or used by the device, by penetration of the device and/or by monitoring emanations from the device (including power fluctuations), requires an attack potential of at least 35 for identification and initial exploitation with a minimum of 15 for exploitationB.
A5 Determination of any PCI-related cryptographic key resident in the device or used by the device, by penetration of the device and/or by monitoring emanations from the device (including power fluctuations), requires an attack potential of at least 35 for identification and initial exploitation with a minimum of 15 for exploitationB.
Removed p. 13
The transaction is completed, The HSM has timed out, or The HSM recovers from an error state.
Modified p. 13 → 14
Number Description of Requirement Yes No N/A To ensure that the HSM is operating as designed, the device runs self-tests when powered up and at least once per day to check firmware (authenticity check), security mechanisms for signs of tampering, and whether the HSM is in a compromised state. When specific critical operations are performed, the HSM performs conditional tests. The techniques and actions of the HSM upon failure of a self-test are consistent with those defined in FIPS PUB …
Number Description of Requirement Yes No N/A B1 To ensure that the device is operating as designed, the device runs self-tests when powered up and at least once per day or 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 consistent …
Modified p. 13 → 14
B2 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 clear-text PINs or other sensitive information.
B2 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.
Modified p. 13 → 14
B4 If the HSM implements firmware updates, the device cryptographically authenticates the firmware integrity, and if the authenticity is not confirmed, the firmware update is rejected and deleted.
B4 The device must support firmware updates. The device must cryptographically authenticate the firmware, and if the authenticity is not confirmed, the firmware update is rejected and deleted.
Modified p. 13 → 14
The HSM provides secure interfaces that are kept logically separate by distinguishing between data and control for inputs and also between data and status for outputs.
B5 The device provides secure interfaces that are kept logically separate by distinguishing between data and control for inputs and also between data and status for outputs.
Modified p. 13 → 14
B6 The HSM must automatically clear or reinitialize its internal buffers that hold sensitive information prior to reuse of the buffer, including when:
B6 The device must automatically clear or reinitialize its internal buffers that hold sensitive information prior to reuse of the buffer, including when:
Modified p. 14 → 15
Manual Direct Network Plaintext keys No Yes No Plaintext key components Yes Yes No Enciphered keys Yes Yes Yes If the device generates random numbers in connection with security over sensitive data, the random number generator has been assessed to ensure that it is generating sufficiently unpredictable numbers.
Manual Direct Network Plaintext keys No Yes No Plaintext key components Yes Yes No Enciphered keys/components Yes Yes Yes B9 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.
Modified p. 14 → 15
The HSM uses accepted cryptographic algorithms, modes, and key sizes.
B10 The device uses accepted cryptographic algorithms, modes, and key sizes.
Modified p. 14 → 15
B11 The key-management techniques implemented in the HSM conform to ISO 11568 and/or ANSI X9.24. Key-management techniques must support ANSI TR-31 key-derivation methodology or an equivalent methodology for maintaining the TDEA key bundle.
B11 The key-management techniques implemented in the device conform to ISO 11568 and/or ANSI X9.24. Key-management techniques must support ANSI TR-31 key-derivation methodology or an equivalent methodology for maintaining the TDEA key bundle.
Modified p. 14 → 15
B12 The HSM ensures that if cryptographic keys within the secure HSM boundary are rendered invalid for any reason (e.g., tamper or long- term absence of applied power), the HSM will fail in a secure manner.
B12 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.
Modified p. 14 → 15
The HSM 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 or key-encrypting key contained in or protected by the HSM. The HSM 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.
B13 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 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 → 16
B15 If the HSM is designed to be used for PIN management, the HSM shall meet the PIN-management requirements of ISO 9564. The PIN- encryption technique implemented in the HSM is a technique included in ISO 9564.
B15 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 → 16
B16 The HSM includes cryptographic mechanisms to support secure logging of transactions, data, and events to enable auditing.
B16 The device includes cryptographic mechanisms to support secure logging of transactions, data, and events to enable auditing.
Modified p. 15 → 16
B19 The HSM has the ability to return its unique device ID.
B19 The device has the ability to return its unique device ID.
Modified p. 15 → 16
B20 HSMs 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 HSM is in PCI mode and not in PCI mode, and must require dual authentication when switching between the two modes.
B20 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
D3 The HSM is assembled in a manner that the components used in the manufacturing process are those components that were certified by the Physical Security Requirements evaluation, and that unauthorized substitutions have not been made.
Modified p. 17 → 23
Number Description of Requirement Yes No N/A D1 Change-control procedures are in place so that any intended change to the physical or functional capabilities of the HSM causes a re- certification of the device under the Physical Security Requirements or the Logical Security Requirements of this document. Immediate re- certification is not required for changes which purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality.
Number Description of Requirement Yes No N/A I1 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.
Modified p. 17 → 23
D2 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.
I2 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.
Modified p. 17 → 23
D4 Production software (e.g., firmware) that is loaded to devices at the time of manufacture is transported, stored, and used under the principle of dual control, preventing unauthorized modifications and/or substitutions.
I4 Production software (e.g., firmware) that is loaded to devices at the time of manufacture is transported, stored, and used under the principle of dual control, preventing unauthorized modifications and/or substitutions.
Modified p. 17 → 23
D5 Subsequent to production but prior to shipment from the manufacturer s or reseller s facility, the HSM and any of its components are stored in a protected, access-controlled area or sealed within tamper-evident packaging to prevent undetected unauthorized access to the device or its components.
I5 Subsequent to production but prior to shipment from the manufacturer’s or reseller’s facility, the device and any of its components are stored in a protected, access-controlled area or sealed within tamper-evident packaging to prevent undetected unauthorized access to the device or its components and to prevent unauthorized modifications to the physical or functional characteristics of the device.
Modified p. 18 → 24
D8 Controls exist over the repair process and the inspection/testing process subsequent to repair to ensure that the device has not been subject to unauthorized modification.
I8 Controls exist over the repair process and the inspection/testing process subsequent to repair to ensure that the device has not been subject to unauthorized modification.
Modified p. 19 → 25
Number Description of Requirement Yes No N/A E1 The HSM should be protected from unauthorized modification with tamper-evident 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 HSM.
Number Description of Requirement Yes No N/A J1 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.
Modified p. 19 → 25
Where this is not possible, the HSM is shipped from the manufacturer s facility to the facility of initial deployment and stored en route under auditable controls that can account for the location of every HSM at every point in time.
Where this is not possible, the device is shipped from the manufacturer’s facility to the facility of initial deployment and stored en route under auditable controls that can account for the location of every device at every point in time.
Modified p. 19 → 25
Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage that 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 is compliant with this requirement.
Modified p. 19 → 25
E2 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.
J2 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.
Modified p. 19 → 25
E3 While in transit from the manufacturer s facility to the facility of initial deployment, the device is:
J3 While in transit from the manufacturer’s facility to the facility of initial deployment, the device is:
Modified p. 19 → 25
Shipped and stored in tamper-evident packaging; and/or Shipped and stored containing a secret that:
Shipped and stored in tamper-evident packaging; and/or
Modified p. 19 → 25
Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and Can be verified by the initial-key-loading facility, but that cannot feasibly be determined by unauthorized personnel.
Can be verified by the initial-key-loading facility, but that cannot feasibly be determined by unauthorized personnel.
Modified p. 19 → 25
E4 The device s development-security documentation must provide means to the facility of initial deployment to assure the authenticity of the TOE security-relevant components.
J4 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.
Modified p. 19 → 26
E5 If the manufacturer is in charge of initial-key loading, the manufacturer must verify the authenticity of the HSM security-related components.
J6 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. 20 → 26
E7 Each device shall have a unique visible identifier affixed to it or should be identifiable using secure, cryptographically-protected methods.
J7 Each device shall have a unique visible identifier affixed to it or should be identifiable using secure, cryptographically protected methods.
Modified p. 20 → 26
E8 The vendor must maintain a manual that provides instructions for the operational management of the HSM. This includes instructions for recording the entire life cycle of the HSM security-related components and of the manner in which those components are integrated into a single HSM, e.g.:
J8 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 of the manner in which those components are integrated into a single device, e.g.:
Modified p. 21 → 27
HSM Manufacturer Information HSM Manufacturer:
Device Manufacturer Information Device Manufacturer:
Modified p. 22 → 28
I hereby attest that the above-referenced model of HSM is:
I hereby attest that the above-referenced model of device is:
Modified p. 22 → 28
Printed Name 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.
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.
Modified p. 24 → 34
Active Erasure Mechanism that intentionally clears data from storage through a means other than simply removing power (e.g. zeroization, inverting power).
Active Erasure Mechanism that intentionally clears data from storage through a means other than simply removing power (e.g., zeroization, inverting power).
Removed p. 25
The transformation of plaintext data into ciphertext data, The transformation of ciphertext data into plaintext data, A digital signature computed from data, The verification of a digital signature computed from data, An authentication code computed from data, or An exchange agreement of a shared secret.
Modified p. 27 → 37
DTP Detailed Test Procedure DTR Derived Test Requirement 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. …
DTP Detailed Test Procedure. DTR Derived Test Requirement. 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. …
Modified p. 27 → 37
ECB Electronic codebook EEPROM Electronically erasable programmable read-only memory EFP Environmental failure protection EFTPOS Electronic funds transfer at point of sale Electromagnetic Emanations (EME) An intelligence-bearing signal, which, if intercepted and analyzed, potentially discloses the information that is transmitted, received, handled, or otherwise processed by any information-processing equipment.
Electromagnetic Emanations (EME) An intelligence-bearing signal, which, if intercepted and analyzed, potentially discloses the information that is transmitted, received, handled, or otherwise processed by any information-processing equipment.
Modified p. 28 → 38
Evaluation Laboratory Independent entity that performs a security evaluation of the HSM against the PCI Security Requirements.
Evaluation Laboratory Independent entity that performs a security evaluation of the device against the PCI Security Requirements.
Modified p. 28 → 38
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 addition, symbolized as “XOR” and defined as:
Modified p. 28 → 38
Firmware Any code within the HSM that provides security protections needed to comply with these HSM security requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under these HSM security requirements.
Firmware Any code within the device that provides security protections needed to comply with these device security requirements. Other code that exists within the device that does not provide security, and cannot impact security, is not considered firmware under these device security requirements.
Modified p. 28 → 38
It may be used to reduce a potentially long message into a hash value or message digest which is sufficiently compact to be input into a digital signature algorithm. A good hash is such that the results of applying the function to a (large) set of values in a given domain will be evenly (and randomly) distributed over a smaller range.
It may be used to reduce a potentially long message into a “hash value” or “message digest” which is sufficiently compact to be input into a digital signature algorithm. A “good” hash is such that the results of applying the function to a (large) set of values in a given domain will be evenly (and randomly) distributed over a smaller range.
Modified p. 31 → 41
Master Key In a hierarchy of key-encrypting keys and transaction keys, the highest level of key-encrypting key is known as a Master Key. May also be known as Master File Key or Local Master Key, depending on the vendor s nomenclature.
Master Key In a hierarchy of key-encrypting keys and transaction keys, the highest level of key-encrypting key is known as a Master Key. May also be known as Master File Key or Local Master Key, depending on the vendor’s nomenclature.
Modified p. 33 → 43
A system based on asymmetric cryptographic techniques can either be an encipherment system, a signature system, a combined encipherment and signature system, or a key agreement system.
A system based on asymmetric cryptographic techniques can either be an encipherment system, a signature system, a combined encipherment and signature system, or a key-agreement system.
Modified p. 33 → 43
With asymmetric cryptographic techniques, such as RSA, there are four elementary transformations: sign and verify for signature systems, and encipher and decipher for encipherment systems. The signature and the decipherment transformation are kept private by the owning entity, whereas the corresponding verification and encipherment transformations are published. There exists asymmetric cryptosystems (e.g. RSA) where the four elementary functions may be achieved by only two transformations: one private transformation suffices for both signing and decrypting messages, and one public transformation suffices …
With asymmetric cryptographic techniques, such as RSA, there are four elementary transformations: sign and verify for signature systems, and encipher and decipher for encipherment systems. The signature and the decipherment transformation are kept private by the owning entity, whereas the corresponding verification and encipherment transformations are published. There exists asymmetric cryptosystems (e.g., RSA) where the four elementary functions may be achieved by only two transformations: one private transformation suffices for both signing and decrypting messages, and one public transformation suffices …
Modified p. 33 → 43
Removable Cover A part of a cryptographic module s enclosure that permits physical access to the contents of the module.
Removable Cover A part of a cryptographic module’s enclosure that permits physical access to the contents of the module.
Modified p. 33 → 44
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. 35 → 46
Variant of a Key A new key formed by a process (which need not be secret) with the original key, such that one or more of the non-parity bits of the new key differ from the corresponding bits of the original key. For example exclusive-OR ing a non- secret constant with the original key.
Variant of a Key A new key formed by a process (which need not be secret) with the original key, such that one or more of the non-parity bits of the new key differ from the corresponding bits of the original key. For example exclusive-OR’ing a non- secret constant with the original key.
Modified p. 37 → 47
1. A description of device characteristics 2. External photos 3. Internal photos, sufficient to show the various components of the device
3. Internal photos, sufficient to show the various components of the device