GM/T 0110-2021Key management interoperability protocol specification (English PDF)

3.1 Archive

Put infrequently accessed information into long-term storage.

3.2 Authorization

An access right granted to an entity. It expresses a "formal" permission to perform a security function or activity.

3.3 Compromise

Unauthorized disclosure, alteration, replacement, or use of sensitive data (such as key material and other security-related information).

3.4 Message digest

The result of a cryptographic hash operation on a message.

3.5 Key wrapping (wrapping)

A method of encrypting, MAC/signing, or both encryption and MAC/signing a key.

3.6 Profile

A specification of objects, attributes, operations, message elements, and authentication methods. These objects, attributes, operations, message elements, and authentication methods are used in the interaction between a key management service and a client in a specific context.

3.7 Recover

Recover information that has been archived for long-term preservation.

3.8 Split key

The process of splitting a key into n key components using secret sharing technology.

Each key component cannot be used to deduce the original key alone, but when combined together, the original key can be reconstructed. If k key components (k <= n) are required to reconstruct the original key, then if only k -1 key components are known, the key information of the original key cannot be gotten.

3.9 Salt

A random variable added as a secondary input to a one-way or encryption function that can be used to derive password verification data.

3.10 Key derivation

Derive one or more secret keys from a secret value of a master key, password, or passphrase using a pseudorandom function. It can be used to extend a key into a longer key or to get a key in a desired format.

3.11 XEX-based tweaked-codebook mode with ciphertext stealing

An adjustable codebook mode based on the XEX (XOR-ENCRYPT-XOR) ciphertext stealing algorithm. This encryption mode is mainly used to encrypt static data in storage devices based on data units (including sectors, logical disk blocks, etc.).

3.12 Managed object

The objects managed by the key management server, including symmetric keys, asymmetric keys, certificates, secret data, opaque objects, etc.

6.1 Protocol model

The interaction model of the key management interoperability protocol is shown in

Figure 1.

Figure 1 -- Interaction model of key management interoperability protocol

As shown in Figure 1, the client sends a request message to the key management server.

The request message shall contain information such as client identity authentication, operation identifier, and operation parameters. The key management server performs corresponding operations according to the request message and returns the operation results to the client as a response message. The response message contains the result state and result data. The protocol described in this document has the following characteristics.

a) Messages are independent of each other. Implementors do not need to maintain message-related states. For specific message data formats and encodings, see 6.5.

b) The message can contain a single operation request or response, or multiple operation requests or responses.

c) The message can be a synchronous message or an asynchronous message. The form of the message is related to the specific operation and implementation.

d) According to the different operations or the different target objects of the operation, it can be divided into.

1) Direct operation without authentication, such as querying public objects;

2) Operations that require authentication, such as creating and getting private objects.

6.2.1 Object types

The following subsections describe the objects passed between the Client and the Key Management Server.

Managed objects are the objects of key management operations (see 6.4). Managed objects include cryptographic objects (objects containing key material, such as certificates, keys and secret data) and non-cryptographic objects (such as opaque objects).

Some object types are only used in the protocol itself and are not managed objects. They are called basic objects.

The primitive data types referenced in object descriptions include.

- Integer;

- Long Integer;

6.4.1.1 Overview

This clause defines the operations that a key management client can request. All object management operations are sent from the client to the server in a request, and the results are gotten in a response from the server to the client. Multiple operations can be combined in a batch. The result is only a single request response.

The following operations are affected by a mechanism called ID placeholders.

The key management service shall implement a temporary variable called an ID placeholder. This value contains a unique identifier. It is a variable stored internally in the server. It is valid and persisted only while a batch operation is executed. Once the batch operation is completed, the ID placeholder shall be discarded and/or invalidated by the server so that subsequent requests will not see this previous ID placeholder as valid.

The ID placeholder is gotten from the unique identifier returned in the response to the Create Symmetric Key, Create Public-Private Key Pair, Register, Derive Key, Update Symmetric Key, Update Public-Private Key Pair, Locate, and Recover operations. If any of these operations complete successfully, the server shall copy this unique identifier into the ID placeholder variable. It shall be retained until the rest of the batched operations are completed, or a subsequent operation in the batch causes the ID placeholder to be replaced. If the Batch Error Continue option is set to Stop and the Batch Sequential option is set to True, subsequent operations in the batched request can utilize the ID placeholder by omitting the unique identifier in the request payload.

For any operation on managed objects already stored on the server, any archived objects shall first be made available via a restore operation (see 6.4.1.22) before they can be used (e.g. online objects).

Multi-step cryptographic algorithm operations (operations whose data flow spans multiple requests from the client to the server) are optionally supported by those cryptographic algorithm operations that include the associated value (see 6.2.2.15), initial indicator (see 6.2.2.16), and completion indicator (see 6.2.2.17) request parameters.

For multi-step cryptographic algorithm operations, perform the following process.

a) In the first request.

1) provide an initial indicator with a value of true;

2) provide other required parameters;

3) retain the relevant values returned in the response for subsequent requests;

4) use the data output of the response (if any).

7.3 Storage security

Users can choose to store sensitive data objects such as private keys and symmetric keys in hardware cryptographic devices, or adopt other security measures.

The security of the master key or root key is very important. It shall be stored in a hardware cryptographic device. Secret sharing technology (key splitting) can be used to achieve secure management of the master key or root key.

7.4 Transmission security

The key client and key management server shall establish and maintain a secure channel.

Ensure the confidentiality and integrity of the secure channel.

The key client shall verify the authenticity of the key management server identity.

The key management server can verify the authenticity of the key client identity according to security needs.

The communication between the key client and the key management server shall comply with the provisions of GM/T 0024.

7.5 Identity authentication

The mechanism used to authenticate the server and client is not part of the message definition, but is external to the protocol (e.g., the secure communication protocol between the client and the server).

Credentials (see 6.2.2.2) are used to identify the visitor, or to authenticate the client.

The credentials can be associated with the client certificate when establishing a secure channel to improve the security of authentication.

7.6 Access control

Key objects can only be authorized to legitimate users or applications for operation. It is necessary to authenticate the visitor's identity and review the operation permissions to determine whether the visitor has the permission to operate the object.

Objects can have sensitive and always-sensitive attributes set based on security needs.

The access rights for an object are specified by the credentials included in the create key object message (see 6.2.2.2).

The operation permissions of the object are marked by the cryptographic usage mask ......