GM/T 0039-2015 (GM/T0039-2015, GMT 0039-2015, GMT0039-2015)
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GM/T 0039-2015 | English | 365 |
Add to Cart
|
0--9 seconds. Auto-delivery
|
Security test requirements for cryptographic modules
| Valid |
GM/T 0039-2015
|
Preview PDF: GM/T 0039-2015
| Standard ID | GM/T 0039-2015 (GM/T0039-2015) | | Description (Translated English) | Security test requirements for cryptographic modules | | Sector / Industry | Chinese Industry Standard (Recommended) | | Classification of Chinese Standard | L80 | | Word Count Estimation | 107,117 |
GM/T 0039-2015
GM
CRYPTOGRAPHY INDUSTRY STANDARD
OF THE PEOPLE’S REPUBLIC OF CHINA
ICS 35.040
L 80
File No.. 49738-2015
Security test requirements for cryptographic modules
ISSUED ON. APRIL 1, 2015
IMPLEMENTED ON. APRIL 1, 2015
Issued by. State Cryptography Administration
Table of Contents
Foreword . 3
1 Scope .. 4
2 Normative references .. 4
3 Terms and definitions .. 4
4 Abbreviations .. 4
5 Document organization . 5
5.1 General .. 5
5.2 Clauses and security requirements .. 5
5.3 Description of reference clauses . 6
6 Security test requirements .. 6
6.1 General requirements . 6
6.2 Cryptographic module specification .. 7
6.3 Cryptographic module interfaces .. 23
6.4 Roles, services, and authentication . 40
6.5 Software / Firmware security .. 65
6.6 Operational environment .. 72
6.7 Physical security . 88
6.8 Non-invasive security . 119
6.9 Sensitive security parameter management . 121
6.10 Self-tests .. 137
6.11 Life-cycle assurance .. 162
6.12 Mitigation of other attacks .. 180
6.13 A - Documentation requirements . 181
6.14 B - Cryptographic module security policy .. 182
6.15 C - Approved security functions .. 183
6.16 D - Approved sensitive security parameter generation and establishment
methods .. 183
6.17 E - Approved authentication mechanisms . 183
6.18 F - Non-invasive attacks and common mitigation test metrics .. 183
Annex A (Informative) Security level correspondence tables . 184
Foreword
This Standard was drafted in accordance with the rules given in GB/T 1.1-2009.
This Standard was prepared by redrafting with reference to ISO / IEC
24759.2014 Information technology - Security techniques - Test requirements
for cryptographic modules. The degree of consistency with ISO / IEC
24759.2014 is not equivalent.
Attention is drawn to the possibility that some of the elements of this document
may be the subject of patent rights. The issuing authority 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 Technical
Committee for Standardization of Cryptography Industry.
Main drafting organizations of this Standard. Bejing Watchdata Intelligent
Technology Co., Ltd, Feitian Technologies Co., Ltd, Beijing HuaDa ZhiBao
Electronic System Co., Ltd, Beijing Haitai Fangyuan Technologies Co., Ltd,
Commercial Cryptography Testing Center of State Cryptography Administration,
Data Assurance & Communications Security (DCS) Center, Beijing Creative
Century Technology Co., Ltd, Shanghai Koal Software Co., Ltd.
Main drafters of this Standard. Wang Xuelin, Li Dawei, Deng Kaiyong, Chen
Guo, Chen Baoru, Zhang Yifei, Hu Boliang, Zhu Pengfei, Luo Peng, Zhang
Zhong, Lei Yinhua, Mo Fan, Lin Chun, Jiang Hongyu, Tan Wuzheng, Zhang
Wantao, Gao Neng.
Security test requirements for cryptographic modules
1 Scope
This Standard specifies a series of test procedures, test methods and
corresponding document submission requirements for cryptographic modules,
in accordance with the requirements of GM/T 0028-2014.
This Standard is applicable to the tests of cryptographic modules.
2 Normative references
The following documents are essential to the application of this document. For
dated references, only the editions with the dates indicated are applicable to
this document. For undated references, only the latest editions (including all the
amendments) are applicable to this document.
GM/T 0028-2014 Security requirements for cryptographic modules
GM/Z 4001 Cryptology terminology
3 Terms and definitions
The terms and definitions defined in GM/T 0028-2014 and GM/Z 4001 are
applicable to this document.
4 Abbreviations
The following abbreviations are applicable to this document.
API Application Program Interface
CBC Cipher Block Chaining
CSP Critical Security Parameter
EDC Error Detection Code
EFP Environmental Failure Protection
EFT Environmental Failure Testing
Following each clause is the requirements for the required vendor
documentation. These requirements describe the types of documentation or
explicit information that the vendor shall provide in order for the tester to verify
conformity (of the documentation or information) to the given clause.
These requirements are denoted by the form.
CY< requirement number>.< clause sequence number>.< sequence number>
where “CY” represents the requirements for the documents that are submitted
by the vendor, “requirement number” and “clause sequence number” are
identical to those in the corresponding security requirement, and “sequence
number” is a sequential identifier for vendor requirements within the clause.
Following the required vendor documentation is the requirements for the
required test procedures. These requirements instruct the tester as to what he
or she shall do in order to test the cryptographic module with respect to the
given clause.
These requirements are denoted by the form.
JY< requirement number>.< clause sequence number>.< sequence number>
where “JY” represents the requirements for the test procedures and methods,
“requirement number” and “clause sequence number” are identical to those in
the corresponding security requirement, and “sequence number” is a sequential
identifier for tester requirements within the clause.
5.3 Description of reference clauses
For coherence in the statements, this Standard adds supplementary statements
to some of the clauses that are direct quotations from GM/T 0028-2014. These
statements have been put between curly brackets “{” and “}” and are italicized
in bold font of Song typeface.
In addition, the “shall” used in the requirements for the vendor documentation
and the requirements for the test procedures required by this Standard have
the same meaning as the “should” in the clauses that are directly quoted from
GM/T 0028-2014.
6 Security test requirements
6.1 General requirements
NOTE. This subclause states general requirements to meet the articles of the other subclauses in Clause
6.
description of the approved mode of operation.
JY02.19.02. The tester shall verify that it is able to activate the approved mode
of operation according to the method described in the vendor documentation.
JY02.19.03. The tester shall verify that the operator is able to operate the
cryptographic module in an approved mode of operation.
AY02.20. (Security levels 1, 2, 3 and 4)
An approved mode of operation shall be defined as the set of services
which include at least one service that utilizes an approved cryptographic
algorithm, security function or process.
Required vendor documentation
CY02.20.01. The vendor documentation shall describe the approved
cryptographic algorithm, security function or process that is used in the
approved mode of operation for the cryptographic module and those services
specified in 7.4.3 of GM/T 0028-2014.
CY02.20.02. The vendor documentation shall provide a verification certificate
that includes all approved cryptographic algorithms, security functions or
processes.
Required test procedures
JY02.20.01. The tester shall verify the approved mode of operation described
in the documentation, and that at least one service uses the approved
cryptographic algorithm, security function or process and those services or
processes specified in 7.4.3 of GM/T 0028-2014.
JY02.20.02. The tester shall verify the vendor provided verification certificate
for approved cryptographic algorithms, security functions or processes.
JY02.20.03. The tester shall verify that the approved modes of operation and
security functions for use described in the documentation meet the
requirements of Annex C in GM/T 0028-2014.
AY02.21. (Security levels 1, 2, 3 and 4)
Non-approved cryptographic algorithms, security functions, and
processes or other services not specified in {GM/T 0028-2014} 7.4.3 shall
not be utilized by the operator in an approved mode of operation unless
the non-approved cryptographic algorithm or security function is part of
an approved process and is non-security relevant to the approved
processes operation (e.g. a non-approved cryptographic algorithm or
commands using the external input device(s).
AY03.09. (Security levels 1, 2, 3 and 4)
All output commands, signals, and control data (e.g. control commands
to another module) used to control the operation of a cryptographic
module shall exit via the “control output” interface.
Required vendor documentation
CY03.09.01. The cryptographic module shall have a control output interface.
The output commands, signals, and control data used to control the operation
of a cryptographic module must be output via the control output interface.
CY03.09.02. If applicable, the vendor documentation shall describe all external
devices that are used in conjunction with the cryptographic module and that are
used to output control data from the control output interface, such as smart
cards, tokens, displays and / or other storage devices.
Required test procedures
JY03.09.01. The tester shall verify that the output commands, signals and
control data used to control the operation of a cryptographic module shall be
output via the control output interface.
JY03.09.02. The tester shall verify whether the vendor documentation specifies
the external devices that are used in conjunction with the cryptographic module
and that are used to output control data from the control output interface, such
as smart cards, tokens, displays and / or other storage devices.
AY03.10. (Security levels 1, 2, 3 and 4)
All control output via the “control output” interface shall be inhibited
when the cryptographic module is in an error state unless exceptions are
specified in the security policy.
Required...
......
|