HOME   Cart(0)   Quotation   About-Us Policy PDFs Standard-List
www.ChineseStandard.net Database: 189760 (18 Oct 2025)

GB/T 37092-2018 PDF English

US$565.00 · In stock · Download in 9 seconds
GB/T 37092-2018: Information security technology -- Security requirements for cryptographic modules
Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See step-by-step procedure
Status: Valid
Standard IDContents [version]USDSTEP2[PDF] deliveryName of Chinese StandardStatus
GB/T 37092-2018English565 Add to Cart 0-9 seconds. Auto-delivery Information security technology -- Security requirements for cryptographic modules Valid

Excerpted PDFs (Download full copy in 9 seconds upon purchase)

PDF Preview: GB/T 37092-2018
      

Similar standards

GB/T 36959   GB/T 36958   GB/T 36651   GB/T 37091   

GB/T 37092-2018: Information security technology -- Security requirements for cryptographic modules


---This is an excerpt. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.), auto-downloaded/delivered in 9 seconds, can be purchased online: https://www.ChineseStandard.net/PDF.aspx/GBT37092-2018
GB NATIONAL STANDARD OF THE PEOPLE’S REPUBLIC OF CHINA ICS 35.040 L 80 Information security technology - Security requirements for cryptographic module Issued on: DECEMBER 28, 2018 Implemented on: JULY 01, 2019 Issued by. State Administration for Market Regulation; Standardization Administration of the People’s Republic of China.

Table of Contents

Foreword... 3 Introduction... 4 1 Scope... 5 2 Normative references... 5 3 Terms and definitions... 6 4 Abbreviated terms... 9 5 Cryptographic module security level... 10 5.1 General... 10 5.2 Security level 1... 11 5.3 Security level 2... 11 5.4 Security level 3... 12 5.5 Security level 4... 13 6 Functional security target... 13 7 Security requirements... 14 7.1 General requirements... 14 7.2 Cryptographic module specifications... 18 7.3 Cryptographic module interface... 22 7.4 Roles, services, and authentication... 25 7.5 Software/firmware security... 31 7.6 Operational environment... 33 7.7 Physical security... 39 7.8 Non-invasive security... 50 7.9 Sensitive security parameter management... 51 7.10 Self-test... 56 7.11 Life cycle assurance... 61 7.12 Mitigations for other attacks... 67 Appendix A (Normative) Documentation requirements... 69 Appendix B (Normative) Cryptographic module security policy... 78 Appendix C (Normative) Approved security functions... 85 Appendix D (Normative) Approved methods for generating and establishing sensitive security parameters... 87 Appendix E (Normative) Approved authentication mechanism... 88 Appendix F (Normative)) Detection indicators of non-invasive attacks and mitigation methods... 89 Bibliography... 91 Information security technology - Security requirements for cryptographic module

1 Scope

This Standard specifies security requirements for cryptographic modules, defines four security levels for cryptographic modules, and gives corresponding requirements for the four security levels. This Standard applies to cryptographic modules used in security systems for protecting sensitive information in computer and telecommunication systems. This Standard also provides guidance for the design and development of cryptographic modules and a reference for the testing of cryptographic module security requirements.

2 Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. GB/T 15843 (all parts), Information technology - Security techniques - Entity authentication GB/T 15852 (all parts), Information technology - Security techniques - Message authentication codes GB/T 17964, Information security technology - Modes of operation for a block cipher GB/T 25069, Information security technology - Glossary GB/T 32905, Information security techniques - SM3 cryptographic hash algorithm GB/T 32907, Information security technology - SM4 block cipher algorithm GB/T 32918 (all parts), Information security technology - Public key cryptographic algorithm SM2 based on elliptic curves GB/T 33133.1, Information security technology - ZUC stream cipher algorithm - Part 1.Algorithm description All sentences containing "shall [xx.yy]" in the following text of this Standard are regarded as a security requirement of the cryptographic module. This identification method can be directly referenced by the subsequent test standards corresponding to this Standard, and can also be referenced by the documents submitted by the cryptographic module manufacturer. 5.2 Security level 1 Security level 1 provides the lowest level of security requirements. Security level 1 states the basic security requirements for cryptographic modules, for example, cryptographic modules shall use at least one approved security function or an approved sensitive security parameter establishment method. Software or firmware cryptographic modules can run in unmodifiable, restricted, or modifiable operational environments. In addition to meeting the basic requirements of product-level components, hardware cryptographic modules have no other special physical security mechanism requirements. Mitigations implemented by cryptographic modules against non-invasive or other attacks need to be documented. Examples of security level 1 cryptographic modules include hardware encryption boards in personal computers and cryptographic toolkits running on handheld devices or general-purpose computers. When the application system outside the cryptographic module has been configured with physical security, network security, and management process control measures, the cryptographic module of security level 1 is very suitable. This allows users of cryptographic modules to choose from a variety of cryptographic solutions to meet security requirements. 5.3 Security level 2 Security level 2 adds requirements for disassembly evidence based on security level 1, such as using tamper-evident coatings or seals, or adding pick-resistant locks to covers or doors to provide disassembly evidence. Tamper-evident seals or pick-resistant locks shall be installed on covers or doors to prevent unauthorized physical access. When physical access is made to the secure parameters within the cryptographic module, any tamper-evident coating or seal on the cryptographic module shall be broken. Security level 2 requires role-based authentication. The cryptographic module needs to identify and verify the operator's role to determine whether he or she has the authority to perform the corresponding service. The software cryptographic module of security level 2 can run in a modifiable environment, which shall implement role-based access control or autonomous access control, but autonomous access control shall be able to define new groups, assign permissions through access control lists (ACLs), and assign a user to multiple groups. Access control measures shall prevent unauthorized execution, modification, and reading of software that implements cryptographic functions. 5.4 Security level 3 In addition to the physical security mechanisms for disassembly traces required in security level 2, security level 3 also requires stronger physical security mechanisms to further prevent unauthorized access to sensitive security parameters within the cryptographic module. These physical security mechanisms shall be able to detect and respond with a high probability to the following actions. direct physical access, use or modification of the cryptographic module, and probing of the cryptographic module through vents or gaps. The physical security mechanisms described above may include a rugged housing, tamper detection devices, and response circuits. When the cover/door of the cryptographic module is opened, the response circuit shall reset all key security parameters to zero. Security level 3 requires an identity-based authentication mechanism to improve the security of the role-based authentication mechanism in security level 2.The cryptographic module needs to authenticate the identity of the operator and verify whether the authenticated operator is authorized to assume a specific role and can perform the corresponding services. Security level 3 requires that manually established plaintext critical security parameters are encrypted, input or output using a trusted channel or split knowledge. Cryptographic modules of security level 3 shall effectively prevent voltage and temperature from exceeding the normal operating range of the cryptographic module and damaging the security of the cryptographic module. An attacker can deliberately make the environmental parameters of the cryptographic module deviate from the normal operating range, thereby bypassing the protective measures of the cryptographic module. Cryptographic modules shall be designed with environmental protection features to detect environmental anomalies and reset critical security parameters to zero, or be able to pass environmental failure tests to provide a reasonable guarantee to ensure that the security of the cryptographic module will not be compromised due to environmental anomalies. Cryptographic modules of security level 3 shall provide evidence of the effectiveness and detection methods of non-invasive attack mitigation technologies. For software cryptographic modules, security level 3 requirements are not given in all clauses of this Standard. Therefore, the maximum overall security level that can be achieved by the software cryptographic module is limited to security level 2. Cryptographic modules of security level 3 add lifecycle assurance requirements, such as automated configuration management, detailed design, low-level testing, and operator authentication based on authentication information provided by the manufacturer. 5.5 Security level 4 Security level 4 is the highest security level in this Standard. This level includes all the security features of the lower levels, as well as some extended features. The physical security mechanism of security level 4 shall provide a complete enclosure protection around the cryptographic module, with the purpose of detecting and responding to all unauthorized physical access when the cryptographic module contains sensitive security parameters, regardless of whether external power is supplied. Penetration of the cryptographic module's enclosure from any direction will be detected with a high probability and will cause all unprotected sensitive security parameters to be immediately reset to zero. Since the cryptographic module of security level 4 has a high security mechanism, it is particularly suitable for environments without physical protection. Security level 4 requires multi-factor authentication of operators. At a minimum, two of the following factors are required. -- Something known, such as a secret password; -- Something processed, such as a physical key or token; -- Certain attribute processed, such as biological characteristics. Cryptographic modules of security level 4 shall effectively prevent voltage and temperature from exceeding the normal operating range of the cryptographic module and damaging the security of the cryptographic module. Cryptographic modules shall be designed with environmental protection features specifically for detecting environmental anomalies and resetting critical security parameters to zero, thereby providing a reasonable guarantee to ensure that the security of the cryptographic module will not be compromised due to environmental anomalies. According to the non-invasive attack mitigation detection indicators of security level 4 stipulated by relevant national departments, test the mitigation methods for non- invasive attacks stipulated in 7.8 implemented in the cryptographic module. Security level 4 requires that the design of the cryptographic module shall pass consistency verification, that is, verifying the consistency between the pre- and post- conditions and the functional specifications.

6 Functional security target

The security requirements specified in this Standard involve the secure design and implementation of cryptographic modules. Security requirements start from the lowest level of security targets and increase as the security target levels increase. These requirements are derived from the following functional security targets for cryptographic modules. -- Use and properly implement approved security functions to protect sensitive information; -- Prevent unauthorized operation or use of cryptographic modules; -- Prevent unauthorized disclosure of the contents of cryptographic modules, including critical security parameters; -- Prevent unauthorized or undetectable modification of cryptographic modules and cryptographic algorithms, including unauthorized modification, replacement, insertion, and deletion of sensitive security parameters; -- Provide an indication of the operational state of the cryptographic module; -- Ensure that the cryptographic module can operate correctly in the approved operation mode; -- Detect errors in the operation of cryptographic modules to prevent these errors from unauthorized disclosure, modification, replacement or use of critical security parameters, or unauthorized modification or replacement of public security parameters; -- Ensure that cryptographic modules are designed, allocated and implemented correctly.

7 Security requirements

7.1 General requirements Cryptographic modules conforming to this Standard shall [01.01] meet the security requirements. These security requirements cover areas related to the design, implementation, operation, and decommissioning of cryptographic modules, including. cryptographic module specifications; cryptographic module interfaces; roles, services, and authentication; software/firmware security; operational environment; physical security; non-invasive security; sensitive security parameter management; self-test; life cycle assurance; and mitigation of other attacks. Table 1 summarizes the security requirements for each domain. Cryptographic modules shall [01.02] be tested against the requirements of each domain. Cryptographic modules shall [01.03] be rated independently in each domain. Among the 11 security domains mentioned above, the security requirements of some domains increase accordingly as the security level increases. The ratings obtained by the cryptographic module in these domains reflect the highest security level that the -- Hybrid software cryptographic module. The cryptographic boundary demarcates the set of software components and separated hardware components (i.e., the software components are not within the hardware cryptographic module boundary). The computing platform and operating system in which the software runs are outside the boundaries of the defined hybrid software cryptographic module. -- Hybrid firmware cryptographic module. The cryptographic boundary demarcates the combination of firmware components and separated hardware components (i.e., the firmware components are not within the hardware cryptographic module boundary). The computing platform and operating system included in the environment where the firmware runs are outside the defined hybrid firmware cryptographic module boundary, but are explicitly bound to the hybrid firmware cryptographic module. For hardware and firmware cryptographic modules, all applicable requirements for physical security as specified in 7.7 and for non-invasive security as specified in 7.8 shall [02.04] be met. For software cryptographic modules operating in a modifiable environment, all applicable requirements for non-invasive security as specified in 7.8 shall [02.05] be met; the physical security requirements as specified in 7.7 are optional. For hybrid cryptographic modules, all applicable requirements for software/firmware security as specified in 7.5, for operational environment as specified in 7.6, for physical security as specified in 7.7, and for non-intrusive security as specified in 7.8 shall [02.06] be met. 7.2.3 Cryptographic boundary 7.2.3.1 General requirements for cryptographic boundary The cryptographic boundary shall [02.07] consist of a well-defined boundary (e.g., a collection of hardware, software, or firmware components) that establishes the boundaries of all components of the cryptographic module. The requirements of this Standard shall [02.08] apply to all algorithms, security functions, processes and components within the cryptographic boundary. The cryptographic boundary shall [02.09] include at least all security-related algorithms, security functions, processes and components within the cryptographic module (i.e., those that are security-related within the scope of this Standard). Non-security related algorithms, security functions, processes and components may also be included within the cryptographic boundary. The implementation of non-security related algorithms, security functions, processes and components used in approved operation modes shall [02.10] not interfere with or undermine the approved operation of the cryptographic module. The name of a cryptographic module shall [02.11] represent the component composition within the cryptographic boundary and shall not represent a composition -- An instance of a cryptographic module that is held in memory and executed by one or more processors. d) The cryptographic boundary of a hybrid cryptographic module shall [02.18]. -- consist of the boundaries of the cryptographic module hardware components and the boundaries of the separate software or firmware components; -- contain the collection of all ports and interfaces for each component. For hybrid cryptographic modules, in addition to separate software or firmware components, the hardware components of the cryptographic module may also include embedded software or firmware. 7.2.4 Operation mode 7.2.4.1 General requirements for operation mode The cryptographic module can have an approved operation mode and an unapproved operation mode. The approved operation mode means that the cryptographic module can only use approved security functions to provide security-related services in this operation mode. The operator shall [02.19] be able to operate the cryptographic module in the approved operation mode. An approved operation mode shall [02.20] be defined as a set of services where at least one service uses an approved cryptographic algorithm, security function or process. Non-approved cryptographic algorithms, security functions and processes, or other services not specified in 7.4.3 shall not [02.21] be used by operators in an approved operation mode unless the non-approved cryptographic algorithm or security function is part of an approved process and is not relevant to the security of the approved process. For example, using unapproved cryptographic algorithms or keys generated in an unapproved manner, obfuscating data or critical security parameters, the results are also considered unprotected plaintext and cannot provide security-related functions. 7.2.4.2 Normal operation Normal operation means that the complete set of algorithms, security functions, services, or processes are available and/or configurable. Critical security parameters of approved and non-approved services and operation modes shall [02.22] be separated from each other, i.e., not shared or accessible to each other. The output of an approved randomizer may be provided to a non-approved algorithm, security function, or process without zeroing the seed as long as the randomizer seed cannot be accessed in an unapproved mode. The cryptographic module security policy shall [02.23] define the complete set of services for each operation mode (authorized and non-authorized) included in the cryptographic module. When the service is using approved cryptographic algorithms, security functions or processes in an approved manner, as well as other services or processes specified in 7.4.3, the service shall [02.24] provide an appropriate status indication. 7.2.4.3 Degraded operation Degraded operation means that when a cryptographic module enters an error state, the operational set of certain algorithms, security functions, services or processes are still available and/or configurable. This Standard requires that when any error occurs in the cryptographic module, it shall [02.25] enter an error state and stop working, and cannot downgrade its operation. 7.3 Cryptographic module interface 7.3.1 General requirements for cryptographic module interfaces All logical information flows into and out of the cryptographic module shall [03.01] only pass through defined physical ports and logical interfaces that are the entry and exit points into and out of the cryptographic boundary. The logical interfaces of a cryptographic module shall [03.02] be separate from each other. These logical interfaces may share a physical port, for example, input data and output data may use the same port, or the logical interfaces may be distributed over one or more physical ports, for example, input data may be transmitted through both a serial port and a parallel port. The application programmer’s interface (API) of a cryptographic module software component may be defined as one or more logical interfaces. Cryptographic module documentation shall [03.03] be prepared in accordance with the requirements of A.2.3. 7.3.2 Interface type The interface types of the cryptographic module include. -- The hardware cryptographic module interface is defined as a complete set of commands used to request hardware cryptographic module services, where the commands requesting services include parameters input to or output by the cryptographic module. -- The software or firmware cryptographic module interface is defined as a complete set of commands used to request software or firmware cryptographic module services, where the commands requesting services include parameters input to or output by the cryptographic module. -- The hybrid firmware or hybrid software cryptographic module interface is defined as a complete set of commands used to request hybrid firmware or hybrid software cryptographic module services, where the commands requesting services include parameters input to or output by the cryptographic module. 7.3.3 Interface definition A cryptographic module shall [03.04] have the following five interfaces (“input” and “output” are relative to the cryptographic module). -- Data input interface. All input data processed by the cryptographic module (except control data input through the "control input" interface), including plaintext, ciphertext, sensitive security parameters and status information of another cryptographic module, shall [03.05] be input through the "data input" interface. When the cryptographic module performs the self-test in 7.10, the cryptographic module can receive data through the data input interface. -- Data output interface. Except for the status data output through the "status output" interface and the control data output through the "control output" interface, all output data from the cryptographic module, including plaintext, ciphertext and sensitive security parameters, etc., shall [03.06] be output through the "data output" interface. During manual input, pre-operational self- test, software/firmware loading and zeroing, or when the cryptographic module is in an error state, data output through the "data output" interface shall [03.07] be prohibited. -- Control input interface. All input commands, signals (e.g., clock inputs) and control data (including manual controls such as switches, buttons and keyboards, as well as function calls) used to control the operation of the cryptographic module shall [03.08] be input through the “control input” interface. -- Control output interface. All output commands, signals and control data used to control the operation of the cryptographic module (for example, control commands to another cryptographic module) shall [03.09] be output through the "control output" interface. When the cryptographic module is in the error state, control outputs through the "control output" interface shall [03.10] be disabled unless some exceptions are specified in the security policy. -- Status output interface. All output signals, indicators (e.g., error indicators), and status data used to indicate the status of the cryptographic module [including return codes and physical indicators, such as visual (display, indicator lights), audible (buzzer, bell), and mechanical (vibrator)] shall [03.11] be output through the "status output" interface. Status output can be explicit or implicit. All cryptographic modules, except software cryptographic modules, shall [03.12] have the following interfaces. -- Power interface. All external power input to the cryptographic module shall [03.13] be input through the power port. A power port is not required and may not be present when all energy is provided or maintained within the cryptographic boundary of the cryptographic module (e.g., by an internal battery). A cryptographic module shall [03.14] distinguish between inputs of data, control information, and power, and outputs of data, control information, status information, and power. The cryptographic module specification shall [03.15] clearly define the format of input data and control information, including length limits for all variable- length inputs. 7.3.4 Trusted channel A trusted channel is a link established between a cryptographic module and a sender or receiver for securely transmitting unprotected plaintext key components, authentication data, and other critical security parameters. A plaintext key is a key that has not been encrypted or has been obfuscated by an unauthorized method. A trusted channel, at the input or output port defined by the cryptographic module as well as the communication link of the intended sender or receiver terminal, can prevent eavesdropping and physical or logical tampering by malicious operators/entities, processes, or other devices. Requirements for trusted channel of cryptographic modules include. a) Security level 1 and security level 2. For security level 1 and security level 2, there is no requirements for trusted channel. b) Security level 3. For security level 3. -- A cryptographic module shall [03.16] implement a trusted channel for the transmission of unprotected plaintext key components, authentication data, and other critical security parameters between the cryptographic module and the sender or receiver terminal; -- Trusted channels shall [03.17] prevent unauthorized modification, replacement, and disclosure of information on the communication link; -- The physical ports used by the trusted channel shall [03.18] be physically isolated from other physical ports; alternatively, the logical interfaces used by the trusted channel shall [03.19] be logically isolated from other logical interfaces; ......
Source: Above contents are excerpted from the full-copy PDF -- translated/reviewed by: www.ChineseStandard.net / Wayne Zheng et al.


      

Tips & Frequently Asked Questions

Question 1: How long will the true-PDF of English version of GB/T 37092-2018 be delivered?

Answer: The full copy PDF of English version of GB/T 37092-2018 can be downloaded in 9 seconds, and it will also be emailed to you in 9 seconds (double mechanisms to ensure the delivery reliably), with PDF-invoice.

Question 2: Can I share the purchased PDF of GB/T 37092-2018_English with my colleagues?

Answer: Yes. The purchased PDF of GB/T 37092-2018_English will be deemed to be sold to your employer/organization who actually paid for it, including your colleagues and your employer's intranet.

Question 3: Does the price include tax/VAT?

Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countries

Question 4: Do you accept my currency other than USD?

Answer: Yes. www.ChineseStandard.us -- GB/T 37092-2018 -- Click this link and select your country/currency to pay, the exact amount in your currency will be printed on the invoice. Full PDF will also be downloaded/emailed in 9 seconds.

How to buy and download a true PDF of English version of GB/T 37092-2018?

A step-by-step guide to download PDF of GB/T 37092-2018_EnglishStep 1: Visit website https://www.ChineseStandard.net (Pay in USD), or https://www.ChineseStandard.us (Pay in any currencies such as Euro, KRW, JPY, AUD).
Step 2: Search keyword "GB/T 37092-2018".
Step 3: Click "Add to Cart". If multiple PDFs are required, repeat steps 2 and 3 to add up to 12 PDFs to cart.
Step 4: Select payment option (Via payment agents Stripe or PayPal).
Step 5: Customize Tax Invoice -- Fill up your email etc.
Step 6: Click "Checkout".
Step 7: Make payment by credit card, PayPal, Google Pay etc. After the payment is completed and in 9 seconds, you will receive 2 emails attached with the purchased PDFs and PDF-invoice, respectively.
Step 8: Optional -- Go to download PDF.
Step 9: Optional -- Click Open/Download PDF to download PDFs and invoice.
See screenshots for above steps: Steps 1~3    Steps 4~6    Step 7    Step 8    Step 9