PDF GM/T 0104-2021 English
Search result: GM/T 0104-2021
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| GM/T 0104-2021 | English | 470 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Specifications of cloud host cryptographic server
| Valid |
PDF Preview: GM/T 0104-2021
GM/T 0104-2021: PDF in English (GMT 0104-2021) GM/T 0104-2021
GM
CRYPTOGRAPHY INDUSTRY STANDARD
OF THE PEOPLE’S REPUBLIC OF CHINA
ICS 35.030
CCS L 80
Specifications of cloud host cryptographic server
ISSUED ON: OCTOBER 18, 2021
IMPLEMENTED ON: MAY 01, 2022
Issued by: State Cryptography Administration
Table of Contents
Foreword ... 4
1 Scope ... 5
2 Normative references ... 5
3 Terms and definitions ... 6
4 Abbreviated terms ... 8
5 Functional requirements ... 8
5.1 Device form ... 8
5.2 Device management ... 9
5.3 Cryptographic operations ... 11
5.4 Log audit ... 11
5.5 Device self-checking ... 12
5.6 Device use ... 12
5.7 Virtualization ... 13
6 Security requirements ... 14
6.1 Key management ... 14
6.2 Access control and identity authentication... 17
6.3 Random number generation and verification ... 18
6.4 Hardware security ... 18
6.5 Software security ... 19
6.6 VSM security ... 19
6.7 Security isolation ... 19
6.8 Security drift ... 22
6.9 Device state ... 23
7 Hardware requirements ... 24
7.1 External interface ... 24
7.2 Randomizer ... 24
7.3 Environmental adaptability ... 24
7.4 Reliability ... 25
8 Software requirements ... 25
8.1 Basic requirements ... 25
8.2 Management tools ... 25
9 Interface specifications ... 25
9.1 Service interface ... 25
9.2 Management interface ... 26
10 Testing requirements ... 26
10.1 Testing instructions ... 26
10.2 Appearance and structure inspection ... 26
10.3 Inspection of submitted files ... 26
10.4 Function testing ... 26
10.5 Performance testing ... 29
10.6 Environmental adaptability testing ... 32
11 Judgment of conformity ... 32
Appendix A (Informative) Cloud cryptographic server Web service interface message
syntax ... 33
Specifications of cloud host cryptographic server
1 Scope
This document defines the relevant terms of cloud cryptographic server, and specifies
the overall structure, functional requirements, hardware requirements, software
requirements, security requirements and testing requirements of cloud cryptographic
server.
This document applies to the development and use of cloud cryptographic server, and
can also be used to guide the testing of cloud cryptographic server.
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
version corresponding to that date is applicable to this document; for undated references,
the latest version (including all amendments) is applicable to this document.
GB/T 9813.3-2017, General specification for computer - Part 3: Server
GB/T 31168-2014, Information security technology - Security capability
requirements of cloud computing services
GB/T 32915-2016, Information security technology - Binary sequence randomness
detection method
GB/T 35293-2017, Information technology - Cloud computing - General technical
requirements of virtual machine management
GB/T 36322-2018, Information security technology - Cryptographic device
application interface specifications
GB/T 37092-2018, Information security technology - Security requirements for
cryptographic modules
GB/T 36968-2018, Information security technology - Technical specification for
IP Sec VPN
GB/T 38636-2020, Information security technology - Transport layer cryptography
protocol (TLCP)
GB/T 38625-2020, Information security technology - Security test requirements
for cryptographic modules
management system, but can be centrally and uniformly managed by the management
system of the tenant to which the virtual security module belongs.
The remote management and maintenance channels of the cloud cryptographic server
host and different virtual security modules shall be independent of each other.
Encryption and identity authentication as well as other technical means shall be used to
protect the remote management and maintenance channels. The administrators and
maintenance personnel of the host cannot log in to the virtual security module, cannot
obtain sensitive information in the virtual security module, and cannot access the
services of the virtual security module.
The administrator of the host is provided with the operating authorizations such as
initialization, system configuration and key management on the host, as well as the
operating authorizations such as creation, startup, shutdown, deletion, and drift on
virtual security modules. The administrator of the host cannot perform operations such
as initialization, system configuration, and key management on virtual security modules.
The administrator of the virtual security module has the authority to perform operations
such as initialization, system configuration, and key management on the virtual security
module to which it belongs, but cannot perform operations such as initialization, system
configuration, and key management on the host and other virtual security modules, nor
can it perform operations such as creation, startup, shutdown, deletion and drift on the
virtual security module.
5.2.2 Initialization
The initialization of the cloud cryptographic server host mainly includes the generation
(recovery) and installation of the host key, the generation of administrators, the secure
storage and backup of the key according to the security mechanism, so that the device
is in a ready state. The initialization of the virtual security module mainly includes the
generation (recovery) and installation of the virtual security module key, the generation
of administrators, the generation or import of the identity authenticated information
such as digital certificate or identification password of tenants and virtual security
modules, so that the virtual security module is in a ready state. Before the virtual
security module is put into normal use, it is necessary to complete the generation or
import of the identity authenticated information of tenants and the corresponding virtual
security module.
5.2.3 Registration, scheduling and monitoring
The cloud cryptographic server host should have the function of registering with the
cloud platform management system, registering the physical resources of the host's
physical device (processor, memory, network, cryptographic computing power, key
storage capacity, etc.), and accepting the cloud platform management system's
scheduling management and real-time monitoring of its operational state.
5.3 Cryptographic operations
The virtual security module shall have cryptographic operations such as symmetric
cryptographic operations, public key cryptographic operations, and cryptographic hash
operations, and support multi-task concurrent access.
5.3.1 Symmetric cryptographic algorithm
The virtual security module shall support at least the SM4 block cipher algorithm,
including at least two modes: electronic codebook (ECB) and chained block cipher
(CBC).
5.3.2 Public key cryptographic algorithm
The virtual security module shall support at least the SM2 public key cryptographic
algorithm.
5.3.3 Cryptographic hash algorithm
The virtual security module shall support at least the SM3 cryptographic hash algorithm.
5.4 Log audit
The cloud cryptographic server host and different virtual security modules shall provide
log record, view and export functions.
The log contents of the host include:
a) Login authentication, system configuration and other administrator operations;
b) Operations or events such as creation, startup, shutdown, deletion, and drift of
virtual security modules and their results;
c) Corresponding management commands and operations from the cloud platform
management system.
The log contents of the virtual security module include:
a) Administrator operations, including login authentication, system configuration,
key management, etc.;
b) Abnormal events, including records of abnormal events such as authentication
failure and illegal access.
The storage and operation of logs shall meet the following requirements:
-- The log records of the host and different virtual security modules shall be
stored and operated independently;
b) The tenant accesses the management IP address of the virtual security module
and logs in to the virtual security module with the default administrator
password to perform initialization operations on the virtual security module,
including the generation or import of identity authenticated information of the
tenant and the corresponding virtual security module.
c) The tenant logs in to the virtual security module as an administrator to perform
system configuration and key management operations.
d) The tenant establishes a secure channel with the virtual security module and calls
the cryptographic service of the virtual security module through the secure
channel. For the requirements on the secure channel, see 9.1.
5.7 Virtualization
5.7.1 Virtual security module life cycle management
The cloud cryptographic server shall have virtualization function, to be able to accept
external commands, as well as to create, start, stop and destroy virtual security modules.
5.7.2 Key isolation between virtual security modules
The cloud cryptographic server shall have a key isolation function to prevent the virtual
security module's key from being stolen, prevent the cross-use of keys between virtual
security modules, and prevent the host administrator from obtaining the virtual security
module's key.
5.7.3 VSM image security
The image file of the virtual security module shall be protected by a signature, and the
cloud cryptographic server shall prohibit the VSM image that fails the signature
verification from running in the cloud cryptographic server.
5.7.4 VSM security drift
The cloud cryptographic server should support the VSM drift function. During the drift
process, the VSM data image shall be encrypted and protected for integrity.
5.7.5 VSM resource adjustment
The cloud cryptographic server should support the adjustment function of the resources
(processor, memory, network, cryptographic operation, key storage, etc.) occupied by
the virtual security module.
5.7.6 Maximum number of virtual security modules
The cloud cryptographic server shall define and report the maximum number of virtual
security modules supported to the cloud platform management system.
User key: including signature key pair and encryption key pair, which are used to
implement user signature, verification, identity authentication, protection and
negotiation of session keys, etc., representing the identity of tenants or applications.
The host of the cloud cryptographic server does not use and manage the user key. Each
virtual security module uses its own management key to encrypt and store its own user
key. Different virtual security modules cannot access each other's user key.
Device key: the identity key of the cloud cryptographic server, including the signature
key pair and the encryption key pair, which is used for device management and
represents the identity of the cloud cryptographic server. The host of the cloud
cryptographic server and each virtual security module have their own device key and
are encrypted and stored with their own management key.
Key encryption key: a symmetric key that is changed regularly. In the case of pre-
allocated or imported and exported keys, the virtual security module uses the key
encryption key to protect the session key.
Session key: used for data encryption and decryption.
6.1.3 Key generation and installation
Management key: generated or installed by the management tool used when the device
is initialized, and stored in the secure storage area inside the cloud cryptographic server.
The host and each virtual security module of the cloud cryptographic server shall use
their own independent management tools to generate their own management keys and
store them in their own independent secure storage areas.
User key: The user signature key pairs of the virtual security modules of the cloud
cryptographic server are generated and installed by each virtual security module. The
user signature key pairs shall be generated using random numbers and strong prime
numbers generated by physical noise sources. User encryption key pairs are generated
by the key management system and distributed independently to each virtual security
module. The format of encryption key pair distribution shall comply with the
requirements of GB/T 36322 for encryption key pair protection format.
Device key: The host and each virtual security module of the cloud cryptographic server
shall use their own independent management tools to generate their own device
signature key pairs. The device signature key pairs shall be generated using random
numbers and strong prime numbers generated by physical noise sources. The device
encryption key pairs are generated by the key management system and distributed
independently to the host and each virtual security module. The format of the device
encryption key pair distribution shall comply with the requirements of GB/T 36322 for
the protection format of encryption key pairs.
Key encryption key: The virtual security modules of the cloud cryptographic server
shall use their own independent management tools to generate their own key encryption
keys and encrypt the session keys for protection. The key encryption keys shall be
generated using random numbers generated by physical noise sources.
Session key: The session key shall be generated using random numbers generated by
physical noise sources, and the session key shall be replaced once per session.
6.1.4 Secure storage and destruction of keys
Each virtual security module of the cloud cryptographic server shall be able to store at
least 32 pairs of asymmetric keys and 100 symmetric keys.
The cloud cryptographic server shall store keys securely and persistently, which shall
comply with the provisions of security level 2 and above for the management of
sensitive security parameters in GB/T 37092.
The device key, user key and key encryption key of the virtual security module are
encrypted with the management key of the virtual security module and stored in the
independent secure storage area of each virtual security module. Each virtual security
module shall support a certain number of key storage. When the session key is stored
for a long time, it shall be encrypted and protected using user key pairs or key
encryption keys.
The secure storage of virtual security module management keys should adopt the tenant
authorization mode to avoid access by the host and other virtual security
modules/tenants. The following methods can be used:
-- Use the authorization code combined with other key components as the key
material for encrypted storage. Other key components can use information
such as random numbers and hardware feature codes (such as the MAC
address of the Ethernet card, the serial number of the hard disk, etc.);
-- Store on the key storage component with micro-electric protection and key
destruction triggering device, and use authorization codes for access control;
-- Store on external password modules such as cryptographic smart token, and
use authorization codes for access control.
Different virtual security modules shall have different authorization codes, which are
kept and used by the tenant. The administrator password of the virtual security module
or the PIN code of the cryptographic smart token can be used as the authorization code.
The device key of the host is encrypted and stored with the management key of the host.
The management key of the host needs to be encrypted or stored securely using a key
storage component with micro-electric protection and key destruction trigger device.
The virtual security module and tenants cannot access the management key of the host.
The host and the virtual security module shall each have an independent key destruction
function. When executing key destruction, the designated keys stored in the host and
and shall comply with the provisions for identity authentication of administrators and
users at security level 2 and above in GB/T 37092. An identity authentication
mechanism based on digital certificates, identification passwords or hardware identity
media should be used.
The host or virtual security module shall have a complete identity authentication
mechanism, and different management operations shall have different operation
permissions. The host or virtual security module shall reject any access or operation
without corresponding permissions to prevent unauthorized malicious personnel from
logging in, so as to avoid damaging the security of the host and virtual security module.
The cloud cryptographic server shall be able to provide access control functions for
internally stored data and resources:
-- For the private key stored in the virtual security module, the correct private
key access password shall be held to use it;
-- The calling of the virtual security module service interface and the remote
management of the host and the virtual security module can adopt the
authorized access control technology based on the IP address. Only the host
with the authorized IP address can normally call the virtual security module
service interface or remotely manage the host and the virtual security module.
The host without the authorized IP address is not allowed to call the virtual
security module service interface or remotely manage the host and the virtual
security module;
-- Access to different virtual security modules shall be individually authorized
by the administrator of the virtual security module being accessed.
6.3 Random number generation and verification
Each virtual security module shall have an independent random number generation
function, and the random numbers generated by the virtual security module shall
comply with the requirements of GB/T 32915 and the provisions of GM/T 0062 for
Class E products. When virtual security modules share a physical noise source, they
shall be logically isolated through virtualization technology; it shall be ensured that
different random numbers are provided to different virtual security modules, and the
used random numbers are reset to zero.
6.4 Hardware security
The hardware of the cloud cryptographic server shall comply with the physical security
requirements for hardware modules of security level 2 and above in GB/T 37092.
The cloud cryptographic server shall provide security measures to ensure the storage
security of cryptographic algorithms, keys, and key data.
Except for the necessary communication interface and management interface, no
external interface for debugging and tracking is provided. The internal debugging and
testing interface shall be closed after the product is finalized.
The cloud cryptographic server shall prevent sensitive information in the cloud
cryptographic server or virtual security module from being obtained through any
unauthorized external interface.
Cloud cryptographic servers shall be provided with corresponding protection measures
in terms of process design, structural design, hardware configuration, etc. to ensure the
basic physical security protection functions of the device.
6.5 Software security
The software and firmware of the cloud cryptographic server shall comply with the
software/firmware security regulations of security level 2 and above in GB/T 37092.
All security protocols and management software shall be implemented independently.
The operating system shall be hardened for security, all unnecessary functions shall be
cut off, and all unnecessary ports and services shall be closed.
Any operation instructions and any combination thereof cannot leak keys and sensitive
information.
The cloud cryptographic server only accepts legal operation instructions.
6.6 VSM security
The virtual security module shall meet the VSM security management requirements
proposed in GB/T 35293 and the system virtualization, network virtualization and
storage virtualization security requirements proposed in GB/T 31168.
6.7 Security isolation
6.7.1 Management isolation
The host and different virtual security modules shall have different management IP
addresses, management domain names or management ports, run different management
processes, and use different security channels for remote management or remote
maintenance.
The same terminal device cannot log in to the host and different virtual security modules
at the same time.
User information cannot be shared between the host and different virtual security
modules, and completely independent user management shall be performed.
guest operating systems (GuestOS) or namespaces for different virtual
security modules.
6.7.4 Key isolation
The host and different virtual security modules shall have their own completely
independent management keys, device keys, user keys, key encryption keys and session
keys. The key structure shall be generated completely independently and protected by
layers of encryption in accordance with the requirements of 6.1.2.
The top-layer management key shall be stored in accordance with the requirements of
6.1.4. The management keys of the host and different virtual security modules use
different authorization codes for access control. The authorization code of the host is
kept by the host administrator, and the authorization codes of different virtual security
modules are kept and used by their respective tenants.
6.7.5 Cryptographic component isolation
Hardware or software-based virtualization technology can be used to securely isolate
and share the cryptographic components of the cloud cryptographic server between
virtual security modules.
-- Inside cryptographic components such as cryptographic operation
components, key storage components, and randomizers, different operation
units and storage spaces can be divided for the host and different virtual
security modules in a physical or logical manner.
-- The IO (input and output) interface of the cryptographic component can use
hardware virtualization (such as SRIOV) or physical or logical methods such
as access control at the driver and API layer to divide different data and control
command transmission channels for the host and different virtual security
modules.
-- When using hardware virtualization technologies such as SRIOV to share
cryptographic components, independent virtual cryptographic components
(VFs) shall be assigned to different virtual security modules. Technical means
shall be used to prevent virtual security modules from accessing virtual
cryptographic components (VFs) that are not assigned to them. When the
hardware and underlying operating system support virtual device views,
independent device views can be created for different virtual security modules,
and the view only contains virtual cryptographic component devices (VFs)
assigned to this virtual security module. When the hardware and underlying
operating system do not support virtual device views, virtual cryptographic
components can be uniformly named, and the cryptographic component
device driver of the virtual security module can be bound to the named virtual
cryptographic component assigned to this virtual security module. The
naming parameters are passed in when the virtual cryptographic is initialized,
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|