GM/T 0028-2014 PDF in English
GM/T 0028-2014 (GM/T0028-2014, GMT 0028-2014, GMT0028-2014)
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| GM/T 0028-2014 | English | 365 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Security requirements for cryptographic modules
| Valid |
Standards related to (historical): GM/T 0028-2014
PDF Preview
GM/T 0028-2014: PDF in English (GMT 0028-2014) GM/T 0028-2014
GM
CRYPTOGRAPHY INDUSTRY STANDARD
OF THE PEOPLE’S REPUBLIC OF CHINA
ICS 35.040
L 80
File No.. 44629-2014
Security requirements for cryptographic modules
ISSUED ON. FEBRUARY 13, 2014
IMPLEMENTED ON. FEBRUARY 13, 2014
Issued by. State Cryptography Administration
Table of Contents
Foreword . 4
Introduction .. 5
1 Scope .. 6
2 Normative references .. 6
3 Terms and definitions .. 6
4 Abbreviations . 21
5 Security levels of cryptographic module .. 22
5.1 Overview .. 22
5.2 Security level 1 .. 23
5.3 Security level 2 .. 23
5.4 Security level 3 .. 24
5.5 Security level 4 .. 25
6 Functional security targets .. 26
7 Security requirements . 26
7.1 General requirements .. 26
7.2 Specifications of cryptographic modules .. 29
7.3 Interfaces of cryptographic modules . 34
7.4 Roles, services, and authentication .. 36
7.5 Software/firmware security . 43
7.6 Operational environment . 45
7.7 Physical security .. 51
7.8 Non-invasive security . 62
7.9 Management of sensitive security parameters .. 63
7.10 Self-tests . 67
7.11 Life cycle guarantee . 72
7.12 Mitigation of other attacks .. 79
Appendix A (Normative) Document requirements .. 81
A.1 Purpose . 81
A.2 Clauses .. 81
Appendix B (Normative) Cryptographic module’s security policy .. 90
B.1 Purpose . 90
B.2 Clauses .. 90
Appendix C (Normative) Approved security functions .. 96
C.1 Purpose . 96
C.2 Clauses .. 96
Appendix D (Normative) Approved generation and establishment methods of
sensitive security parameters . 98
D.1 Purpose . 98
D.2 Clauses .. 98
Appendix E (Normative) Approved authentication mechanisms . 99
E.1 Purpose . 99
E.2 Authentication mechanisms .. 99
References . 100
Foreword
This Standard was drafted in accordance with the rules given in GB/T 1.1-2009.
This Standard uses Redraft Law to modify ISO 19790.2012 Information
technology - Security techniques - Security requirements for cryptographic
modules.
The technical differences between this Standard and ISO 19790. 2012 and the
reasons are as follows.
- With regard to Appendix C - E, this Standard makes adjustments with
technical differences, to suit our country’s technical conditions; specifically
adjusts the documents listed in Appendix C - E; replaces the list of
standards listed in ISO 19790.2012 with the list of standards approved by
the State Cryptography Administration.
Attention is drawn to the possibility that some of the elements of this Standard
may be the subject of patent rights. The issuing authority of this document shall
not be held responsible for identifying any or all such patent rights.
This Standard was proposed by and shall be under the jurisdiction of
Standardization Technical Committee of Cryptography Industry.
Main drafting organizations of this Standard. DCS Center, Beijing Watchdata
Technologies Co., Ltd., Beijing Certificate Authority, Zanjia Electronic
Technology (Beijing) Co., Ltd., Feitian Technologies Co., Ltd., Beijing Haitai
Fangyuan Technologies Co., Ltd., Beijing HuaDa ZhiBao Electronic System Co.,
Ltd., Commercial Cryptography Testing Center of State Cryptography
Administration, Shanghai KOAL Software Co., Ltd., Beijing Creative Century
Technologies Co., Ltd.
Main drafters of this Standard. Gao Neng, Jing Jiwu, Wang Juan, Tu Chenyang,
Wang Xuelin, Chen Guo, Zhan Banghua, Zhang Jiachun, Zhu Pengfei, Jiang
Hongning, Chen Yue, Luo Peng, Tan Wuzheng, Zhang Wantao, Liu Limin,
Wang Yuewu, Xiang Ji, Wang Qiongxiao, Lin Zhangqiang, Xia Luning.
Security requirements for cryptographic modules
1 Scope
This Standard, for the cryptographic modules which are used to protect the
security system of sensitive information in computer and telecommunications
systems, specifies security requirements. The Standard defines 4 security
levels for cryptographic modules, to meet the security requirements of different
degrees of sensitive information and many application fields. For the 11 security
domains of cryptographic modules, this Standard gives the corresponding
requirements of the four security levels. The high security level, on the basis of
the low security level, further improves security.
2 Normative references
The following documents are essential to the application of this document. For
the dated references, only the versions with the dates indicated are applicable
to this document. For the undated references, the latest version (including all
the amendments) are applicable to this document.
The documents listed in Appendix C, D, and E of this Standard.
3 Terms and definitions
The following terms and definitions are applicable to this document.
3.1 Access control list
A list of permissions which allows access to an object.
3.2 Administrator guidance
Written data used by cryptographic officer and/or other management roles to
correctly configure, maintain, and manage cryptographic modules.
3.3 Approval authority
An authority which is authorized to approve and/or evaluate security functions.
The function of approval authority is to evaluate and approve security functions,
not to test the compliance of cryptographic modules with this Standard.
3.4 Approved data authentication technique
Approved data authentication technique based on digital signature, message
authentication code, or hash with cryptographic keys (such as HMAC), and
other methods.
3.5 Approved integrity technique
Approved integrity technique based on hash, massage authentication code, or
digital signature algorithm.
3.6 Approved mode of operation
A mode of operation of cryptographic modules. Under this mode, only approved
security functions can be used. It shall not be confused with the mode of
operation of cryptographic algorithm, such as AES CCM mode.
3.7 Approved security function
Security functions given in Appendix C, such as cryptographic algorithm.
3.8 Asymmetric cryptographic technique
USE two correlation-transform cryptographic techniques. a public
transformation defined by public key and a private transformation defined by
private key. The two transformations have the following nature. Within the given
finite time, and under the given computational resources, it is not
computationally feasible to deduce the private transformation from the given
public transformation.
3.9 Bypass capability
The capability of a service to partly or totally bypass cryptographic functions.
3.10 Certificate
Entity data which cannot be forged, and which are produced based on the
private key or secret key of authentication authority.
3.11 Compromise
Unauthorizedly DISCLOSE, modify, replace, or use critical sensitive data; or
unauthorizedly MODIFY or replace public security parameters.
3.12 Conditional self-test
When the specified test condition occurs, a test performed by cryptographic
modules.
3.13 Confidentiality
key of the signer, to confirm the integrity of the data to be signed, the
authenticity of the signer's identity, and the nonrepudiation of the signature
behavior.
3.29 Electromagnetic emanations
The signal which contains useful information. Once it is intercepted and
analyzed, the information transmitted, received, processed, or operated by an
information processing device may be divulged.
3.30 Electronic key entry
The operation where SSP or cryptographic key component, by electronic
means, is input into cryptographic modules.
3.31 Encrypted key
The key which is encrypted by approved security function; it is considered
protected.
3.32 Entity
Person, block, device, or process.
3.33 Entropy
A measure of disorder, randomness, or variability of closed systems. The
entropy of random variable X is the mathematical measure of the amount of
information obtained by observing X.
3.34 Environmental failure protection
The characteristics implemented on a cryptographic module to prevent the
damage to the security of cryptographic module caused by environmental
conditions beyond the normal operational range of the module.
3.35 Environmental failure testing
USE a specific test method to ensure the security of cryptographic module; so
that it will not be damaged by the environment conditions beyond the normal
operational range of the module.
3.36 Error detection code
The value formed by redundant bits which are calculated from the data to be
tested, which is used to detect whether the data are unintentionally altered; but
not to correct.
PSP. Public Security Parameters
RBG. Random Bit Generator
SFMI. Software (Firmware) Module Interface
SSP. Sensitive Security Parameter
5 Security levels of cryptographic module
5.1 Overview
Cryptographic modules are a series of hardware, software, and/or firmware,
which are included in cryptographic boundary and perform approved or
accepted security functions (including cryptographic algorithms and key
generation). To protect the cryptographic module itself and the SSP contained
and controlled in cryptographic module, this Standard specifies 4 security levels
with incremental security requirements. Some common examples given in this
Standard are used to illustrate how to meet the security requirements of this
Standard, not to constrain or enumerate all situations. For the purpose of this
Standard, the term “module” shall be understood as “cryptographic module”.
The following subclauses provide an overview of the 4 security levels. The 4
security levels involve the same cryptographic technique.
This Standard uses “shall [xx.yy]” to identify and sequence all security
requirements in the Standard; where xx represents the clause, and yy is the
numeric index in the clause. If “shall [xx.yy]” appears in a sentence in this
Standard, it means that the sentence is a security requirement of this Standard
and is nu...
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|