标准编号:	GB/T 37092-2018
中文名称:	信息安全技术 密码模块安全要求
英文名称:	Information security technology-Security requirements for cryptographic modules
中标分类:	L80    数据加密
行业分类:	GB    国家标准
ICS分类:	35.040 35.040    字符集和信息编码 35.040
发布机构:	国家市场监督管理总局 国家标准化管理委员会
发布日期:	2018-12-28
实施日期:	2019-7-1
标准状态:	现行
翻译语言:	英文
文件格式:	PDF
中文字符数:	45000 字
翻译价格(元):	3200.00 元
交付时间:	付款后 1 个工作日

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

信息安全技术密码模块安全要求

1 范围

本标准针对密码模块规定了安全要求，为密码模块定义了四个安全等级，并分别给出了四个安全等级的对应要求。
本标准适用于保护计算机与电信系统内敏感信息的安全系统所使用的密码模块。本标准也为密码模块的设计、开发提供指导，为密码模块安全要求的检测提供参考。

2 规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T 15843（所有部分） 信息技术 安全技术 实体鉴别
GB/T 15852（所有部分） 信息技术 安全技术 消息鉴别码
GB/T 17964 信息安全技术 分组密码算法的工作模式
GB/T 25069 信息安全技术 术语
GB/T 32905 信息安全技术 SM3密码杂凑算法
GB/T 32907 信息安全技术 SM4分组密码算法
GB/T 32918（所有部分） 信息安全技术 SM2椭圆曲线公钥密码算法
GB/T 33133.1 信息安全技术 祖冲之序列密码算法 第1部分：算法描述
GM/T 0001.2 祖冲之序列密码算法 第2部分：基于祖冲之算法的机密性算法
GM/T 0001.3 祖冲之序列密码算法 第3部分：基于祖冲之算法的完整性算法
GM/T 0044（所有部分） SM9标识密码算法

3 术语和定义

GB/T 25069界定的以及下列术语和定义适用于本文件。
3.1
证书 certificate
关于实体的一种数据，该数据由认证机构的私钥或秘密密钥签发，并无法伪造。
3.2
条件自测试 conditional self-test
当规定的测试条件出现时，由密码模块执行的测试。
3.3
关键安全参数 critical security parameter
与安全相关的秘密信息，这些信息被泄露或被修改后会危及密码模块的安全性。
注：关键安全参数可以是明文形式的也可以是经过加密的。
3.4
密码边界 cryptographic boundary
明确定义的边线，该边线建立了密码模块的物理和/或逻辑边界，并包括了密码模块的所有硬件、软件和/或固件部件。
3.5
密码模块 cryptographic module
实现了安全功能的硬件、软件和/或固件的集合,并且被包含在密码边界内。
注：密码模块根据其组成，可分为硬件密码模块、固件密码模块、软件密码模块以及混合密码模块。
3.6
密码模块接口 cryptographic module interface
密码模块的逻辑入口或出口，为逻辑信息流提供进出模块的通道。
3.7
密码模块安全策略 cryptographic module security policy
密码模块运行应遵从的安全规则的明确说明，其中包含了从本标准的要求导出的规则以及厂商要求的规则。
3.8
差分功耗分析 differential power analysis
对密码模块的功耗变化进行分析,并用以获取密码操作相关的信息。
3.9
故障注入 fault induction
通过应用短暂的电压、辐射、激光或时钟偏移技术，导致硬件中的操作行为发生变化的技术。
3.10
多因素鉴别 multi-word authentication
至少具有两个独立鉴别因素的鉴别。
注：独立的鉴别因素类别包括：已知某物，拥有某物，以及具有某属性。
3.11
非入侵式攻击 non-invasive attack
一种针对密码模块的攻击,该攻击对密码边界内的部件不进行直接的物理接触,且这类攻击不会更改密码模块所处的状态。
3.12
运行环境 operational environment
密码模块安全运行所需要的所有软件、固件和硬件的集合，其中包括操作系统和硬件平台。
注：运行环境分为可修改的运行环境、受限制的运行环境以及不可修改的运行环境。
3.13
运行前自测试 pre-operational self-test
密码模块在上电或实例化（在关闭电源、重置、重启、冷启动、供电中断等之后）至转换到运行状态之间执行的测试。
3.14
公开安全参数 public security parameter
与安全性相关的公开信息，一旦被修改，会威胁到密码模块安全。
注：例如，公钥、公钥证书、自签名证书、信任锚、与计数器和内部保持的日期和时间相关联的一次性口令。公开安全参数如果不能被修改或者修改后能够被密码模块发现，此时可以认为该公幵安全参数是受保护的。
3.15
运行时环境 runtime environment
一种虚拟机状态，在计算机运行时，为进程和程序提供软件服务。
注：运行时环境可能与操作系统本身，也可能与其下运行的软件有关，其主要目的在于实现“平台无关”的编程目标。
3.16
安全功能 security function
密码算法及其工作模式，包括：分组密码、序列密码、非对称密码、消息鉴别码、杂凑函数、随机数生成、实体鉴别和敏感安全参数生成和建立等。
3.17
敏感安全参数 sensitive security parameters
包括关键安全参数（3.3）和公开安全参数（3.14）。
3.18
简单功耗分析 simple power analysis
对指令执行（或单个指令的执行）模式的直接（主要是可视化的）分析，它与密码模块的功耗有关，并用以获取密码操作相关的信息。
3.19
知识拆分 split knowledge
密钥被拆分成多个密钥分量，从密码模块输出给多个实体的过程。单个分量不能提供原始密钥的知识。密钥分量被各个实体输入密码模块能够重新组合成原始密钥，合成密钥可以需要所有分量或一部分分量来完成。
3.20
敏感安全参数建立 sensitive security parameter establishment
将共享的敏感安全参数提供给一个或多个实体的过程。
注：敏感安全参数建立包括敏感安全参数协商、传输以及输入或输出。

4 缩略语

下列缩略语适用于本文件。
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 密码模块安全等级

5.1 概述
密码模块是指实现密码运算、密钥管理等功能的硬件、软件、固件或者其组合。本标准适用于保护计算机与电信系统内敏感信息的安全系统所使用的密码模块。为了保护密码模块和密码模块中包含和控制的敏感安全参数，以及满足众多应用领域的、不同程度的安全需求，本标准规定了4个要求递增的安全等级，高安全等级在低安全等级的基础上进一步提高了安全性。本标准中给出的一些常见的例子，是用于阐明如何满足本标准的安全要求，而不是为了约束或列举所有的情况。下文分别概述了4个安全等级。4个安全等级所涉及的密码技术是相同的。
本标准采用了“应[xx.yy]”方式对标准中的所有安全要求进行标识和顺序编号，其中，xx表示条款，yy是该条款中的数字索引。如果本标准中的某句话中出现“应[xx.yy]”，即表示该句是本标准的一项安全要求，编号为[xx.yy]。本标准总共有12个条款，与密码模块的安全通用要求以及11个安全域相对应，1〜12分别代表：通用要求；密码模块规格；密码模块接口；角色、服务和鉴别；软件/固件安全;运行环境；物理安全;非入侵式安全；敏感安全参数管理；自测试；生命周期保障；以及对其他攻击的缓解。每个条款中又包含具体的安全要求，每个安全要求从[xx.01]开始按顺序编号。
本标准下文中凡是包含“应[xx.yy]”的句子都被视为密码模块的一项安全要求，这种标识方式可以被本标准对应的后续检测标准直接引用，也可被密码模块厂商提交的文档引用。
5.2 安全一级
安全一级提供了最低等级的安全要求。安全一级阐明了密码模块的基本安全要求，例如，密码模块应使用至少一个核准的安全功能或核准的敏感安全参数建立方法。软件或固件密码模块可以运行在不可修改的、受限的或可修改的运行环境中。硬件密码模块除了需要达到产品级部件的基本要求之外，没有其他特殊的物理安全机制要求。密码模块实现的针对非入侵式攻击或其他攻击的缓解方法需要有文档记录。安全一级密码模块的例子有：个人计算机中的硬件加密板卡、运行在手持设备或通用计算机上的密码工具包。
当密码模块外部的应用系统已经配置了物理安全、网络安全以及管理过程等控制措施时，安全一级的密码模块就非常适用。这使得密码模块的使用者可以选择多种密码解决方案来满足安全需求。
5.3 安全二级
安全二级在安全一级的基础上增加了拆卸证据的要求，例如使用拆卸存迹的涂层或封条，或者在封盖或门上加防撬锁等手段以提供拆卸证据。
拆卸存迹的封条或防撬锁应安装在封盖或门上，以防止非授权的物理访问。当物理访问密码模块内的安全参数时，密码模块上拆卸存迹的涂层或封条就应破碎。
安全二级要求基于角色的鉴别。密码模块需要鉴别并验证操作员的角色，以确定其是否有权执行对应的服务。
安全二级的软件密码模块可以运行在可修改的环境中，该环境应实现基于角色的访问控制或自主访问控制，但自主访问控制应能定义新的组，通过访问控制列表（ACL）分配权限，以及将一个用户分配给多个组。访问控制措施应防止非授权地执行、修改以及读取实现密码功能的软件。
5.4 安全三级
除了安全二级中要求的拆卸存迹物理安全机制外，安全三级还要求更强的物理安全机制，以进一步防止对密码模块内敏感安全参数的非授权访问。这些物理安全机制应能够以很高的概率检测到以下行为并作出响应，这些行为包括：直接物理访问、密码模块的使用或修改，以及通过通风孔或缝隙对密码模块的探测。上述物理安全机制可以包括坚固的外壳、拆卸检测装置以及响应电路。当密码模块的封盖/门被打开时，响应电路应将所有的关键安全参数置零。
安全三级要求基于身份的鉴别机制，以提高安全二级中基于角色的鉴别机制的安全性。密码模块需要鉴别操作员的身份，并验证经鉴别的操作员是否被授权担任特定的角色以及是否能够执行相应的服务。
安全三级要求手动建立的明文关键安全参数是经过加密的、使用可信信道或使用知识拆分来输入或输出。
安全三级的密码模块应有效防止电压、温度超出密码模块正常运行范围对密码模块安全性的破坏。攻击者可以故意让密码模块的环境参数偏离正常运行范围，从而绕过密码模块的防护措施。密码模块应设计有环境保护特性，用以检测环境异常并置零关键安全参数，或者能够通过环境失效测试从而提供一个合理的保障，确保不会因环境异常破坏密码模块的安全性。
安全三级的密码模块应提供非入侵式攻击缓解技术的有效性证据和检测方法。
对于软件密码模块,并没有在本标准的所有条款中给出安全三级的要求。因此，软件密码模块能够达到的最大整体安全等级限定为安全二级。
安全三级的密码模块增加了生命周期保障的要求，比如自动配置管理、详细设计、底层测试以及基于厂商所提供的鉴别信息的操作员鉴别。
5.5 安全四级
安全四级是本标准中的最高安全等级。该等级包括较低等级中所有的安全特性，以及一些扩展特性。
安全四级的物理安全机制应在密码模块周围提供完整的封套保护，其目的是无论外部电源是否供电，当密码模块包含敏感安全参数时，检测并响应所有非授权的物理访问。从任何方向穿透密码模块的外壳都会以很高的概率被检测到，并将导致所有未受保护的敏感安全参数立刻被置零。由于安全四级的密码模块自身具有较高的安全机制，所以它特别适用于无物理保护的环境。
安全四级要求对操作员进行多因素鉴别。最低限度下，要求使用下列因素中的两个：
——已知某物，如秘密口令；
——拥有某物，如物理钥匙或令牌；
——具有某属性，如生物特征。
安全四级的密码模块应有效防止电压、温度超出密码模块正常运行范围对密码模块安全性的破坏。密码模块应设计有环境保护特性，专门用以检测环境异常并置零关键安全参数，从而提供一个合理的保障，确保不会因环境异常破坏密码模块的安全性。
按照国家相关部门规定的、安全四级的非入侵式攻击缓解检测指标，检测密码模块中实现的、7.8中规定的针对非入侵式攻击的缓解方法。
安全四级要求密码模块的设计应通过一致性验证，即验证前置和后置条件与功能规格之间的一致性。

6 功能安全目标

本标准中规定的安全要求涉及密码模块的安全设计和实现。安全要求从安全目标的最低等级开始，随着安全目标等级的递增而增加。这些要求源于密码模块的下列功能性安全目标：
——使用并正确实现核准的安全功能，以保护敏感信息；
——防止非授权地操作或使用密码模块；
——防止非授权地泄露密码模块的内容，其中包括关键安全参数；
——防止对密码模块和密码算法进行非授权或检测不到的修改，包括非授权地修改、替换、插入和删除敏感安全参数；
——提供密码模块运行状态的指示；
——保证密码模块在核准的工作模式下能够正确运行；
——检测出密码模块运行中的错误，防止这些错误非授权地公开、修改、替换或使用关键安全参数，或者非授权地修改或替换公开安全参数；
——保证正确地设计、分配和实现密码模块。

7 安全要求

7.1 通用要求
符合本标准的密码模块应[01.01]满足的安全要求。这些安全要求涵盖了密码模块的设计、实现、操作以及废弃相关的域，具体包括：密码模块规格；密码模块接口；角色、服务和鉴别；软件/固件安全;运行环境；物理安全;非入侵式安全；敏感安全参数管理；自测试;生命周期保障；以及对其他攻击的缓解。
表1总结了每个域的安全要求。
密码模块应[01.02]针对各个域的要求进行检测。密码模块应[01.03]在每个域中独立地进行评级。上述11个安全域中，有些域随着安全等级的递增，安全要求也相应增加。密码模块在这些域中获得的评级反映了密码模块在该域中所能达到的最高安全等级，即密码模块应满足该域针对该等级的所有安全要求。另外一些域的安全要求不分安全等级,那么密码模块在这些域中将获得与整体评级相当的评级。
除了在每个安全域中获得独立的评级之外，密码模块还将获得一个整体评级。整体评级设定为11个域所获得的最低评级。
本标准要求密码模块提供相关的文档，具体要求见附录A和附录B。待确认或评估的密码模块应[01.04]提供所有相关文档，包括用户和安装手册、设计说明、生命周期文档等。
附录C、附录D、附录E和附录F提供了核准的安全功能、核准的敏感安全参数生成和建立方法、核准的鉴别机制以及非入侵式攻击及常用的缓解方法等相关内容。
表1 安全要求总表
安全域 安全一级 安全二级 安全三级 安全四级
1密码模块规格 密码模块、密码边界、核准的密码功能以及正常的工作模式的说明；
密码模块的描述，包括所有硬件、软件和固件部件；
所有服务提供状态信息以指示服务何时按照核准的方式使用核准的密码算法、安全功能或过程
2密码模块接口 要求的和可选的接口；
所有接口和所有输入输出数据路径的说明 可信信道
3角色、服务和鉴别 要求的角色、服务与可选的角色、服务逻辑上相隔离 基于角色或基于身份的操作员鉴别 基于身份的鉴别 多因素鉴别
4软件/固件安全 核准的完整性技术，以及定义的软件或固件密码模块接口、混合固件密码模块接口 基于核准的数字签名或带密钥信息消息鉴别码的完整性测试 基于核准的数字签名的完整性测试
以及混合软件固件密码模块接口；可执行代码
5运行环境 不可修改的、受限的；对敏感安全参数的控制
可修改的；
对敏感安全参数的控制 可修改的；
基于角色或自主访问控制；审计机制
6物理安全 产品级部件 拆卸证据；
不透明的遮盖物或外壳 封盖和门上的拆卸检测与响应电路；牢固的外壳或涂层；防止直接探测的保护；
EFP或EFT 拆卸检测和响应封壳；
EFP；
故障注入的缓解
7非入侵安全 能够缓解附录F中规定的非入侵式攻击
文档阐明附录F中规定的缓解技术和有效性 提供缓解检测方法 缓解检测
8敏感安全参数管理 随机数生成器、敏感安全参数生成、建立、输入和输出、存储以及置零
自动的敏感安全参数传输或敏感安全参数协商使用核准方法
手动建立的敏感安全参数可以以明文的形式输入或输出 手动建立的敏感安全参数，可以以加密的形式、通过可信信道或使用知识拆分过程输入或输出
9自测试 运行前：软件/固件完整性测试、旁路测试以及关键功能测试
条件：密码算法、配对一致性、软件/固件加载、手动输入、条件旁路以及关键功能测试
表1（续）
10
生
命
周
期
保
障 1）配置管理 密码模块、部件和文档的配置管理系统。每一项在整个生命周期中都有唯一标识并可追踪 自动配置管理系统
2）设计 密码模块设计成允许对所有提供的安全相关服务进行测试
3）FSM 有限状态模型
4）开发 有注释的源代码、版图或HDL 软件高级语言；硬件高级描述语言 文档注明密码模块部件执行的前置条件，以及当部件执行完毕时预期为真的后置条件
5）测试 功能测试 底层测试
6）配送与操作 初始化流程 配送流程 使用厂商提供的鉴别信息的操作员鉴别
7）生命终止 安全清理密码模块的流程 安全销毁密码模块的流程
8）指南文档 管理员和非管理员指南
11其他攻击的缓解 缓解其他攻击的说明，目前对这些攻击还没有可检测要求 验证缓解技术的有效性

7.2 密码模块规格
7.2.1 密码模块规格通用要求
密码模块应[02.01]是硬件、软件、固件，或它们之间组合的集合，该集合至少使用一个核准的密码算法、安全功能或过程实现一项密码服务，并且包含在定义的密码边界内。
密码模块文档应[02.02]按照A.2.2中规定的要求编写。
7.2.2 密码模块类型
密码模块应[02.03]定义为下列一种密码模块类型：
——硬件密码模块：密码边界规定为硬件边线。固件和/或软件，其中还可以包括操作系统，可以被包含在硬件密码边界内。
——软件密码模块：密码边界为执行在可修改的运行环境中的纯软件部件（可以是一个或多个软件部件）划定界线。软件密码模块的运行环境所包含的计算平台和操作系统，在定义的密码边界之外。
——固件密码模块：密码边界为执行在受限的或不可修改的运行环境中的纯固件部件划定界线。固件密码模块的运行环境所包含的计算平台和操作系统，在定义的密码边界之外，但是与固件密码模块明确绑定。
——混合软件密码模块：密码边界为软件部件和分离的硬件部件（即软件部件不在硬件密码模块边界中）的集合划定界线。软件运行的环境所包含的计算平台和操作系统，在定义的混合软件密码模块边界之外。
——混合固件密码模块：密码边界为固件部件和分离的硬件部件（即固件部件不在硬件密码模块边界中）的合成划定界线。固件运行的环境所包含的计算平台和操作系统,在定义的混合固件密码模块边界之外，但是与混合固件密码模块明确绑定。
对于硬件和固件密码模块，应[02.04]满足7.7中规定的物理安全和7.8中规定的非入侵式安全的所有适用要求。
对于运行于可修改环境中的软件密码模块，应[02.05]满足7.8中规定的非入侵式安全中的所有适用要求；7.7中规定的物理安全要求是可选的。
对于混合密码模块，应[02.06]满足7.5中规定的软件/固件安全、7.6中规定的运行环境、7.7中规定的物理安全和7.8中规定的非入侵式安全中的所有适用要求。
7.2.3 密码边界
7.2.3.1 密码边界通用要求
密码边界应[02.07]由定义明确的边线（例如，硬件、软件或固件部件的集合）组成，该边线建立了密码模块所有部件的边界。本标准的要求应[02.08]适用于密码边界内的所有算法、安全功能、过程和部件。密码边界应[02.09]至少包含密码模块内所有安全相关的算法、安全功能、过程和部件（即本标准范围内与安全相关的）。非安全相关的算法、安全功能、过程和部件也可以包含在密码边界内。用于核准工作模式的非安全相关的算法、安全功能、过程和部件的实现应[02.10]不干扰或破坏密码模块核准的运行。
密码模块的名称应[02.11]代表密码边界内的部件构成，不应代表大于实际范围的构成或产品。密码模块应[02.12]至少具有代表每个互不相同的硬件、软件和/或固件部件的特定版本信息。
密码边界内的某些硬件、软件和/或固件部件可以从本标准的要求中排除。被排除的硬件、软件或固件部件的实现应[02.13]不干扰或破坏密码模块核准的安全运行。应[02.14]阐明被排除的硬件、软
件或固件（见附录A）。
7.2.3.2 密码边界的定义
不同类型的密码模块，其密码边界有所差异，具体内容如下：
a）硬件密码模块的密码边界应[02.15]划界并确定：
硬件部件集合，可包括：
——在部件之间提供互联的物理配线的物理结构，包括电路板、基板或其他表面贴装；
——有效电器元件，如半集成、定制集成或通用集成的电路、处理器、内存、电源、转换器等；
——外壳、灌封或封装材料、连接器和接口之类的物理结构；
——固件，可以包含操作系统；
——上面未列出的其他部件类型。
b）软件密码模块的密码边界应[02.16]划界并确定：
——构成密码模块的可执行文件或文件集；
——保存在内存中并由一个或多个处理器执行的密码模块的实例。
c）固件密码模块的密码边界应[02.17]划界并确定：
——构成密码模块的可执行文件或文件集；
——保存在内存中并由一个或多个处理器执行的密码模块的实例。
d）混合密码模块的密码边界应[02.18]：
——由密码模块硬件部件的边界以及分离的软件或固件部件的边界构成；
——包含每个部件所有端口和接口的集合。
混合密码模块除了分离的软件或固件部件，密码模块的硬件部件还可以包含嵌入式的软件或固件。
7.2.4 工作模式
7.2.4.1 工作模式通用要求
密码模块可以有核准的工作模式和非核准的工作模式。核准的工作模式是指密码模块在该工作模式下只能使用核准的安全功能提供安全相关服务。
操作员应[02.19]能够在核准的工作模式下操作密码模块。核准的工作模式应[02.20]定义为一组服务的集合，其中至少有一个服务使用了核准的密码算法、安全功能或过程。
非核准的密码算法、安全功能和过程或其他未规定于7.4.3中的服务不应[02.21]被操作员用于核准的工作模式中，除非非核准的密码算法或安全功能是核准的过程的一部分，而且与核准的过程的安全无关。例如，使用非核准的密码算法或非核准的方式生成的密钥，混淆数据或关键安全参数，结果也被视为未受保护的明文，且不能提供安全相关功能。
7.2.4.2 正常工作
正常工作是指算法、安全功能、服务或过程的完整集合都是可用的和/或可配置的。
核准的和非核准的服务和工作模式的关键安全参数应[02.22]相互分离，例如，不共享或不相互访问。核准的随机数生成器的输出可以提供给非核准的算法、安全功能或过程，只要随机数生成器种子无法在非核准的模式中访问就无需置零种子。
密码模块的安全策略应[02.23]为密码模块所包括的每个工作模式（核准的和非核准的）定义完整的服务集合。
当服务正在以核准的方式使用核准的密码算法、安全功能或过程，以及其他规定于7.4.3中的服务或过程的时候，该服务应[02.24]给出相应的状态指示。
7.2.4.3 降级工作
降级工作是指当密码模块进入错误状态后，某些算法、安全功能、服务或过程的操作集合仍然是可用的和/或可配置的。本标准要求当密码模块出现任何错误，都应[02.25]进入错误状态并停止工作，不能降级工作。
7.3 密码模块接口
7.3.1 密码模块接口通用要求
所有进出密码模块的逻辑信息流，都应[03.01]只能通过已定义的物理端口和逻辑接口，这些端口和接口是出入密码边界的入口和出口。密码模块逻辑接口应[03.02]是相互分离的，这些逻辑接口可以共享一个物理端口，例如，输入数据和输出数据可以使用同一个端口，或者逻辑接口也可以分布在一个或多个物理端口上，例如，输入数据可以通过串口也可以通过并口。密码模块软件部件的应用程序接口（API）可以定义为一个或多个逻辑接口。
密码模块文档应[03.03]按照A.2.3的要求编写。
7.3.2 接口类型
密码模块的接口类型包括：
——硬件密码模块接口定义为用于请求硬件密码模块服务的命令全集，请求服务的命令中包括输入到密码模块或者由密码模块输出的参数。
——软件或固件密码模块接口定义为用于请求软件或固件密码模块服务的命令全集，请求服务的命令中包括输入到密码模块或者由密码模块输出的参数。
——混合固件或混合软件密码模块接口定义为用于请求混合固件或混合软件密码模块服务的命令全集，请求服务的命令中包括输入到密码模块或者由密码模块输出的参数。
7.3.3 接口定义
密码模块应[03.04]具备下列五种接口（“输入”和“输出”是相对于密码模块而言的）：
——数据输入接口：由密码模块处理的所有输入数据（通过“控制输入”接口输入的控制数据除外），包括明文、密文、敏感安全参数和另一个密码模块的状态信息，应[03.05]通过“数据输入”接口输入。当密码模块执行7.10中自测试时，密码模块可以通过数据输入接口接收数据。
——数据输出接口：除“状态输出”接口输出的状态数据以及通过“控制输出”接口输出的控制数据之外，所有从密码模块输出的输出数据，包括明文、密文和敏感安全参数等，应[03.06]通过“数据输出”接口输出。在执行手动输入、运行前自测试、软件/固件加载和置零的过程中，或者当密码模块处在错误状态时，应[03,07]禁止通过“数据输出”接口输出数据。
——控制输入接口：所有用于控制密码模块运行的输入命令、信号（例如，时钟输入）及控制数据（包括手动控制如开关、按钮和键盘，以及功能调用）应[03.08]通过“控制输入”接口输入。
——控制输出接口：所有用于控制密码模块运行的输出命令、信号及控制数据（例如，对另一个密码模块的控制命令）应[03.09]通过“控制输出”接口输出。当密码模块处于错误状态时，应[03.10]禁止通过“控制输出”接口的控制输出，除非在安全策略中规定了一些例外情况。
——状态输出接口：所有用于指示密码模块状态的输出信号、指示器（例如，错误指示器）和状态数据[包括返回码和物理指示器，比如视觉的（显示器，指示灯），声音的（蜂鸣器提示音，响铃），以及机械的（振动器）]，应[03.11]通过“状态输出”接口输出。状态输出可以是显式的或隐式的。
除软件密码模块以外，所有密码模块还应[03.12]具备下列接口：
——电源接口：输入密码模块的所有外部电能应[03.13]通过电源端口输入。电源端口不是必需的，当所有能量由密码模块的密码边界内部提供或维持时（例如，通过内部电池），电源接口可以不存在。
密码模块应[03.14]区分数据、控制信息和电源的输入，以及数据、控制信息、状态信息和电源的输出。密码模块规格应[03.15]明确规定输入数据以及控制信息的格式,包括对所有可变长度输入的长度限制。
7.3.4 可信信道
可信信道是在密码模块和发送者或接收者之间建立的链路，用于安全传输未受保护的明文密钥分量、鉴别数据以及其他关键安全参数。明文密钥指的是未经加密的密钥，或由非核准的方法混淆的密钥。可信信道在密码模块定义的输入或输出端口以及预期的发送者或接收者终端的通信链路上，可以防止窃听以及来自恶意的操作员/实体、进程或其他设备的物理或逻辑篡改。
密码模块的可信信道要求包括：
a）安全一级和安全二级：
对于安全一级和安全二级，没有可信信道要求。
b）安全三级：
对于安全三级：
——密码模块应[03.16]实现可信信道，用于在密码模块与发送者或接收者终端之间传输未受保护的明文密钥分量、鉴别数据以及其他关键安全参数；
——可信信道应[03.17]防止在通信链路上的非授权修改、替换和泄露；
——可信信道使用的物理端口应[03.18]与其他物理端口实现物理隔离；或可信信道使用的逻辑接口应[03.19]与其他逻辑接口实现逻辑隔离；
——基于身份的鉴别应[03.20]用于所有使用可信信道的服务；
——当可信信道在使用时，应[03.21]提供状态指示器。
c）安全四级：
对于安全四级，除了安全三级的要求以外，基于身份的多因素鉴别应[03.22]用于所有使用可信信道的服务。
7.4 角色、服务和鉴别
7.4.1 角色、服务和鉴别通用要求
密码模块应[04.01]支持操作员的授权角色以及与每个角色相对应的服务。一个操作员可以担任多种角色。如果密码模块支持多个操作员同时操作.那么密码模块内部应[04.02]确保各个操作员担任的角色相隔离及相应的服务相隔离。当服务执行不会修改、泄露或替换关键安全参数和公开安全参数时，例如显示状态、自测试或者其他不影响密码模块安全的服务，操作员无需担任一个授权角色。
密码模块可能需要鉴别机制，以鉴别操作员对密码模块的访问，以及验证操作员是否被授权担任请求的角色和执行该角色下的服务。
密码模块文档应[04.03]按照A.2.4中规定的要求编写。