Codeofchina.com is in charge of this English translation. In case of any doubt about the English translation, the Chinese original shall be considered authoritative.
This standard is developed in accordance with the rules given in GB/T 1.1-2009.
This standard was proposed by and is under the jurisdiction of the National Technical Committee on Information Security of Standardization Administration of China (SAC/TC 260).
Drafting organizations of this standard: Data Assurance and Communication Security Research Center of Chinese Academy of Sciences, Commercial Cryptography Testing Center of State Cryptography Administration, Beijing Watchdata Intelligent Technologies Co., Ltd., Beijing Certificate Authority, Feitian Technologies Co., Ltd., Beijing Haitai Fangyuan Technologies Co,.Ltd., Beijing Huada Zhibao Electronic System Co., Ltd. and Beijing Creative Century Information Technology Co., Ltd.
Chief drafters of this standard: Jing Jiwu, Gao Neng, Tu Chenyang, Zheng Fangyu, Jiang Weiyu, Zhou Guoliang, Liu Zongbin, Liu Zeyi, Wang Jing, Luo Peng, Wang Xuelin, Chen Guo, Zhan Banghua, Zhu Pengfei, Jiang Hongyu, Chen Yue, Zhang Wantao, Liu Limin and Xiang Ji.
Introduction
In Information Technology, there is an increasing need to use cryptographic technique such as the protection of data against unauthorized disclosure or manipulation, for entity authentication and for nonrepudiation. The security and reliability of cryptographic mechanisms are directly dependent on the cryptographic modules in which they are implemented.
This standard provides four progressive and qualitative security levels for the cryptographic modules, but doesn't specify the correct application and secure deployment of a cryptographic module. During the use or deployment of cryptographic module, the operator of cryptographic module is responsible for ensuring that the security provided by the module is sufficient and acceptable to the owner of the information, and that any residual risk is informed to the owner of the information. The operator of cryptographic module is responsible for selecting a cryptographic module of appropriate security level to ensure that the cryptographic module adapts to security requirements necessary for application and the security state of environment where it is used.
Information security technology - Security requirements for cryptographic modules
1 Scope
This standard specifies the security requirements for cryptographic modules, and defines four security levels for cryptographic modules and corresponding requirements.
This standard is applicable to cryptographic modules used in security systems protecting the sensitive information in computer and telecommunications system. This standard also provides guidance for the design and development of cryptographic modules, and provides a reference for the detection of security requirements for cryptographic modules.
2 Normative references
The following referenced documents are indispensable for the application 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 (MACs)
GB/T 17964 Information technology - Security techniques - 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
GM/T 0001.2 ZUC Stream cipher algorithm - Part 2: The ZUC-based confidentiality algorithm
GM/T 0001.3 ZUC Stream Cipher Algorithm - Part 3: The ZUC-based integrity algorithm
GM/T 0044 (All parts) SM9 identification cryptographic algorithm
3 Terms and definitions
For the purposes of this document, the terms and definitions given in GB/T 25069 and the following apply.
3.1
certificate
data of an entity, which is issued by the certification authority's private key or secret key and cannot be forged
3.2
conditional self-test
test performed by a cryptographic module when specified test conditions occur
3.3
critical security parameter
security relevant secret information which may endanger the security of cryptographic module once disclosed or modified
Note: critical security parameter may be in plaintext or encrypted.
3.4
cryptographic boundary
clearly defined perimeter that establishes physical and/or logical boundaries and includes all hardware, software and/or firmware components of the cryptographic module
3.5
cryptographic module
set of hardware, software and/or firmware implementing security function, which is included within the cryptographic boundary
Note: cryptographic modules may be classified into hardware cryptographic module, firmware cryptographic module, software cryptographic module and hybrid cryptographic module according to composition.
3.6
cryptographic module interface
logical entry or exit of a cryptographic module, providing access for logical information flow
3.7
cryptographic module security policy
clear description of security rules which shall be complied with by cryptographic module, including the rules derived from the requirements of this standard and those required by the vendor
3.8
differential power analysis
analysis on power consumption change of cryptographic module, which is used to obtain information related to cryptographic operation
3.9
fault induction
technology causing change of operational behavior in hardware by applying transient voltage, radiation, laser or clock offset technology
3.10
multi-word authentication
authentication containing at least two independent authentication factors
Note: categories of independent authentication factors include: something known, something possessed mater and property possessed.
3.11
non-invasive attack
attack on cryptographic module, which is not in direct physical contact with the components within the cryptographic boundary, and does not change the state of the cryptographic module
3.12
operational environment
set of all software, firmware and hardware required for secure operation of cryptographic module, including operating system and hardware platform
Note: the operational environment is classified into modifiable operational environment, limited operational environment and unmodifiable operational environment.
3.13
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 before the module transition to the operational state
3.14
public security parameter
security relevant public information which may endanger the security of cryptographic module once modified
Note: for example, public key, public key certificate, self-signed certificate, trust anchor, one-time password associated with the counter and the date and time kept internally. If the public security parameter cannot be modified or can be discovered by the cryptographic module after being modified, the public security parameter may be considered as protected.
3.15
runtime environment
virtual machine state that provides software service for processes and programs while the computer is running
Note: the runtime environment may be related to the operating system or the software running under it. Its main purpose is to achieve a "platform-independent" programming target.
3.16
security function
cryptographic algorithm and its working mode, including: block cipher, stream cipher, asymmetric cipher, message authentication code, hash function, random number generation, entity authentication, generation and establishment of sensitive security parameters, etc.
3.17
sensitive security parameters
including critical security parameter (3.3) and public security parameter (3.14)
3.18
simple power analysis
direct (mainly visual) analysis on (single) command execution mode, which is related to the power consumption of cryptographic module and used to obtain information related to cryptographic operation
3.19
split knowledge
process in which a key is split into multiple key components and output from cryptographic module to multiple entities. Single component cannot provide knowledge of the original key. The key component entered into cryptographic module by each entity can be synthesized into the original key, which may require all components or a part of them
3.20
sensitive security parameter establishment
process of providing shared sensitive security parameters to one entity or more entities
Note: sensitive security parameter establishment includes negotiation, transfer and entry/output of sensitive security parameter.
4 Abbreviations
For the purposes of this document, the following abbreviations apply.
API: Application Program Interface
CBC: Cipher Block Chaining
ECB: Electronic Codebook
EDC: Error Detection Code
EFP: Environmental Failure Protection
EFT: Environmental Failure Testing
FSM: Finite State Model
HDL: Hardware Description Language
HMAC: Hash-Based Message Authentication Code
IC: Integrated Circuit
PIN: Personal Identification Number
5 Security level of cryptographic module
5.1 Overview
A cryptographic module refers to the hardware, software, firmware or the set of them, implementing functions such as cryptographic operation and key management. This standard is applicable to cryptographic modules used in security systems protecting the sensitive information in computer and telecommunications system. In order to protect the cryptographic modules and the sensitive security parameters contained in and controlled by the cryptographic modules as well as to meet the security requirements in many application fields and of different levels, this standard specifies four progressing security levels, among which, the high-level ones are improved based on low-level ones. Common examples given in this standard are used to illustrate how to meet the security requirements hereof other than for restriction or enumeration. Four security levels are outlined below. The cryptographic techniques are identical over the four security levels.
In this standard, each security requirement is identified and numbered by a "shall [xx.yy]" where xx indicates the clause and yy is a numeric index of the clause. If "shall [xx.yy]" occurs in certain sentence in this standard, it means that this sentence is a security requirement of this standard with serial number of [xx.yy]. There are 12 clauses in total in this standard, corresponding to the common security requirements and 11 security domains of cryptographic modules; wherein, 1~12 represent respectively: general requirements; cryptographic module specification; cryptographic module interface; roles, services and authentication; software/firmware security; operational environment; physical security; non-invasive security; management of sensitive security parameters; self-test; life-cycle assurance; mitigation of other attacks. Specific security requirements are contained in each clause, which are numbered in sequence from [xx..01].
Each sentence in this standard thereinafter containing "shall [xx.yy]" shall be considered a security requirement of the cryptographic module; such identification may be directly cited by the corresponding subsequent detection standard of this standard and cited by documentation submitted by the cryptographic module vendor.
5.2 Security Level 1
Security Level 1 provides a baseline level of security. Security Level 1 clarifies the basic security requirements for cryptographic modules. For example, a cryptographic module shall use at least one approved security function or sensitive security parameter establishment method. A software or firmware cryptographic module may run in an unmodifiable, limited or modifiable operational environment. A hardware cryptographic module is unnecessary to reach other special physical security mechanism requirements except for the basic requirements for production-grade components. Mitigation methods implemented by the cryptographic module against non-invasive attack or other attacks shall be documented. Examples of cryptographic modules of Security Level 1 are: hardware encryption card in personal computer, cryptographic toolkit running on handheld device or general-purpose computer.
Cryptographic module of Security Level 1 is well suitable when the application system outside the cryptographic module has been configured with measures such as physical security, network security and management process, thus allowing the user of cryptographic module to choose from various cryptographic solutions to meet security needs.
5.3 Security Level 2
For Security Level 2, requirements for tamper evidence are added based on Security Level 1, such as using tamper-evident coatings or seals or pick-resistant locks on removable covers or doors.
Tamper-evident seals or pick-resistant locks shall be installed on removable covers or doors to protect against unauthorized physical access. The tamper-evident coating or seal shall be broken when obtaining physical access to security parameters within the cryptographic module.
Security Level 2 requires role-based authentication, in which a cryptographic module authenticates the role of an operator to determine if the operator has the right to perform corresponding services.
The software cryptographic module of Security Level 2 may run in a modifiable environment that shall implement role-based access controls or discretionary access control which is able to define new groups, assign permissions through access control lists (ACL) and assign each user to more than one group, and that protects against unauthorized execution, modification, and reading of software implementing cryptographic function.
5.4 Security Level 3
In addition to the tamper-evident physical security mechanisms required at Security Level 2, Security Level 3 provides additional requirements to mitigate the unauthorized access to sensitive security parameters within the cryptographic module. These physical security mechanisms required at Security Level 3 shall be able to have a high probability of detecting and responding to attempts at direct physical access, use or modification of the cryptographic module and probing through ventilation holes or slits. The physical security mechanisms may include the use of strong enclosures, and tamper of detection device and response circuit that shall zeroize all critical security parameters when the removable covers/doors of the cryptographic module are opened.
Security Level 3 requires identity-based authentication mechanisms, enhancing the security provided by the role-based authentication mechanisms specified for Security Level 2. A cryptographic module needs to authenticate the identity of an operator and verifies that the authenticated operator is authorized to assume a specific role and perform corresponding services.
Security Level 3 requires manually established plaintext critical security parameters to be encrypted, utilize a trusted channel or use split knowledge for entry or output.
The cryptographic module at Security Level 3 shall protect against a security compromise due to voltage and temperature outside of the cryptographic module's normal operating ranges. Intentional excursions beyond the normal operating ranges may be used by an attacker to bypass a cryptographic module's defense. A cryptographic module shall either include environmental protection features designed to detect abnormal environment and zeroize critical security parameters, or to pass environmental failure testing to provide a reasonable assurance that the cryptographic module security will not be damaged by abnormal environment.
The cryptographic module of Security Level 3 shall provide evidence and testing methods for the validity of non-invasive attack mitigation techniques.
Security Level 3 is not offered in all clauses of this standard for software cryptographic modules, therefore, the overall highest security level achievable by software cryptographic module is limited to Security Level 2.
The cryptographic module at Security Level 3 requires additional life-cycle assurances, such as automated configuration management, detailed design, low-level testing, and operator authentication using vendor-provided authentication information.
5.5 Security Level 4
Security Level 4 provides the highest level of security defined in this standard. This level includes all security features of the lower levels, as well as extended features.
At Security Level 4, the physical security mechanisms shall provide a complete envelope for protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access when sensitive security parameters are contained in the cryptographic module whether external power is supplied or not. Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate zeroization of all unprotected sensitive security parameters. By virtue of high security mechanism, Security Level 4 cryptographic modules are useful for operation in physically unprotected environment.
Security Level 4 introduces the multi-factor authentication requirement for operator authentication. At minimum, this requires two of the following three attributes:
——something known, such as a secret password;
——something possessed, such as a physical key or token;
——property possessed, such as a biometric.
The cryptographic module at Security Level 4 shall protect against a security f due to voltage and temperature outside of the cryptographic module's normal operating ranges. A cryptographic module shall include environmental protection features designed to detect abnormal environment and zeroize critical security parameters, to provide a reasonable assurance that the cryptographic module security will not be compromised by abnormal environment.
The mitigation methods for non-invasive attacks specified in 7.8 and implemented in cryptographic modules are detected according to the non-invasive attack mitigation detection indicators for Security Level 4 specified by the relevant national departments.
The design of a Security Level 4 module is verified by the correspondence between both pre- and post-conditions and the functional specification.
Foreword i
Introduction ii
1 Scope
2 Normative references
3 Terms and definitions
4 Abbreviations
5 Security level of cryptographic module
5.1 Overview
5.2 Security Level
5.3 Security Level
5.4 Security Level
5.5 Security Level
6 Functional security targets
7 Security requirements
7.1 General requirements
7.2 Cryptographic module specification
7.3 Cryptographic module interfaces
7.4 Roles, services, and authentication
7.5 Software/firmware security
7.6 Operational environment
7.7 Physical security
7.8 Non-invasive security
7.9 Sensitive security parameter management
7.10 Self-tests
7.11 Life-cycle assurance
7.12 Mitigation of other attacks
Annex A (Normative) Documentation requirements
Annex B (Normative) Cryptographic module security policy
Annex C (Normative) Approved security functions
Annex D (Normative) Approved sensitive security parameter generation and establishment methods
Annex E (Normative) Approved authentication mechanisms
Annex F (Normative) Non-invasive attacks and mitigation method detection indicators
Bibliography
