Document Comparison
PCI_HSM_Security_Requirements_v3_2016_TOC.pdf
→
PCI_HSM_Security_Requirements_v4.pdf
75% similar
47 → 52
Pages
12145 → 14202
Words
130
Content Changes
Content Changes
130 content changes. 64 administrative changes (dates, page numbers) hidden.
Added
p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Hardware Security Module (HSM) Modular Security Requirements Version 4.0
Added
p. 7
Life Cycle Life cycle management considers how the device is produced, controlled, transported, stored, and used throughout its life cycle. If the device is not properly managed, unauthorized modifications might be made to its physical or logical security characteristics.
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 X9.142 Retail Financial Services - Interoperable Secure Key Block Specification ANSI X9.143 Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms ASC X9 TR 31 Interoperable Method for Distribution of Symmetric …
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 X9.142 Retail Financial Services - Interoperable Secure Key Block Specification ANSI X9.143 Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms ASC X9 TR 31 Interoperable Method for Distribution of Symmetric …
Added
p. 10
December 2021 HSM Identifier Device Manufacturer:
Added
p. 10
Firmware Version NumberA:
Use of “x” represents a request for field to be a variable.
A See “Optional Use of Variables in the Identifier,” following page.
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.
B As defined in Appendix A of the PCI HSM DTRs.
Use of “x” represents a request for field to be a variable.
A See “Optional Use of Variables in the Identifier,” following page.
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.
B As defined in Appendix A of the PCI HSM DTRs.
Added
p. 13
The update mechanism ensures security⎯i.e., integrity, mutual authentication, and protection against replay⎯by using an appropriate and declared security protocol when using a network connection.
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 support the authentication of applications loaded into the device consistent with B3.
Added
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
• 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.
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.
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.
I5 The HSM processing element …
• Installed and operated in an environment meeting at least the security requirements of a controlled environment, or
• Protect the stored and processed sensitive data to an attack potential of at least 26 per HSM virtualization system for identification and initial exploitation, with a minimum of 13 for initial exploitationA.
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.
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.
I5 The HSM processing element …
Added
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.
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 …
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.
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 …
Added
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.
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.
K5 HSM processing element tamper keys used to protect the keys of more than one HSM Solution Consumer must be …
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.
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.
K5 HSM processing element tamper keys used to protect the keys of more than one HSM Solution Consumer must be …
Added
p. 25
K10 The HSM Solution must implement a public vulnerability management and disclosure policy. This must provide:
• Methods for the secure disclosure to the impacted user organization of any vulnerabilities as they are found,
• Ranking and addressing vulnerabilities in a timely matter, and
• Methods for any HSM Solution Consumers of the HSM Solution to be informed of the vulnerabilities.
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 …
• Methods for the secure disclosure to the impacted user organization of any vulnerabilities as they are found,
• Ranking and addressing vulnerabilities in a timely matter, and
• Methods for any HSM Solution Consumers of the HSM Solution to be informed of the vulnerabilities.
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 …
Added
p. 33
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.
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.
Added
p. 38
Application(s) Any code or script that is not firmware and can be loaded onto the device.
Atomic A single command that has a defined set of input criteria/values and a defined set of output responses. No intermediate responses, states, or indications of operation are returned until the defined output is provided. For example, chaining together a set of common and related commands (MAC verify, verify PIN, check CVV, check cryptogram, etc.) to minimize traffic on the HSM link.
Authentication Code See Password.
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 …
Atomic A single command that has a defined set of input criteria/values and a defined set of output responses. No intermediate responses, states, or indications of operation are returned until the defined output is provided. For example, chaining together a set of common and related commands (MAC verify, verify PIN, check CVV, check cryptogram, etc.) to minimize traffic on the HSM link.
Authentication Code See Password.
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 …
Added
p. 40
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.
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.
Added
p. 43
Hexadecimal Character A single character in the range 0-9, A-F (upper case), representing a four- bit string.
HSM Processing Element Physical system that performs operations using user cryptographic keys (working keys) of an HSM Solution Consumer.
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 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.
HSM Solution Provider The entity that sets up and maintains an HSM Solution exposed to one or more HSM Solution Consumers.
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 …
HSM Processing Element Physical system that performs operations using user cryptographic keys (working keys) of an HSM Solution Consumer.
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 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.
HSM Solution Provider The entity that sets up and maintains an HSM Solution exposed to one or more HSM Solution Consumers.
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 …
Added
p. 46
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.
Added
p. 47
Pre-operational Self- test Test performed by a cryptographic module between the time a cryptographic module is powered on or instantiated (after being powered off, reset, rebooted, cold-start, power interruption, etc.) and transitions to the operational state.
Public Security Parameters (PSPs) Security-related public information whose modification can compromise the security of a cryptographic module.
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.
Note: A PSP is considered protected if it cannot be modified or if its modification can be determined by the module.
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-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 …
Public Security Parameters (PSPs) Security-related public information whose modification can compromise the security of a cryptographic module.
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.
Note: A PSP is considered protected if it cannot be modified or if its modification can be determined by the module.
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-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 …
Added
p. 49
Sensitive Security Parameters (SSPs) Critical security parameters (CSP) and public security parameters (PSP).
Added
p. 50
Simple Power Analysis (SPA) Direct (primarily visual) analysis of patterns of instruction execution (or execution of individual instructions) in relation to the electrical power consumption of a cryptographic module for the purpose of extracting information correlated to a cryptographic operation.
Strong Cryptography Cryptography using algorithms and key sizes as defined in Appendix D of the PCI HSM DTR document.
Strong Cryptography Cryptography using algorithms and key sizes as defined in Appendix D of the PCI HSM DTR document.
Modified
p. 3 → 2
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.
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.
• 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.
Removed
p. 6
• A companion PCI PTS Vendor Questionnaire (where technical details of the device are provided)
Modified
p. 6 → 5
• 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.
Removed
p. 7
1. The addition of approval classes for key-loading devices and for remote administration of HSMs
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.
Device Management Device management considers how the device is produced, controlled, transported, stored, and used throughout its life cycle. If the device is not properly managed, unauthorized modifications might be made to its physical or logical security characteristics.
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.
Device Management Device management considers how the device is produced, controlled, transported, stored, and used throughout its life cycle. If the device is not properly managed, unauthorized modifications might be made to its physical or logical security characteristics.
Modified
p. 8 → 7
The evaluation of physical security characteristics is very much a value judgment. Virtually any physical barrier can be defeated with sufficient time and effort. Therefore, many of the requirements have minimum attack-calculation values for the identification and initial exploitation of the device based upon factors such as attack time, expertise and equipment required. Given the evolution of attack techniques and technology, the PCI payment brands will periodically review these attack calculations for appropriateness.
The evaluation of physical security characteristics is very much a value judgment. Virtually any physical barrier can be defeated with sufficient time and effort. Therefore, many of the requirements have minimum attack-calculation values for the identification and initial exploitation of the device based upon factors such as attack time, expertise, and equipment required. Given the evolution of attack techniques and technology, the PCI payment brands will periodically review these attack calculations for appropriateness.
Modified
p. 8 → 7
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 PIN Security Requirements.
Removed
p. 9
Because many FIPS 140-2 evaluations only cover a subsection of the HSM and with a number of possible security levels, existing evaluation evidence for an HSM certified against FIPS 140-2 will be assessed as follows.
The evaluator will establish:
• 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.
The evaluator will establish:
• 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.
Removed
p. 10
Publication Title Reference Banking•Retail Financial Services Symmetric Key Management ANSI X9.24 Key Establishment Using Integer Factorization Cryptography ANSI X9.44 Public Key Cryptography for the Financial Services ECDSA ANSI X9.62 Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms ANSI TR-31 FIPS PUB 140-2: Security Requirements for Cryptographic Modules FIPS Personal Identification Number (PIN) Management and Security ISO 9564 Information technology
• Part 1: General ISO/IEC 18033-1 Information Technology
• Part 1: General ISO/IEC 18033-1 Information Technology
Modified
p. 10 → 8
• Part 1: Mechanisms using a block cipher ISO 9797-1 Banking•Key Management (Retail) ISO 11568 Information Technology
• Part 1: Mechanisms using a block cipher ISO 9797-1 Financial Services•Key Management (Retail) ISO 11568 Information Technology
Modified
p. 10 → 8
• Key Management, Part 3: Mechanisms Using Asymmetric Techniques (RSA and Diffie-Hellman) ISO 11770-3 Banking•Secure Cryptographic Devices (Retail) ISO 13491 Financial services
• Requirements for message authentication using symmetric techniques Information Technology
• Requirements for message authentication using symmetric techniques Information Technology
• Key Management, Part 3: Mechanisms Using Asymmetric Techniques (RSA and Diffie-Hellman) ISO 11770-3 Financial Services•Secure Cryptographic Devices (Retail) ISO 13491 Financial Services
• Requirements for message authentication using symmetric techniques Information Technology
• Requirements for message authentication using symmetric techniques Information Technology
Modified
p. 12 → 10
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.
Modified
p. 12 → 10
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.
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. 13 → 12
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 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. 13 → 12
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 …
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.
Modified
p. 13 → 12
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.
Removed
p. 14
B3 The firmware, and any changes thereafter, has been inspected and reviewed using a documented process that can be audited and is certified as being free from hidden and unauthorized or undocumented functions.
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.
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.
Modified
p. 14 → 13
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 …
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. 14 → 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.
Modified
p. 14 → 13
B3 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. 14 → 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.
Modified
p. 14 → 13
B5 The device must automatically clear or reinitialize its internal buffers that hold sensitive information once the information is no longer needed, including when:
Removed
p. 15
B8 Private and secret key entry is performed using accepted techniques according to the table below.
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.
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. 15 → 14
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.
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.
Modified
p. 15 → 14
B9 The device uses accepted cryptographic algorithms, modes, and key sizes.
Modified
p. 15 → 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.
Modified
p. 15 → 14
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. 16 → 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.
Modified
p. 16 → 14
B15 The device includes cryptographic mechanisms to support secure logging of transactions, data, and events, to enable auditing.
Modified
p. 16 → 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.
Modified
p. 16 → 15
B18 The device has the ability to return its unique device ID.
Modified
p. 16 → 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.
Modified
p. 18 → 17
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.
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.
Modified
p. 18 → 17
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 key.
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 key.
Modified
p. 19 → 18
• Disabling or enabling of device functions;
• Disabling or enabling of device functions
Modified
p. 19 → 18
• Change of passwords or data that enable the device to enter the sensitive state.
• Change of passwords/authentication codes or data that enable the device to enter the sensitive state.
Modified
p. 19 → 18
The secure operator interface is so designed that entry of more than one password (or some equivalent mechanism for dual or multiple control) is required in order to enter this sensitive state and that it is highly unlikely that the device can inadvertently be left in the sensitive state.
The secure operator interface is so designed that entry of more than one password/authentication code (or some equivalent mechanism for dual or multiple control) is required in order to enter this sensitive state and that it is highly unlikely that the device can inadvertently be left in the sensitive state.
Modified
p. 20 → 19
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.
F2 The length of the MAC being generated or verified is in accordance with ISO 16609.
Modified
p. 21 → 20
G2 The device will not output any plaintext key except under dual control. Such dual control is enforced by means such as the following:
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:
Modified
p. 21 → 20
• 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 passwords/authentication codes be correctly entered within a period of no more than five minutes before the device will output a key.
Modified
p. 21 → 20
G3 The following operator functions (if available) require the use of special “sensitive” states:
G3 The following operator functions (if available) require the use of sensitive states:
Modified
p. 21 → 20
• Manual input of control data (e.g., key verification code) to enable export, import or use of a key; and
• Manual input of control data⎯e.g., key-verification code⎯to enable export, import or use of a key; and
Modified
p. 22 → 21
• The asymmetric private key is only exported outside the original digital signature device under dual control and only for backup and archival purposes; and
• The asymmetric private key is only exported outside the original digital signature device under dual control; and
Modified
p. 22 → 21
• 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, where the public key certificate was obtained from an authorized certificate authority⎯e.g., the vendor’s PKI; or
Removed
p. 23
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. 23 → 26
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.
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 and by means of evidence that procedures are properly implemented and used. Any variances to these requirements will be reported to PCI for review.
Modified
p. 23 → 26
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.
Modified
p. 23 → 26
L4 The device is assembled in a manner that the hardware components used in the manufacturing process are those hardware components certified by the Section A Security Requirements evaluation, and that unauthorized substitutions have not been made.
Modified
p. 23 → 26
L5 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. 23 → 26
L6 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. 24 → 27
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 …
Modified
p. 24 → 27
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. 25 → 28
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 do not currently validate this information; however, the vendor is still required to complete these forms and the information will be reported to PCI for review and, if necessary, corrective action
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 and by means of evidence that procedures are properly implemented and used. Any variances to these requirements will be reported to PCI for review.
Modified
p. 25 → 28
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.
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.
Modified
p. 25 → 28
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.
Modified
p. 25 → 28
M3 While in transit from the manufacturer’s facility to the facility of initial deployment, the device is:
Modified
p. 25 → 28
- Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and
Modified
p. 25 → 28
- Can be verified by the initial-key-loading facility but cannot feasibly be determined by unauthorized personnel.
Modified
p. 25 → 28
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.
Modified
p. 26 → 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. 26 → 29
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.
•and shall be retrievable by a query using secure, cryptographically protected methods.
Modified
p. 26 → 29
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.:
Removed
p. 28
Not in full compliance with the standards set forth above in the Manufacturer Self-Assessment Form as indicated in the attached Exception Form (Form C).
Modified
p. 28 → 31
In full compliance with the standards set forth above in the Manufacturer Self-Assessment Form.
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).
Modified
p. 30 → 33
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.
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.
Modified
p. 31 → 34
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 house’s judgment to evaluate on a case-by-case basis whether supplementary testing is required.
Modified
p. 31 → 34
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.
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 evaluation. In all cases, if a security requirement is impacted, the device must be assessed against it.
Removed
p. 34
Active Erasure Mechanism that intentionally clears data from storage through a means other than simply removing power (e.g., zeroization, inverting power).
Audit Trail See Audit Journal.
Audit Trail See Audit Journal.
Modified
p. 34 → 38
Audit Journal A chronological record of system activities which is sufficient to enable the reconstruction, review, and examination of the sequence of environments and activities surrounding or leading to each event in the path of a transaction from its inception to the output of the final results.
Audit Trail A chronological record of system activities that is sufficient to enable the reconstruction, review, and examination of the sequence of environments and activities surrounding or leading to each event in the path of a transaction from its inception to the output of the final results.
Modified
p. 34 → 38
Authorization The right granted to a user to access an object, resource or function.
Authorization The right granted to a user to access an object, resource, or function.
Modified
p. 34 → 38
Authorize To permit or give authority to a user to communicate with or make use of an object, resource or function.
Authorize To permit or give authority to a user to communicate with or make use of an object, resource, or function.
Removed
p. 35
Clear-text See Plaintext.
Modified
p. 35 → 39
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 plaintext 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 clear-text cryptographic keys and other keying material).
Modified
p. 35 → 39
Critical Security Parameters (CSP) Security-related information (e.g., secret and private cryptographic keys, and authentication data such as passwords and personal identification numbers (PINs)) whose disclosure or modification can compromise the security of a cryptographic module.
Critical Security Parameters (CSP) Security-related information⎯e.g., secret and private cryptographic keys, and authentication data such as passwords/authentication codes•whose disclosure or modification can compromise the security of a cryptographic module.
Modified
p. 35 → 40
• The transformation of plaintext data into ciphertext data,
• The transformation of clear-text data into ciphertext data,
Modified
p. 35 → 40
• The transformation of ciphertext data into plaintext data,
• The transformation of ciphertext data into clear-text data,
Removed
p. 36
Cryptoperiod Time during which a key can be used for signature verification or decryption; it should extend well beyond the lifetime of a key (where the lifetime is the time during which a key can be used to generate a signature and/or perform encryption).
Cryptosystem A system used for the encryption and decryption of data.
Dictionary Attack Attack in which an adversary builds a dictionary of plaintext and corresponding ciphertext. When a match can be made between intercepted ciphertext and dictionary-stored ciphertext, the corresponding plaintext is immediately available from the dictionary.
Cryptosystem A system used for the encryption and decryption of data.
Dictionary Attack Attack in which an adversary builds a dictionary of plaintext and corresponding ciphertext. When a match can be made between intercepted ciphertext and dictionary-stored ciphertext, the corresponding plaintext is immediately available from the dictionary.
Modified
p. 36 → 40
Decrypt A process of transforming ciphertext (unreadable) into plaintext (readable).
Decrypt A process of transforming ciphertext (unreadable) into clear text (readable).
Modified
p. 36 → 40
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 (e.g., terminals) TRSMs.
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.
Removed
p. 37
DTP Detailed Test Procedure.
Modified
p. 37 → 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 Split Knowledge.
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 Split Knowledge.
Modified
p. 37 → 41
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. 37 → 41
Electronic Key Entry 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 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.
Modified
p. 37 → 41
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 plaintext into ciphertext.
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.
Modified
p. 37 → 41
Encrypted Key (Ciphertext Key) A cryptographic key that has been encrypted with a key-encrypting key, a PIN, or a password in order to disguise the value of the underlying plaintext 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 clear-text key.
Removed
p. 38
Hash A (mathematical) function, which is a non-secret algorithm, which takes any arbitrary length message as input and produces a fixed length hash result. Approved hash functions satisfy the following properties:
Modified
p. 38 → 43
• One-Way. It is computationally infeasible to find any input that maps to any pre-specified output.
Modified
p. 38 → 43
• Collision Resistant. It is computationally infeasible to find any two distinct inputs⎯e.g., messages⎯that map to the same output.
Removed
p. 39
IPsec Internet Protocol security is a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session.
Modified
p. 39 → 44
ISO International Organization for Standardization. An international standards setting organization composed of representatives from various national standards.
ISO International Organization for Standardization. An international standards- setting organization composed of representatives from various national standards.
Modified
p. 39 → 44
Joint Interpretation Library (JIL) A set of documents agreed upon by the British, Dutch, French and German Common Criteria Certification Bodies to provide a common interpretation of Common Criteria for composite evaluations, attack paths, attack quotations, and methodology.
Joint Interpretation Library (JIL) A set of documents agreed upon by the British, Dutch, French, and German Common Criteria Certification Bodies to provide a common interpretation of Common Criteria for composite evaluations, attack paths, attack quotations, and methodology.
Modified
p. 39 → 44
Key (Secret) Share One of at least two parameters related to a cryptographic key generated in such a way that a quorum of such parameters can be combined to form the cryptographic key but such that less than a quorum does not provide any information about the key.
Key (Secret) Share One of at least two parameters related to a cryptographic key generated in such a way that a quorum of such parameters can be combined to form the cryptographic key, but such that less than a quorum does not provide any information about the key.
Removed
p. 40
Key Instance The occurrence of a key in one of its permissible forms, that is, plaintext key, key components and enciphered key.
Modified
p. 40 → 44
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 …
Modified
p. 40 → 44
Key-Encrypting (Encipherment Or Exchange) Key (KEK) A cryptographic key that is used for the encryption or decryption of other keys. Also known as a key-encryption or key-exchange key.
Key-Encrypting (Encipherment or Exchange) Key (KEK) A cryptographic key that is used for the encryption or decryption of other keys. Also known as a key-encryption or key-exchange key.
Modified
p. 40 → 45
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:
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:
Modified
p. 40 → 45
• Export of a key from one secure cryptographic device (SCD) to another SCD in plaintext, component, or enciphered form;
• Export of a key from one secure cryptographic device (SCD) to another SCD in clear-text, component, or enciphered form;
Modified
p. 40 → 45
• Export of a key component from an SCD into a tamper-evident package (e.g., blind mailer);
• Export of a key component from an SCD into a tamper-evident package⎯e.g., blind mailer;
Modified
p. 40 → 45
• Temporary storage of the key in plaintext, component, or enciphered form within an SCD during transfer.
• Temporary storage of the key in clear-text, component, or enciphered form within an SCD during transfer.
Modified
p. 40 → 45
Key Management The activities involving the handling of cryptographic keys and other related security parameters (e.g., initialization vectors, counters) during the entire life cycle of the keys, including their generation, storage, distribution, loading and use, deletion, destruction and archiving.
Key Management The activities involving the handling of cryptographic keys and other related security parameters⎯e.g., initialization vectors, counters⎯during the entire life cycle of the keys, including their generation, storage, distribution, loading and use, deletion, destruction, and archiving.
Removed
p. 41
Key Termination Occurs when a key is no longer required for any purpose and all copies of the key and information required to regenerate or reconstruct the key have been deleted from all locations where they ever existed.
Modified
p. 41 → 45
Key-Loading Device A self-contained unit that is capable of storing at least one plaintext or encrypted cryptographic key or key component that can be transferred, upon request, into a cryptographic module.
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. 41 → 45
Keying Material The data (e.g., keys and initialization vectors) necessary to establish and maintain cryptographic keying relationships.
Keying Material The data⎯e.g., keys and initialization vectors⎯necessary to establish and maintain cryptographic keying relationships.
Modified
p. 41 → 46
Manual Key Distribution The distribution of cryptographic keys, often in a plaintext 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 clear-text form requiring physical protection, but using a non-electronic means, such as a bonded courier.
Removed
p. 42
Opaque Impenetrable by light (i.e., light within the visible spectrum of wavelength range of 400nm to 750nm); neither transparent nor translucent within the visible spectrum.
Physically Secure Environment An environment that is equipped with access controls or other mechanisms designed to prevent any unauthorized access that would result in the disclosure of all or part of any key or other secret data stored within the environment. Examples include a safe or a room built with continuous access control, physical security protection, and monitoring.
Plaintext The intelligible form of an encrypted text or of its elements.
Plaintext Key An unencrypted cryptographic key, which is used in its current form.
Physically Secure Environment An environment that is equipped with access controls or other mechanisms designed to prevent any unauthorized access that would result in the disclosure of all or part of any key or other secret data stored within the environment. Examples include a safe or a room built with continuous access control, physical security protection, and monitoring.
Plaintext The intelligible form of an encrypted text or of its elements.
Plaintext Key An unencrypted cryptographic key, which is used in its current form.
Modified
p. 42 → 47
Private Key A cryptographic key, used with a public key cryptographic algorithm that is uniquely associated with an entity and is not made public.
Private Key A cryptographic key used with a public key cryptographic algorithm that is uniquely associated with an entity and is not made public.
Modified
p. 43 → 47
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 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.
Modified
p. 43 → 48
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 for both …
Modified
p. 43 → 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.
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.
Modified
p. 44 → 49
Secure Key Loader A self-contained unit that is capable of storing at least one plaintext 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 clear-text or encrypted cryptographic key or key component that can be transferred, upon request, into a cryptographic module.
Modified
p. 44 → 49
Sensitive (Secret) Data (Information) Data that must be protected against unauthorized disclosure, alteration or destruction, especially plaintext PINs, and secret and private cryptographic keys, and includes design characteristics, status information, and so forth.
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. 44 → 49
Session Key A key established by a key-management protocol, which provides security services to data transferred between the parties. A single protocol execution may establish multiple session keys, e.g., an encryption key and a MAC key.
Session Key A key established by a key-management protocol, which provides security services to data transferred between the parties. A single protocol execution may establish multiple session keys⎯e.g., an encryption key and a MAC key.
Modified
p. 45 → 50
Split Knowledge A condition under which two or more entities separately have key components that individually convey no knowledge of the resultant cryptographic key.
Split Knowledge A condition under which two or more entities separately have information (e.g., key components) that individually convey no knowledge of the resultant combined information (e.g., a cryptographic key).
Modified
p. 46 → 51
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.